The Lightweight Directory Access Protocol, or LDAP , is an application protocol for querying and modifying directory services running over TCP/IP
A directory is a set of objects with similar attributes organized in a logical and hierarchical manner. The most common example is the telephone directory, which consists of a series of names (either of persons or organizations) organized alphabetically, with each name having an address and phone number attached. Due to this basic design (among other factors) LDAP is often used by other services for authentication
Is an LDAP information directory a database?
Just as a Database Management System (DBMS) from Sybase, Oracle, Informix, or Microsoft is used to process queries and updates to a relational database, an LDAP server is used to process queries and updates to an LDAP information directory. In other words, an LDAP information directory is a type of database, but it’s not a relational database. And unlike databases that are designed for processing hundreds or thousands of changes per minute – such as the Online Transaction Processing (OLTP) systems often used in e-commerce – LDAP directories are heavily optimized for read performance.
The LDAP protocol is both cross-platform and standards-based, so applications needn’t worry about the type of server hosting the directory. In fact, LDAP is finding much wider industry acceptance because of its status as an Internet standard. Most LDAP servers are simple to install, easily maintained, and easily optimized.
LDAP is particularly useful for storing information that you wish to read from many locations, but update infrequently. For example, your company could store all of the following very efficiently in an LDAP directory:
- The company employee phone book and organizational chart
- External customer contact information
- Infrastructure services information, including NIS maps, email aliases, and so on
- Configuration information for distributed software packages
- Public certificates and security keys
A client starts an LDAP session by connecting to an LDAP server, by default on TCP Port 389. The client then sends operation requests to the server, and the server sends responses in turn. With some exceptions the client need not wait for a response before sending the next request, and the server may send the responses in any order.
The client may request the following operations:
- Start TLS – optionally protect the connection with Transport Layer Security (TLS), to have a more secure connection
- Bind – authenticate and specify LDAP protocol version
- Search – search for and/or retrieve directory entries
- Compare – test if a named entry contains a given attribute value
- Add a new entry
- Delete an entry
- Modify an entry
- Modify Distinguished Name (DN) – move or rename an entry
- Abandon – abort a previous request
- Extended Operation – generic operation used to define other operations
- Unbind – close the connection (not the inverse of Bind
Directory Structure:
The protocol accesses LDAP directories, which follow the 1993 edition of the X 500model:
- A directory is a tree of directory entries.
- An entry consists of a set of attributes.
- An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema (see below).
- Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, followed by the parent entry’s DN. Think of the DN as a full filename and the RDN as a relative filename in a folder.
Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID might be provided in the set of the entry’s operational attributes.
An entry can look like this when represented in LDIF format (LDAP itself is a binary protocol):
dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1234 mail: john@example.com manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top
dn is the name of the entry; it’s not an attribute nor part of the entry. “cn=John Doe” is the entry’s RDN, and “dc=example,dc=com” is the DN of the parent entry. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like “cn” for common name, “dc” for domain component, “mail” for e-mail address and “sn” for surname.
A server holds a subtree starting from a specific entry, e.g. “dc=example,dc=com” and its children. Servers may also hold references to other servers, so an attempt to access “ou=department,dc=example,dc=com” could return a referral or continuation reference to a server which holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.
LDAP rarely defines any ordering: The server may return the values in an attribute, the attributes in an entry, and the entries found by a search operation in any order. This follows from the formal definitions – an entry is defined as a set of attributes, and an attribute is a set of values, and sets need not be ordered.
To learn about: How-To set up a LDAP server and its clients in Ubuntu, refer
http://www.debuntu.org/ldap-server-and-linux-ldap-clients
Example:
The organisation like an IT company will usually have all the details of the employees stored in the LDAP server. The admin can edit the info of any employee or update the data of the new employee. This LDAP server will have a hostname (IP). You need this hostname(ldap.ind.xyz.com) or IP when you want to do login authentication in some application using Java. This application is used by the employees in the organisation and so uses LDAP for authentication. You need to put “netscape-ldap-1.0.jar” in the classpath or include this jar in the java build path-> libraries in eclipse for that project. You can now write an EJB (stateless, session bean) which does the authentication for you and deploy it in JBoss. Using EJB Client, you can pass the employee name or id and get the authentication done. This EJB example can be found at: http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-ejb.html?page=2#resources
Note: Use can even use JNDI to do authorisation with LDAP server instead of netscape-ldap-1.0.jar. However, from what i know, using netscape ldap is better.
Filed under: Tech | 2 Comments »
Firefox: 1.5 – 3.0a2
A-T-T-I-T-U-D-E in A to Zee 