LDAP

LDAP (Lightweight Directory Access Protocol) has evolved into the most popular open directory access mechanism in the recent times. Essentially this means that information can be stored in a hierarchical structure that is accessible from remote locations. Good examples of this are e-mail address lookup tables, white pages, and company structure information.

In this chapter we shall look into:

• Concepts of directory services and LDAP in particular
• LDAP terminology and the models of LDAP
• Practical applications of LDAP
• The API that PHP provides for programming LDAP client applications
• A sample application to access an LDAP server using PHP's LDAP client API

Overview of Directories

The generic example of a directory would be a telephone directory or an address book. We use white pages directories when we need to find something specific about a person or a business about which we know something distinguishing such as the name of the person or the name of the business. When we need to find more general information about a group, say we need to find the list of all local merchants who specialize in selling reusable widgets, we refer to a yellow pages directory.

We use directories when we use e-mail or a web browser. The e- mail client sends a mail message to a mail server. The mail server looks up an internal table to locate the host machine on which the recipient of the message has an account. Similarly, when the name of a website is typed into a browser, the browser contacts a Domain Name System (DNS) server. The DNS server looks up an internal table that maintains a mapping between a DNS name and the IP address of the machine that hosts the web site. The server returns the mapping to the browser that now talks directly to the web server using its IP address. Ideally, such information can reside in a directory and can be accessed by any client that can speak the protocol of the directory. In fact, there are now quite a few installations where DNS lookup is directory enabled using DNS-to-LDAP gateways.

LDAP

LDAP evolved from the need to supplement the pre-existing directory service provided by the X.500 protocol. The X.500 protocol was heavyweight, due to various transaction overheads and the fact that it used the bulky OSI network stack for its underlying network transport. Though LDAP started out as a gateway to the X.500 directory, using the TCP/IP protocol for its network transport, it evolved from there on to a standalone, networked directory server protocol with a global scope. Thus, with burgeoning amounts of data needed to effectively manage our work and lives, LDAP plays the role of the data manager without the unnecessary overheads. With version 3, LDAP provides extensive customization and extensibility features in the form of LDAP controls.

LDAP vs. Traditional Databases

LDAP was designed and optimized to handle simple data, which once written, will seldom be modified. Traditional databases have been designed and optimized for both query and update operations on data and are designed to handle highly complex data, as opposed to LDAP, which is essentially a text-based directory storage system.

Further, traditional databases have been built for transaction integrity and consistency. This is not really a priority for LDAP where the data is most often read than written. Thus the lightweightness of LDAP comes from it being a simple protocol handling simple data.

LDAP servers usually use quite simplified back-end databases like the Berkeley database or the GDBM (Gnu Database Manager). These provide just the necessary functionality without the overheads. In fact the maintainers of the Berkeley database optimize the database for OpenLDAP and Netscape Directory Server to use it as a back-end datastore. However, a significant number of commercial vendors have chosen to implement LDAP servers using traditional databases as datastores, most notable are Oracle's OID and Microsoft's ICL i.500. Such solutions are often desirable when LDAP servers using flat files or simplified databases for datastores cannot scale to handle very high query volumes.

The way a directory organizes data is considerably different from how a traditional database organizes it. This difference is explicit on the following counts:

• Databases usually have only fields with unique names within a record; for example, an employee record has one field with the name telephonenumber. This is not the case with an LDAP directory. For example, an employee record in a database may have a field named telephonenumber, and there is one and only one field with this name as far as the record is concerned. So what if an employee has two telephone numbers, say one work number and a second cell phone number? In a traditional database, this is solved by representing the numbers as a separate telephone number table with the employee ids used to relate them to a particular employee. However, in an LDAP directory there can be one attribute with the name telephonenumber but with multiple values; there could be two fields with the same name telephonenumber, one representing the work number and the other representing the mobile number. In such a situation, the directory is most likely to perform better than the database in terms of processing a query for the telephone numbers of an employee. Such a fluid scheme is one of the reasons that queries are processed very fast in a LDAP directory.
• Directories such as LDAP order data in a hierarchical fashion as well as group data into various groups. As an example for this, consider the entries for employees in the FooWid Inc chart in the LDAP Applications section later in the chapter. The entry may have an attribute called workfloor that determines the floor on which the employee is working. All employees working on the first floor belong to the First Floor group. Thus, though the data may appear to be organized hierarchically, it is also grouped using attributes to affect the grouping. However, it must be noted that there is no standards for groups. A group is simply an objectclass with attributes that store the DN of entries in the organization. By interrogating the objectclass, applications can draw out the basic nodes that relate to any one group, and traverse them.
• Objects in a directory bear a close resemblance to tables. This is because all entries corresponding to objects of the same type have similar attributes, just as all records in a particular database table have the same set of fields. However, objects in directories go a little further in that they can be extended in an object-oriented fashion to add more attributes. This is something that we cannot possibly do with a database table (unless we create a new table and populate it with earlier data or use subsidiary tables).

Professional PHP4 Programming
Components of LDAP - Page 2