June 21, 2018
Hot Topics:

Introduction to LDAP (Lightweight Directory Access Protocol)

  • April 25, 2003
  • By Manning Publications Co.
  • Send Email »
  • More Articles »

1.3.2 Authentication and authorization

It is virtually impossible to discuss user access and system security today without LDAP being part of the conversation. Although it isn't as visible to the casual user, LDAP is emerging as the de facto way to access the identity information and credentials needed to support authentication. Authentication is the process of validating the identity of a user (or any other object, such as an application).

This process allows identity information to be managed and distributed much more easily than via traditional means. Information stored in an LDAP-enabled data store can be segmented for simpler management while presenting a unified view to applications and authentication services.

Using LDAP also has the benefit of reusing identity information. This approach offers a significant advantage over authentication processes that use an operating system or proprietary mechanism. For example, using LDAP allows both Unix- and Windows-based servers running a particular application to authenticate users in the same manner and from the same repository. In effect, application development time is reduced, authentication code is relatively static between platforms, and the administrative cost of managing two identity repositories is removed. Figure 1.6 shows how an application might use LDAP to authenticate a user.

Figure 1.6
Bob Smith uses a browser to access information on a protected web server. The web server first binds to the LDAP directory to authenticate him.

After authenticating, it is possible to use other available information about the authenticated user (such as department, company, age, and so on) to determine whether he or she is authorized to perform a particular action on resources within a particular computing environment or application.

We will cover the use of LDAP as an authentication and authorization resource in chapter 13. This discussion will include more sophisticated authentication mechanisms, single sign-on issues, and many other related security concerns.

1.3.3 Personalization

Once a person has been identified through authentication, it is useful to personalize the user's experience based on their identity and preferences. In some cases, personalization may simply mean placing the current user's name at the top of a web page. A more sophisticated use might be to pull the customer's location information from the directory to prepopulate an order form.

In a complex web environment with a variety of features, LDAP-enabled directories are a useful place to store information about users' preferences. For example, you might allow users to choose a particular product line as their primary interest when a site covers a large number of products.

Capturing this information and enabling access to it via LDAP allows a variety of applications to customize users' experiences based on their interests. Doing so offers an important benefit: personalized content can be consistent between multiple applications.

LDAP has been gaining wide acceptance as a place to store and retrieve personalization information in enterprise applications. For example, most enterprise portals support LDAP as a means of obtaining the information needed for personalization.

1.3.4 Roaming profiles

Closely related in many respects to personalization, but focused more on operational preferences than content preferences, is the concept of roaming profiles. Roaming profiles allow users to authenticate to an application on any machine and get an identical environment. You do so by storing considerable individual configuration options in a directory.

In addition to enabling roaming, directory-based security also offers the potential to lock down certain configuration items or create organizational or group defaults. In environments with less-sophisticated users, doing so makes it possible to update user configurations without a system administrator needing to make a trip to each cubicle or spend time on the phone walking a user through complicated steps within an application.

Few stand-alone applications provide roaming profiles. Part of the reason is that most applications vary widely in their configuration. Thus each application may require additional information in the directory server to enable storage of that application's configuration values.

This requirement showcases a common conflict between application developers, who often want to change schema to meet their applications' needs, and system administrators, who realize that changes in schema require a great deal of administrative effort. The challenge is deciding where to draw the line between generally useful information that belongs in a directory and application specific information that belongs elsewhere. We will discuss this conflict further in chapter 2.

1.3.5 Public Key Infrastructure

Traditional authentication and encryption systems use secret keys. Generally speaking, a secret key system requires both ends of a communication to know a secret password that will be used to hide the communication. The right secret password produces a legible message, which both protects the message in transit and proves that the message must have been written by the other party, because they were the only other ones with knowledge of the secret. This approach works well as long as the secret isn't compromised and you communicate with few enough people that you can remember a shared secret with each one.

Public key technology changes all this and makes the process more scalable. In this system, two keys are produced. One key, called the private key, is still secret. However, unlike the secret key in a shared-secret system, the private key is never shared with anyone. Instead, a second key called the public key is distributed. A public key can be placed in a digitally signed container called a digital certificate. Such certificates are commonly used to distribute public keys.

A successful deployment of public key infrastructure is highly dependent on a well-designed directory services infrastructure. An LDAP-enabled directory answers the question of where to store and locate digital certificates. Centrally storing digital certificates in a directory allows people and applications to find certificates on demand for business partners and peers with whom they need to communicate securely.

In addition to helping you locate certificates for encryption, directories let you find a list of certificates that have been revoked prior to their expiration time. These certificate revocation lists (CRLs) are commonly stored in LDAP-enabled directories.

This book is not specifically about Public Key Infrastructure (PKI), but PKI is one common application that uses directories. We discuss the use of directories with PKI in much more detail in chapter 13.

1.3.6 Message delivery

On the Internet, messages are routed based on the fully qualified host name to the right of the at sign (@). Such routing is typically done by using the DNS to identify the IP address associated with the human-readable fully qualified host name.

Once a message has been routed to the correct machine, it is delivered on that machine based on the username to the left of the @. Many mail systems now support the use of LDAP to determine how to deliver a message.

The delivery process can include advanced operations, such as locating the exact mail drop for the user in a cluster of mail servers. However, the most common usage is for allowing full-name email aliases and implementing email lists.

As mentioned in section 1.3.3, directories can help you target mailings based on information associated with identities. In an LDAP directory, users are often placed together in groups, either as a list of users or as a dynamic specification (such as all users in department A). These groups can be used for authorization, personalization, and even mailing lists.

We discuss group schemas in chapter 2. Examples of managing groups appear in chapter 7.


The previous section makes it obvious that there are a wide variety of uses for LDAP-enabled directory services. Many of these uses first came about with earlier standards—particularly X.500, which we mentioned briefly earlier in this chapter. In this section we will take a quick look at how LDAP came to its latest incarnation.

1.4.1 X.500 and DAP

LDAP is a TCP/IP-based client/server directory access protocol originally based on a subset of the X.500 Directory Access Protocol (DAP). X.500 is a comprehensive set of standards from the ITU Telecommunication Standardization Sector (ITU-T) that describes all aspects of a global directory service. X.500, like many standards, has gone through many revisions; work is still in progress to update it further. As shown in figure 1.7, a client originally talked to an X.500 server using the DAP protocol.

Figure 1.7
The X.500 client uses DAP to communicate with the X.500 Directory System Agent (DSA).

Designed to be the standard directory service for the Open Systems Interconnection (OSI) world, X.500's fortune has risen and fallen over the years, but it still has a substantial following. Early on, X.500 was accepted by many large information technology (IT) organizations as the direction for global directory services. Although early products had their problems, they also showed a great deal of promise. Many large companies and universities implemented pilot projects, usually involving the hosting of white pages.

One big issue arose very quickly with X.500: the fact that its access protocol required an OSI protocol stack and complex binary encoding of structures represented in a language called Abstract Syntax Notation One (ASN.1). Most desktop computers at the time were ill equipped to deal with DAP.

As Internet Protocol (IP) became the dominant networking standard, DAP's OSI origins made it less attractive. Many of the organizations piloting X.500 directories had already adopted IP and were looking for a protocol with less baggage for client access. Even worse, X.500's complexity and the lack of freely available standards documents or easy-to-use APIs made it difficult to develop clients without paying fees to the ITU-T.

As we've stated since the beginning of this chapter, even the best directory is useless when applications are not available to take advantage of it. Several white pages applications were available, but an electronic phone book is often not enough to justify the expense of collecting and cleansing all the information necessary to make a directory truly useful.

Page 3 of 6

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.


We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date