Understanding and Deploying LDAP Directory Services > 20. Developing New Applications > Common Ways Applications Use Directories |
Common Ways Applications Use DirectoriesBecause directory services are so flexible, applications use them in many different ways. Although not an exhaustive list, the following are some of the most common ways applications use directories:
These examples are discussed in the following sections. Locating and Sharing InformationThe most common use of directory services by applications is to locate information and share it with end users and other applications on the network. Information held in directories is typically published and maintained by a small number of people or applications, but it is accessed by many. Storing information in a shared directory service has several advantages:
Most of the directory-enabled applications mentioned in this book store some shared information in a directory. Whether the information is shared with a single management tool or with hundreds of other applications, placing it in a directory service makes it more available and easier to manage. Verifying Authentication CredentialsA simple but powerful way for an application to use a directory service is for 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 operation, in which the success or failure of the bind translates directly into success or failure of the authentication attempt within the application. Figure 20.4 shows how a Web server that is configured to serve documents only to certain people might use a directory server to authenticate users. Figure 20.4 A Web server that uses a directory to support authentication.The process illustrated in Figure 20.4 goes basically like this: The Web server obtains a user ID and password through an authenticated HTTP request. The Web server then uses LDAP to search for the user. If the search is successful, an LDAP bind operation is used to check the user 's password. The Web server then uses the result of the bind operation to decide whether to return the requested Web page or an error. Using a directory as an authentication service and sharing the directory among all applications requires end users to use only one set of authentication credentials to access all application services. This typically means that each end user needs to remember only one password or carry one certificate ”which makes users happier and leads to fewer calls to the help desk. Tip Sometimes it is inconvenient or perhaps 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 a directory service the credentials or other information required to verify each user's identity. Consider a public key “based authentication scheme. 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 each application to be aware of which certificates have been revoked. Certificates are typically revoked after a person's private key is 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 checking can be accomplished using online revocation checks done over LDAP itself; or a little more indirectly through a protocol designed for revocation checking, such as the online certificate status protocol (OCSP). One possible configuration is shown in Figure 20.5. Figure 20.5 Using a directory for certificate revocation checking.The workflow application shown in Figure 20.5 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. To ensure that the presented certificate has not been revoked, an OCSP server that is backended by an LDAP directory server is contacted. 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 ServicesBecause most directories provide secure access over a standard protocol (LDAP), they are good tools to use when you need to tie 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, it is possible to reduce the cost of providing a service. One infamous example of a technology that has proved difficult and costly to deploy is PKI, which we already discussed briefly in the last section. With PKI, increased security and greater efficiency can be achieved by putting public key certificates in the hands of end users and applications. The process of issuing, revoking, and renewing certificates for all members of an organization is commonly referred to as certificate life cycle management ”the major headache encountered in most real world-PKI deployments. By leveraging a directory service to assist in the certificate life cycle management process, products such as Netscape's Certificate Server are making PKI much more palatable. The main components of a complete PKI solution based on a directory are shown in Figure 20.6. Figure 20.6 Leveraging a directory service to facilitate PKI deployment.Certificates containing users' public keys are generated by a certificate server and published in each person's directory entry. These certificates can be accessed to support applications such as S/MIME email and to allow for online certificate revocation checking. CRLs are also published in the directory server, where they are used by one or more OCSP responders. Finally, a special attribute added to each user's entry is checked by the PKI module in each user's Web browser during application startup to see if any PKI- related actions should be taken. This feature is used to support automated renewal of certificates that are about to expire. Making Access Control DecisionsAnother way that applications can take advantage of a directory is for assistance in making decisions about who is allowed to do what. There are several advantages to using information stored in a directory service to make access control decisions:
There are several ways that applications use directories to help with access control decisions. One approach is for the application to store a set of access control rules locally that refer to certain directory information (such as user and group entries). For example, a Web server such as Netscape Enterprise Server 3.5 stores access control rules with the documents it serves from a local file system. Enterprise Server's access control rules can also, however, refer to user and group entries that are stored in an LDAP server (see Figure 20.7). Figure 20.7 How Netscape Enterprise Server 3.5 uses LDAP for access control.Evaluation of access control rules is performed 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 that access control is applied to. A second method is for the application to store its own application-specific access control information in a directory. The information is read from the directory and evaluated by the application. This approach is used by Netscape's Collabra Server (see Figure 20.8) as well as Netscape Enterprise Server 4.0. The Collabra server is a high-performance, easy-to-manage news server that speaks the Network News Transfer Protocol (NNTP). Figure 20.8 How Netscape Collabra Server uses LDAP for access control.As it turns out, Collabra Server's access control rules can refer to user and group entries much as Enterprise Server 3.5's rules can. But, because the access control information is stored in a shared directory that can be replicated, access control information can be centrally managed and shared with other instances of the application or with related applications. A third method is to take advantage of the access control evaluation features of the directory service itself. This is accomplished by representing in the directory service the objects or tasks for which access control needs to be enforced. By installing appropriate access control rules on the entries and authenticating as the person requesting access, the application can use the success or failure of an LDAP operation to grant or deny access to an end user. An example of this approach is shown in Figure 20.9. The computer system management application shown allows the user to perform a task if, and only if, the user is granted read access to a corresponding task entry stored in the directory service. Figure 20.9 Enforcing access control on a set of tasks.The Netscape Console, which is used for managing many of Netscape's products, uses this third 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 typically includes all these things out of the box. 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 of this approach, however: Because access control is not yet part of the LDAP standard, writing an application that leverages directory access control ties the application to a specific LDAP server implementation. Enabling Location IndependenceAn increasingly popular way 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 are using and where they are connected on the network. As long as the directory can be accessed securely from anywhere on your organization's network, your directory service is a perfect tool for implementing location independence. Then, you can simply write your applications to store all the configuration and preferences information in an LDAP directory server ”instead of the typical local disk or something like the Windows Registry. 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 this is Netscape Communicator 4.5. Like traditional applications, Communicator can store end user preferences (called user profiles ) in a local file system. Communicator can also be configured to retrieve user profile information from an LDAP server (see Figure 20.10). Figure 20.10 Using a directory service to enable location independence.When configured 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.
|
Index terms contained in this sectionaccess controlsapplications 2nd application-specific information storage 2nd directory service evaluation features 2nd local storage 2nd applications access control decisions application-specific information storage 2nd directory service evaluation features 2nd local storage 2nd 3rd deployment aiding in 2nd 3rd public user keys locating and sharing information 2nd 3rd location independence (roaming) enabling 2nd 3rd verifying authentication 2nd 3rd 4th 5th 6th 7th 8th certificates authentication revocation checking verifying life-cycle management deployment aiding with applications certificate life cycle managment PKI public user keys directories applications access control decisions 2nd 3rd 4th 5th 6th 7th 8th enabling location independence (roaming) 2nd 3rd locating and sharing information 2nd 3rd verifying authentication 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th enabling location independence with applications 2nd 3rd evaluation features directory service access controls Netscape Console life-cycle management certificates locating information with applications 2nd 3rd location independence (roaming) enabling with applications 2nd 3rd Netscape Communicator 4.5 roaming Netscape Console directory service access controls PKI aiding in deployment with applications PKI designs verifying profiles user roaming roaming (location independence) enabling with applications 2nd 3rd security authentication verifying with applications 2nd 3rd 4th 5th 6th 7th 8th sharing information with applications 2nd 3rd users profiles roaming public keys aiding in deployment with applications verifying authentications with applications 2nd 3rd 4th 5th 6th 7th 8th |
2002, O'Reilly & Associates, Inc. |