Directory Coexistence Checklist

Understanding and Deploying LDAP Directory Services > 20. Developing New Applications > Common Ways Applications Use Directories

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012002230017026229248246131

Common Ways Applications Use Directories

Because 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:

  • 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 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:

  • Maintenance of the information can be performed over the network using LDAP, and management tasks can be easily distributed to a large number of people.

  • Multiple instances of the same application and instances of unrelated applications can access the data no matter where they reside on the network.

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

  • Management of all information about people and resources can be consolidated in one logical location and managed in a consistent way using LDAP directory-enabled management interfaces (instead of residing in a number of different applications that each has its own access methods and management interfaces).

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 Credentials

A 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 Services

Because 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 Decisions

Another 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:

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

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

  • When appropriate, information maintained for access control purposes 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.

  • The access control information can be replicated and made available through several directory servers to meet applications' performance and reliability needs.

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 Independence

An 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.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

access controls
          applications 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.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net