The Importance and Role of LDAP in Security

Every organization requires a mechanism that keeps track of entities within the organization, such as individual employees, departments of employees, and assets such as buildings, meeting rooms, equipment, and so on. This structure often exists in the form of a directory, which provides contact information for all members of the organization. Before computers were ubiquitous in the business world, these directories often were just private telephone books that presented one view of the organizational structure, usually an alphabetical list of employees and associated contact information. If the organization was large enough, a section might have been included listing departments, sections of a building, phone numbers for conference rooms, and so forth. Publishing such a directory was frequently the responsibility of a single person or team; the larger the organization, the more daunting the task.

With the increased use of electronic business tools such as pagers, cell phones, and e-mail, maintaining such a directory became even more daunting. Employees today do not have just a phone numberthey have several pieces of contact information. The need arose for an electronic directory that could hold various types of contact information and be structurally flexible so that maintenance could easily be performed.

LDAP (Lightweight Directory Access Protocol), based on the X.500 directory standard, is a standard directory structure and protocol. LDAP provides a standard electronic directory service that is implemented by many vendors and used by many companies. The X.500 directory standard came about in 1988 through the work of the International Organization for Standards (ISO) and the International Telecommunication Union (ITU). One of the main concepts in X.500 is that a directory is a hierarchical structure of objects, where an object represents an employee, an asset such as a piece of equipment, or any other entity. Another concept is that the directory is structured in such a way that each section of an organization is responsible for maintaining only its piece of the directory structure. Related to this decentralization is the hierarchical structure, which guarantees that each object has a "parent" responsible for creating and maintaining the object. This is an important point, because one of the pieces of information associated with an employee may be a public key (discussed earlier in this chapter).

The communication between users and the directory structure employs the Directory Access Protocol (DAP). However, the X.500 standard and associated DAP protocol was deemed by many to be far too complicated to implement. LDAP was developed at the University of Michigan in 1995 to offer a lightweight version of the DAP for accessing X.500 directories over TCP/IP. LDAP has quickly become the de facto electronic directory standard.

Earlier in this chapter, the discussion of asymmetric ciphers included the use of public keys and the difficulties in verifying the owner of a public key. One method for assuring the authenticity of the public key and verifying its owner's identity is to present the public key in the form of a digital certificate, where a trusted third party vouches for the owner's identity and binds a digital certificate to the owner's public key. This is done by digitally signing a document that contains the owner's identity and public key. The challenge, then, is to publish or make available the certificate to the public.

LDAP's flexibility makes it possible to store digital certificates along with the rest of an employee's information. It can also be used to publish a digital certificate chain structure for all members of an organization. The LDAP protocol's roots stem from the X.500 directory standard. That is the same standard from which the X.509 digital certificate (widely used by SSL and S/MIME protocols) comes. The two technologies thus work together smoothly.

Figure 2-12 presents a simple example of an organizational hierarchy with digital certificates for each member. Each member's public key (contained within the digital certificate) is signed (and is assumed to be verified) by the "parent" member in the hierarchy. The certificate authority of the organization verifies the public key for the different offices in the organization, such as Washington, Los Angeles, and Chicago. Each office, in turn, is responsible for its portion of the directory structure, including digital certificates. For example, the Los Angeles office maintains departments within its areaMarketing, IT, and Human Resources. Each of these departments' digital certificates are signed by an authority for the entire office. Marketing, in turn, maintains the employee directory structure within its area, and therefore the head of Marketing signs each of that department's employees' certificates.

Figure 2-12. Example LDAP Hierarchy

Note that at the top of the hierarchy is the certificate authority, which has no parent node. Its digital certificate is signed by itself and therefore is the root certificate. The root certificate is widely distributed, and its public key value is well-known; from it, all other certificates can be verified.

As an example, suppose Q. McCluskey in Corporate needs to send a secure e-mail to L. Gilroy in Government Services. Q. McCluskey verifies L. Gilroy's certificate by obtaining a certificate chain that includes L. Gilroy's certificate, Government Services' certificate, Washington's certificate, and the CA master certificate. If each certificate signature checks out, L. Gilroy's certificate is validated.

The Role of LDAP in J2EE

LDAP also plays an important role in Java 2 Enterprise Edition (J2EE) applications. LDAP is the preferred directory service provider for J2EE's Java Naming and Directory Interface (JNDI) requirements. JNDI is an enterprise Java API that provides naming and directory functionality using a common set of classes and interfaces that are independent of a specific naming and directory service implementation [Moraes]. The J2EE specification requires that JNDI be used for the application component's naming environment. For instance, remote interfaces to Enterprise Java Beans (EJBs) can be obtained across a J2EE cluster by retrieving them using a JNDI API call to a common LDAP store. This allows Java objects in one instance of an application server to locate and invoke operations on Enterprise Java Beans (EJBs) in another instance. Other service providers, such as Databases, can be used as well, but LDAP is best suited for the task based on its market share and the fact that it is generally the best performing service provider.

LDAP is also commonly used to store policies, access control lists, and user information in J2EE applications. Many application servers ship with built-in LDAP directories, and all support external LDAP directories. Access control information is often stored in LDAP alongside the user information. Because of LDAP's universality, LDAP-enabled directories have become the de facto standard for managing user information across the enterprise.