Common Ways That Applications Use Directories

Because directory services are so flexible, applications use them in many different ways. Some of the most common tasks for which applications use directories include the following:

• Locating and sharing information

• Verifying authentication credentials

• Aiding the deployment of other services

• Making access control decisions

• Enabling location independence

These examples are discussed in the following sections.

Locating and Sharing Information

The most common use of a directory service is to locate and share information among end users and networked applications. Information held in directories is typically published and maintained by a small set of people and applications, but it is accessed by many. Storing information in a shared directory service has several advantages:

• The information can be maintained over the network with LDAP, and management tasks can be distributed to many people.

• Multiple instances of the same application, as well as instances of unrelated applications, can access the data no matter where they are on the network.

• Access control provided by the directory service can be used to ensure that each person and each application has only the necessary and appropriate level of access to information.

• Information about people and resources can be consolidated into one logical location and managed in a consistent way through the use of directory-enabled management interfaces.

Most of the applications mentioned in this book do store some shared information in a directory. Whether the information is shared with just one management tool or with hundreds of other applications, placing it in a directory service makes it more widely available and easier to manage.

Verifying Authentication Credentials

A simple but powerful use of a directory service is to provide authentication. The basic idea is for the application to ask the directory to verify authentication credentials presented by users or by other applications. This can usually be done through an LDAP bind request, in which the success or failure of the bind translates directly into success or failure of the authentication attempt within the application.

Figure 21.3 shows how a Web server might use a directory server to authenticate users before allowing access to a set of documents. The process goes like this:

Step 1. The Web server obtains a user ID and password through an authenticated HTTP request sent by a Web browser or a Web services application.

Step 2. The Web server sends an LDAP search request to find the user.

Step 3. The server responds to the search request.

Step 4. If the search is successful, the Web server sends an LDAP bind request to check the user's password.

Step 5. The server responds to the bind request.

Step 6. The Web server uses the result of the bind operation to decide whether to return the requested Web page or an error.

Figure 21.3. A Web Server That Uses a Directory for Authentication

Tip

Sometimes it is inconvenient or less secure to ask a directory server to verify a user's authentication credentials on behalf of the application. In this case it may still make sense to store in the directory service the credentials or other information required to verify each user's identity. That way, the authentication credentials can be shared among all of the applications that need them even if the directory itself is not being used to check the authentication credentials.

Using a directory as a shared authentication service allows end users to access all application services with just one set of authentication credentials. Typically this means that each end user needs to remember only one password or carry one public key certificate ”which makes users happier and leads to fewer calls to the Help Desk.

As an example of using a directory service to store authentication credentials, consider a public key certificate-based authentication system that needs to do revocation checking. Usually an application can itself verify that a certificate presented by an end user is valid and not expired , but it is more difficult for an application to know which certificates have been revoked. Certificates are typically revoked after a person's public key has been compromised or when a person leaves an organization. In traditional public key infrastructure (PKI) designs, certificate revocation lists (CRLs) must be distributed to every application. If certificates or CRLs are stored in a directory service, revocation can be checked by online revocation checks done over LDAP itself, or indirectly through a protocol designed for revocation checking, such as the Online Certificate Status Protocol (OCSP). Figure 21.4 shows one possible configuration.

Figure 21.4. Using a Directory to Check for Certification Revocation

The workflow application shown in Figure 21.4 uses public key certificates for authentication, and it verifies the authenticity of the certificate using locally stored information about the certificate authority (CA) that signed the certificate. An OCSP server that has an LDAP directory server on the back end is consulted to ensure that the presented certificate has not been revoked. The OCSP server's job is to tell applications whether a certificate is still active and whether it should be honored.

Aiding the Deployment of Other Services

Because most directories provide access to data over a standard protocol (LDAP), directories are helpful in tying together a set of cooperating applications. This property of directories is especially important if you work with computing services that have historically proven to be costly to deploy and maintain. By using a directory service to facilitate self-service by end users, as a rendezvous point for a set of cooperating applications, and as a central point for service management, you can reduce the cost of providing a service.

One infamous example of a technology that has proven difficult and costly to deploy is PKI, which we already discussed briefly in the previous section, Verifying Authentication Credentials. With PKI, you can increase security and improve efficiency by issuing public key certificates to end users and applications. The process of issuing, revoking, and renewing certificates is commonly referred to as certificate life cycle management ” the major headache encountered in most real-world PKI deployments.

By using a directory service to assist in the certificate life cycle management process, products such as the Netscape Certificate Management System (CMS) are making PKI much more palatable. Figure 21.5 shows the main components of a complete PKI solution based on a directory.

Figure 21.5. Using a Directory Service to Facilitate PKI Deployment

You can create certificates containing users' public keys by contacting the registration manager. The certificate manager component publishes user certificates by adding them to each person's directory entry so that they can be used by applications such as S/MIME e-mail. CRLs are also published in the directory server, where they are used directly by applications or through a set of OCSP Manager responders. Finally, when a Web browser is launched, the PKI module within it checks a special attribute in the user's directory entry to see if any PKI-related actions should be taken. The last technique is used to support automated renewal of certificates that are about to expire, and to initiate any other PKI- related process that requires the user to do something.

Making Access Control Decisions

Another way that applications can take advantage of a directory is to help make decisions about who is allowed to do what. This decision-making process is usually referred to as authorization or access control . Directory services offer several advantages in assisting with access control decisions:

• Administration of the access control information can be distributed among several people, and a new protocol does not need to be invented for maintenance. LDAP itself does the job nicely .

• The information on which access control is based can be shared by several applications, so redundant access control information is eliminated, thereby reducing management costs and lowering security risks.

• When appropriate, access control information can be used for related purposes as well. For example, a group can be used both to perform access control checks and to distribute electronic mail.

• To meet the performance and reliability needs of applications, the access control information can be made widely available through directory replication.

Applications use directories in several ways to help make access control decisions. One approach is for the application to store a set of access control rules locally that refer to directory information (such as user and group entries). For example, a Web server such as Netscape Enterprise Server 6 stores access control rules in a local file system with the documents it serves up. However, Enterprise Server's access control rules can refer to user and group entries that are stored in an LDAP server. Figure 21.6 shows a installation of Enterprise Server that is configured to use LDAP to assist with access control.

Figure 21.6. How Netscape Enterprise Server Uses LDAP for Access Control

Access control rules are evaluated locally by the Web server, and information about users and groups is retrieved from the directory as needed. Some advantages of this approach are that the application is free to implement an access control scheme that perfectly fits its needs, and the access control information itself can be stored close to the objects to which access control is applied.

A second approach is for the application to store its own application-specific access control information in the directory service. The information is read from the directory and evaluated by the application. Figure 21.7 shows an application that uses this approach.

Figure 21.7. An Application That Stores Access Control Rules in an LDAP Directory Service

Two instances of the same application are running on two different application servers. The access control information for the application, as well as the user and group information, is obtained from the LDAP directory server. Because the access control information is stored in a shared directory that can be replicated, the information can be centrally managed and shared among all instances of the application (or with related applications).

A third approach for using a directory service to support access control is for the application to take advantage of the access control evaluation features of the directory itself. In this case the objects or tasks for which access control needs to be enforced are represented in the directory service. Appropriate directory access control rules are created to govern access to these entries. After authenticating as the entity that is requesting access, the application can use the success or failure of an LDAP operation to grant or deny access. Figure 21.8 shows an example of this approach. The computer system management application shown allows the user to perform a task only if the user is granted read access to a corresponding task entry stored in the directory service.

Figure 21.8. Controlling Access to a Set of Tasks

Netscape Console, which is used for managing many of Netscape's server products, uses this approach. One advantage of leveraging the directory service's access control evaluation machinery in this way is that the application doesn't need to implement an access control evaluation engine, design a syntax for access control rules, or provide specialized tools for creating and editing the rules; directory server software vendors typically provide all these things. As long as the access control features provided by the directory software meet the needs of your application, this approach can save a lot of work. There is one disadvantage to this approach, however: Until access control is made part of the LDAP standard, writing an application that uses directory access control may tie the application to a specific LDAP server implementation.

Enabling Location Independence

An increasingly popular reason for software developers to use LDAP is to enable location independence features in their applications. Location independence, or roaming , is achieved when end users and network applications can access the information they need (such as application preferences) regardless of the machine they're running on and where they're connected to the network. As long as the directory can be accessed securely from anywhere on your organization's network or on the Internet (for an outward- facing directory application), your directory service is a good tool for implementing location independence. Instead of storing configuration and preference information in local files or the Windows Registry, your applications can store them in an LDAP directory.

Location independence is a powerful feature that promises to unchain end users from their desktops and allow effective roaming within the network. A good example of an application that demonstrates these benefits is the Netscape Communicator Web browser and e-mail suite. Like traditional applications, Communicator can store end-user preferences (called user profiles ) in a local file system. However, as shown in Figure 21.9, Communicator can also be configured to retrieve user profile information from an LDAP server.

Figure 21.9. Using a Directory Service to Enable Location Independence

When configured in this way, the Communicator application asks the end user for a name and password at startup. It uses this information to authenticate with a directory server, and then it downloads the user's profile information to the local disk, where it is cached. If the user makes any changes to his or her preferences while using Communicator, the changed information is written back to the directory service. For example, if the user adds or deletes a bookmark, the new bookmark data is recorded in the directory.