LDAP

LDAP is a protocol for managing distributed directory services. Examples of handled information can be the list of company emails, addressbooks, and any kind of data represented as a hierarchical model.

Introduction to LDAP

As is written on Wikipedia (LDAP):

The LDAP protocol provides an interface with directories that follow the 1993 edition of the X.500 model:

• 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.

• 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 the full file path and the RDN as its relative filename in its parent folder (e.g. if /foo/bar/myfile.txt were the DN, then myfile.txt would be the RDN).

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 LDAP Data Interchange Format (LDIF) (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 1232
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

dn is the distinguished name of the entry; it is neither an attribute nor a part of the entry. cn=John Doe is the entry's RDN (Relative Distinguished Name), and dc=example,dc=com is the DN of the parent entry, where dc denotes 'Domain Component'. 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 that 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 of 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.

Aliases and Dereferencing Aliases

LDAP aliases provide alternative distinguished names (DN) for entries. The DN describes the contents of attributes in the tree (the navigation path) that will reach the specific entry required OR the search start entry. The use of aliases allows one object to be named using different names.

As it is described in Java official documentation: http://docs.oracle.com/javase/jndi/tutorial/ldap/misc/aliases.html:

Called an alias entry, it contains the DN of the object to which it is pointing. When you look up an object by using the alias, the alias is dereferenced so that what is returned is the object pointed to by the alias's DN. You can use aliases to organize the directory's namespace so that as the namespace evolves, old names may be used. Suppose, for example, that in the o=Wiz, c=us company, the departments ou=hardware and ou=software are merged into ou=engineering. You can move the contents of ou=hardware and ou=software to ou=engineering, and change the entries ou=hardware and ou=software into alias entries that point to ou=engineering.

In the LDAP, aliases are supported in the same way as in the X.500.

When you use Sun's LDAP service provider, you can control how aliases are dereferenced in one of four ways, by using the java.naming.ldap.derefAliases environment property, as shown in the following table. If this environment property is not set, then the default is always.

Property Setting	Description
always	Always dereference aliases
never	Never dereferences aliases
finding	Dereferences aliases only during name resolution
searching	Dereferences aliases only after name resolution

Dereferencing Aliases Example

For this example, the directory has been set up with two aliases, as follows:

• ou=Staff is an alias that points to ou=People. If you list the context of ou=Staff, then you will see the contents of the ou=People context.

• cn=Newbie, ou=People is an alias that points to the cn=J. Duke, ou=NewHires entry.

After setting the environment property, the example performs a search on the ou=Staff context for all entries whose cn attribute begins with J.

The following table summarizes the results of a search with different arguments.

Command Line Argument	Results
(none)	Three entries: cn=Jon Ruiz, cn=John Fowler, cn=J.Duke
always	Three entries: cn=Jon Ruiz, cn=John Fowler, cn=J.Duke
never	Zero (because the ou=Staff alias is never dereferenced)
finding	Two entries: cn=Jon Ruiz and cn=John Fowler (because the cn=Newbie alias is never dereferenced)
searching	Zero (because the ou=Staff alias is never dereferenced)