What a Directory Can Do for You

We've already talked about some applications of offline directory services that you deal with every day. We've also talked about how these same applications can be improved, and sometimes revolutionized, by the timely update capabilities, extensible nature, and personalization possibilities of online directories. Now it's time to turn our attention fully to this exciting aspect of online directories: the types of new applications that can be developed to take advantage of all the capabilities of the online directory.

Finding Things

As mentioned at the beginning of this chapter, most everyday directories are aimed at the problem of finding things ”for example, the right book in the library or the telephone number of your friend or a business you want to contact; the right style, size , and color of shirt you want to order from a catalog; or the time and channel of the television show you want to watch tonight. Traditional types of directories organize information so that it is easy to find what you are looking for. Finding things is also an important application for online directories. And as you will see, online directories have capabilities that allow far more advanced ways of finding things.

Perhaps the most basic and best- understood application of an online directory is the online analogy to a phone book. Directories in this category start on one end with the large Internetwide or countrywide directories provided by Internet directory service providers, such as Switchboard directory (switchboard.com), Yahoo's People directory (people.yahoo.com), Bigfoot (bigfoot.com), Lycos's WhoWhere? (whowhere.lycos.com), and AT&T's AnyWho (anywho.com). On the other end of the spectrum, you can apply directory technology to create a local phone book for your organization. The service provided by these directories is remarkably similar to the analogous paper directories, with some important differences.

First, online directories let you greatly increase the scale and coverage of the directory. The Bigfoot directory, for example, contains essentially every phone book in North America. Try keeping that many phone books in your house for quick and easy reference! More importantly, online directories allow you to organize information in new and exciting ways, even in an application as simple as a phone book. For example, you can use your directory to search by name, phone number, address, and other information not even contained in a traditional phone book. You can also perform new kinds of searches if you don't know the correct spelling of the name you're looking for, if you think the phone number you have might be off by a digit, or if you have only part of a name . In addition, you can browse the contents of the directory in different ways.

Searching versus Browsing

Directories usually support both searching and browsing, but you must take into account their differences.

In thinking about the offline analogies again, it becomes clear that both searching and browsing are needed. When you're looking for the phone number of Pete's pizza delivery service, you know what you want and you want to go right to the answer. Phone books provide alphabetized listings to make this easy. This is searching .

On the other hand, when you're in the mood to buy some new clothes, seldom do you know exactly what you want. You probably have some general characteristics in mind (you know what you like and are in the mood for). It is unlikely that you know the make and model of the shirt you want to buy. You want to flip through the pages of a catalog, looking at pictures of clothes until you come to what you want. This is browsing .

Browsing and searching are not mutually exclusive. Often you perform some kind of search to narrow down the choices, which you then browse. Sometimes the reverse is true: You browse some possibilities to find the place where you want to search. The important point to remember is that browsing and searching are complementary. Some applications require one, some the other. And some applications require both, used either together or at different times.

This flexibility of searching and browsing methods is a direct result of the directory's capability to organize information in different ways simultaneously . This kind of flexibility is important in a wide variety of applications. Consider, for example, a network printing application. This application allows users to choose the desired attributes of a printer. The attributes might be location, color or black-and-white, print quality, size or type of paper, single- or double-sided capability, and others. Typical interaction with the user might involve the user's selecting the most important attributes (for example, color and print quality). The user can then choose from a list of printers, perhaps selecting one based on location.

As a final example of finding things, consider a client in search of a service on the network. This service might be a database service, an employee benefit enrollment service, a stock reporting or trading service, an online dating service, a discipline-specific research service, or just about anything else. As long as these services register themselves with the directory, users or other application programs can later query the directory to locate the services. The directory's online update capability allows users to find the services they need even when those services change locations. The service simply updates the directory with its new location.

Managing Things

One application topic that sets online directories apart from their offline counterparts is information management. Online directories provide a big piece of the management puzzle in a distributed environment, providing a central repository for objects that need to be managed. The example cited most often in this category is the expensive task of user and group management ”one of the most important management services a directory can provide. A centralized directory can help reduce costs of this service substantially.

Until recently, just about every application you deployed came with its own incompatible directory. Mail applications such as cc:Mail, groupware applications such as Lotus Notes and Microsoft Exchange, and even earlier versions of Netscape's Web server all came with their own directory. Unix, too, was not immune, with applications such as sendmail using the /etc/aliases database. Although this situation is convenient if you're installing only one application, it quickly becomes unmanageable as the number of directories in your environment increases .

Imagine that you have a user needing access to all the applications you have installed on your network. The user must be added to all the application-specific directories. If any information about the user changes, it must be changed in all these directories. This is known as the N+1 directory problem ; that is, each new application adds one more directory to manage. This is a troublesome and costly problem for administrators everywhere (refer to Figure 1.6). End users are also inconvenienced; for example, suppose that there are 24 directories and each one stores a copy of a user's password. In the absence of some kind of synchronization solution, changing one password will not affect the other 23.

Consider how this situation changes when you install a centralized directory. In this case you need to enter or change user information in only one place. As new applications are added to the network, they use the centralized directory instead of their own. Passwords are stored and changed in one place. Of course, the flaw in this beautiful plan is clear: All applications must be rewritten to use a centralized directory, at least as an option, rather than their own proprietary directories. These changes are taking place, although perhaps not as fast as you'd like. The improved situation is depicted in Figure 1.7.

Application developers also benefit from storing user and group information in a centralized directory. Instead of having to develop a proprietary directory service integrated with each application, application developers can use what's already provided and focus on making a better application.

Another important area where directories can help solve the management problem is configuration management. Historically, the configuration for an application has been kept in a set of files or an operating system “specific repository such as the Microsoft Windows Registry. This solution is simple to implement and works just fine for many applications. But network applications often have different needs, especially when deployed in large numbers .

Consider, for example, a network of Web servers. A large corporation may have hundreds of them. If they share one or more configuration items, imagine the onerous task of changing the configuration in all of them. In the configuration file approach, you would need to visit each Web server and edit its configuration file. With hundreds of servers, this task would indeed be tedious . You could develop an ad hoc configuration management system based on tools, such as rdist and rsync, but the system itself needs to be managed.

Now consider the implications of these servers storing their configuration information in the centralized directory. First, remote management of the server becomes possible; the server's configuration can be accessed from anywhere on the network. Second, the configuration can be shared among servers, making cluster management of servers possible. In our earlier example, the hundreds of Web servers could have their configuration changed quickly and easily from a central location. An example of this scenario is shown in Figure 1.8.

Figure 1.8. Using a Directory for Centralized Configuration Management

A similar and potentially more powerful application of directory-based management is in the area of user configuration and preferences. As with application configuration, user preferences have historically been maintained in configuration files or local databases, such as the Microsoft Windows Registry, dot files in home directories on Unix, and Macintosh preference files. In an environment where centralized user configuration management is important (and there are many such environments), this proves to be a rather inconvenient solution. However, if applications store and read this information from the directory, thousands of user configurations can be changed at one time. Imagine being able to change a configuration setting one night in one place, and the next day when your users arrive and start their applications, the configuration is seamlessly changed.

When this approach is combined with the storage of user-specific state information in the directory, location independence can be achieved. This is an important feature in many environments. Consider a user who accesses applications from both a machine at home and one at work. The user probably has her preferences set up just the way she prefers. Perhaps she has a personal e-mail address book she needs to access from each location, or personal bookmarks in her Web browser. Storing these things in a directory and retrieving them from the network allows a user to have the same environment both at home and at work.

Similar requirements exist in shop floor situations, in hospitals , or on university campuses, where kiosk access is provided to users who do not have dedicated machines of their own. We use the term roaming to describe this type of user; the emerging practice of not providing fixed office space for workers is sometimes called hoteling . IS professionals and others who find themselves in front of many different machines in the course of a normal day can also benefit from location independence enabled by a directory. Figure 1.9 illustrates this application.

Figure 1.9. Using a Directory to Provide Location Independence

Lightweight Database Applications

In the first section of this chapter we described a directory by comparing it to a database. In this section we go into more detail about the differences between the two.

Directories are good at storing and retrieving relatively small pieces of information. The fact that LDAP directories provide a standard protocol and a standard API to access this information is also attractive. Prior to LDAP's arrival, application developers who needed to maintain a simple database for their application had just a couple of choices:

• Build a proprietary special-purpose database . This approach means extra work for the application developer and the application administrator who must install and maintain the database. It also means a lot of wasted time solving problems that have already been solved .

• Embed a commercial database package . This approach is more attractive because it generally involves less work for the application developer and avoids duplication of existing efforts. However, it can still be inconvenient for users and administrators who have to install and maintain the database. Embedding a full-fledged database such as Oracle is overkill and comes with a high price tag. Other simpler, embedded databases exist, but they are usually proprietary and difficult to integrate.

Embedding a simple directory server can often solve the same problems with some distinct advantages. Directories are generally smaller, less complex applications than full-fledged databases. LDAP directories provide a standard access protocol, meaning that your application can work with other directories, and other applications can work with your directory. This approach helps to avoid the N+1 directory problem described earlier.

LDAP directories also provide de facto (soon-to-be-official) standard APIs you can use to access the directory, making your application more portable. The result is a reduction in the amount of work required for application programmers to embed directory services in an application.

One example of an embedded database like this can be found in Netscape's Web browser and mail client. The client maintains several local databases containing user bookmarks, local address book information, security information, and other information. All of these bits of data used to be stored in separate proprietary databases, meaning that the information could not be shared and could not be accessed from anywhere but the local machine. Introducing a directory server to store the information solves both of these problems.

Another example of an embedded database is found in the Netscape Certificate Management System. This server maintains a database of certificates it has issued to users. Version 1.0 of the product stored these certificates in an Informix database. This approach proved to be unwieldy, difficult to manage and install, and generally a poor choice. Now the certificate server uses an embedded LDAP directory server to manage this database of information. This directory-based solution is much easier to install and manage, easier to develop with, and much more flexible.

Security Applications

Another interesting directory application is security. Of particular interest are public key “based security systems. Chapter 12, Privacy and Security Design, covers these systems in more detail. For now, it's enough to know that the public key infrastructure (PKI) required to provide security like this is difficult to manage. PKI requires a way to distribute security objects such as certificates to clients and servers, to keep those security objects up-to-date, to revoke them when they are compromised, and to handle other functions. Without a directory, these tasks are difficult.

Directories help solve two problems that certificates and PKI in general introduce:

1. The PKI life cycle management problem . This problem has to do with how certificates are created, maintained, and destroyed . Without a directory, this process is up to you to manage. If you're lucky, you might have some proprietary software acting on your behalf that helps manage the process for you.

2. The certificate location problem . This problem has to do with how you find the certificates of the people with whom you want to communicate securely, and how people who want to communicate with you find your certificate. Without a directory, you and your friends might have to resort to calling each other on the phone and reading off strings of hexadecimal (base 16) digits to each other.

Introducing a directory helps solve these two problems. The directory acts as a central point of administration throughout the PKI life cycle. Your various security objects can even live in the directory, where you or an administrator you trust can maintain them. When you need a new certificate, one can easily be issued to you through the directory. When your certificate needs to be revoked , again the directory provides the means to do so quickly and efficiently , along with the means by which other parties can be notified of the change.

The directory also helps locate the certificates of others. In this application, the certificate or other security information is just another attribute of a user's directory entry. A certificate can be retrieved from the directory as conveniently and efficiently as a name, phone number, or e-mail address. A more detailed and formal description of these problems and processes is presented in Chapter 12.