LDAP Applications - Page 3

The key to deciding whether to choose an LDAP directory service is to understand what data can go into the LDAP directory. A few cases of what data can be represented using an LDAP directory and some examples of common directory applications are in order:

• The directory services can be white page services, yellow page services, or a query list of all the printers on the 6th floor. Queries with multiple constraints are of course possible - list of all employees in the Engineering division working out of Europe with birthdays falling on March 22nd.
• A very common LDAP application is seen in e-mail clients that auto-fill the e-mail address of the recipient when the name of the recipient is typed into the To: field. The e- mail client uses the name to query an e-mail directory and fills in the field with the result.
• Several LDAP applications are actually gateways to other established services. For example, using a DNS to X.500 gateway, it is possible for LDAP-enabled clients to query a LDAP server for information residing on a legacy X.500 directory. Other examples of LDAP gateways are e-mail to LDAP, finger to LDAP, and DNS to LDAP.

Examples of data suited to reside in LDAP directories:

• Employee phone book
• Organizational charts
• IT services information (for example, Domain names or IP addresses of servers)
• E-mail addresses
• Public certificates and cryptographic public keys
• URLs
• Binary data such as pictures

In short, LDAP can be used in applications where the data is seldom changed and the query volumes are high.

To better understand a typical application of LDAP let us take a look at the organizational chart of a small company, FooWid Inc. A directory service can be implemented to store information about the organization and its employees:

FooWid, based in the USA and working out of a two-storied building has just two departments - manufacturing and administration and 5 employees. A thing to note here is that employees are hierarchically classified under departments, just as they are also grouped under the criteria of the floor on which they work. This is precisely the kind of scenario we can attempt to represent in an LDAP directory:

First we break up the hierarchical tree into various levels and assign names to each of the levels; the first level is the country level and is labeled c, the next level is the name of the organization and the label is o; the label for departments is ou (organizational unit). Let us label the employee names as cn, (common name). Each of these labels has a value assigned to them.

In this case cn=Bob W, ou=Administration, o=FooWid, c=US is an example of a unique name to identify an employee's record. Once we locate a record using this identifier, we can easily access other interesting information contained in the record, such as the employee's e-mail id or telephone number.

So to uniquely identify an employee, would it be sufficient that we trace the employee node in the tree from the root? The answer is yes, for example, Bob could be uniquely identified as c=US, o=FooWid, ou=Administration, cn=Bob W.

Some LDAP terminology

Keeping in mind the organizational chart of FooWid as an example, let's take a look at some common terminology:

• Entry
  In a generic sense, an entry is to a directory what a record or row is to a database. The node holding the name Bob can also hold information about him, such as which floor he works on and what his e-mail address is. The whole node is as such called an entry. This is also called a DSE (Distinguished Service Entry).

• Attributes
  An attribute is to a directory what a field is to a database. The field in the entry Bob holding his common name is labeled as cn and is assigned the value Bob W; this is an example of an attribute.

• Objects
  Objects in a directory are analogous to tables in a database. All the records in a database table are similar in the sense that they have similar fields. Similarly all entries of a particular object type will have the same kind of attributes. Objects have the additional capability that they can be extended to add new attributes to the pre-existing list of attributes (unlike tables in relational databases).

• Distinguished Name (DN)
  The name used to uniquely (and globally) identify Bob is c=US, o=FooWid, ou=Administration, cn=Bob W. This is the distinguished name. Here an attribute, cn in this case, is chosen as the key that will represent the entry. The path leading to the entry with their values makes up the DN, thus the DN is the unique identifier of an entry.

• Relative Distinguished Name (RDN)
  Each level in the tree makes up a component of the DN to a particular node. Each of these components is called a RDN (Relative Distinguished Name).

• Directory Information Tree (DIT)
  The entire information tree of the directory itself is called the DIT (Directory Information Tree).

• Schema
  The schema of an LDAP directory gives the layout of the information it contains and also how this information is grouped. It thereby allows clients or external interfaces to determine how the data is arranged within the directory and how it can be accessed in terms of search, addition, deletion, modification, and so on. You must refer to RFC 2256 for comprehensive detail on the LDAP object classes and attributes.

Components of LDAP - Page 2
Professional PHP4 Programming
LDAP Models - Page 4