Replication Concepts

Understanding and Deploying LDAP Directory Services > 1. Directory Services Overview > What Can a Directory Do for You?

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078209007012167132144031219

What Can a Directory Do for You?

We've already talked about some applications of offline directory services that you deal with every day. Also, we've 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. Finding 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 ”directories organize information in this way so that it is easy to find what you are looking for. Finding things is also an important application for online directories. And as we 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 Four11 (www.four11.com), BigFoot (www.bigfoot.com), WhoWhere? (www.whowhere.com), and AnyWho (www.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, even in an application as simple as a phone book, in new and exciting ways. 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 in case you are unable to correctly spell the name you are 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 . You can also 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.

Thinking about the offline analogies again, it becomes clear that both searching and browsing are needed. When you are 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 keep alphabetized listings to make this easy. This is directory searching .

On the other hand, when you are in the mood to buy some new clothes, it is seldom the case that 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, either used together or at different times.



This flexibility of searching and browsing methods is a direct result of the directory's ability 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. These attributes might be location, color or black-and-white, print quality, size or type of paper, single- versus double-sided capability, and others. Typical interaction with the user might involve the user selecting the most important attributes (for example, color and print quality). The user can then choose from a list of printers, perhaps choosing one based on location.

As a final example of finding things, consider a client in search of a network application service. 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. 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.

The N+1 Directory Problem

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 Commerce 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 are 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 quite a troublesome and costly problem for administrators everywhere (refer to Figure 1.6).

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. 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 the pace at which they are occurring may not be as fast as you'd like. The improved situation was depicted in Figure 1.7.

Another advantage of storing user and group information in a centralized directory is enjoyed by application developers. Instead of having to develop a proprietary directory service integrated with each application, application developers can use what's already provided and focus their activities on making a better application.

Another important application of directories to the management problem relates to the task of configuration management. Historically, the configuration for an application has been kept in a set of files or an OS-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. There may be hundreds of them within a large corporation. If they share one or more configuration items, imagine the onerous task of changing the configuration in all of them. With 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 this 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 application 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. Like 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 preferences 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, by having 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 piece of configuration one night, 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 per-user 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 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 email 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 the user to have the same environment both at home and at work.

Similar requirements exist in shop floor situations or on university campuses, where kiosk access is provided to users without a dedicated machine of their own. (We use the terms "nomadic" or "roaming" to describe these types of users.) 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. This application is illustrated in Figure 1.9.

Figure 1.9 Using the 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 the next section we will 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 API access to this information is also attractive. Prior to LDAP's arrival, application developers with a need to maintain a simple database for their application had just a couple 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 duplicating 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 hard 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 helps to avoid the N+1 directory problem we 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. This reduces 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 Communicator Web and mail client. The client maintains several local databases containing user bookmarks, local address book information, security information, and other things. These all 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 Server. 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 proved to be unwieldy, hard to manage and install, and generally a poor choice. The next version of the Certificate Server used an embedded directory server to manage this database of information. This directory-based solution is much easier to install and manage, easier to develop with, and it is much more flexible.

Security Applications

Another interesting directory application is security. Of particular interest are public key “based security systems. We cover these systems in more detail in Chapter 11, "Privacy and Security Design." For now, it's enough to know that the public key infrastructure (PKI) required to provide security like this is hard 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, this task is difficult to manage.

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

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

  • The certificate location problem.   This refers to how you find the certificates of the people with whom you want to communicate securely, and how people who wish 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 ”and 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 email address. A more detailed and formal description of these problems and processes is presented in Chapter 11.



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

Index terms contained in this section

advantages
          online directories
AnyWho Web site
applications
         databases
                    lightweight 2nd
                    security 2nd
BigFoot Web site
browsing
         online directories
                    versus searching 2nd
building
         databases
                    proprietary special-purpose
centralized configuration management
          directories
certificates 2nd
commercial database packages
          embedding in directories 2nd 3rd
configuration management
          centralized for directories
databases
         applications
                    lightweight 2nd
                    security 2nd
         commercial packages
                    embedding 2nd 3rd
          proprietary special-purpose
directories
          advantages
          browsing versus searching 2nd
          certificates 2nd
         database applications
                    lightweight 2nd
                    security 2nd
         databases
                    embedding commercial packages 2nd 3rd
                    proprietary special-purpose
          location independence
          managing
          managing information 2nd 3rd 4th
          N+1 directory problem 2nd 3rd 4th
         online
                    advantages
                    browsing versus searching 2nd
                    lightweight database applications 2nd
                    managing
                    managing information 2nd 3rd 4th
                    N+1 directory problem 2nd 3rd 4th
                    searching 2nd 3rd
                    searching versus browsing 2nd
                    secure database applications 2nd
         PKI
                    (public key infrastructure) 2nd
          searching 2nd 3rd
          searching versus browsing 2nd
directories:centralized configuration management
embedding
         in directories
                    commercial database packages 2nd 3rd
finding, see searching
Four11 Web site
kiosks
         users
                    nomadic and roaming
lightweight database applications 2nd
locating, see searching
managing
         directories
                    centralized configuration management
         information
                    online directories 2nd 3rd 4th
          online directories
                    N+1 directory problem 2nd 3rd 4th
N+1 directory problem 2nd 3rd 4th
nomadic users
online directories
          advantages
          browsing versus searching 2nd
          centralized configuration management
         database applications
                    lightweight 2nd
                    security 2nd
          managing
          managing information 2nd 3rd 4th
          N+1 directory problem 2nd 3rd 4th
          searching 2nd 3rd
          searching versus browsing 2nd
PKI
          (public key infrastructure) 2nd
proprietary special-purpose databases
roaming users
searching
          online directories 2nd 3rd
                    versus browsing 2nd
security
          database applications 2nd
         of directories
                    certificates 2nd
                    PKI (public key infrastructure) 2nd
sites
         Web
                    AnyWho
                    BigFoot
                    Four11
                    WhoWhere?
users
          nomadic
          roaming
Web sites
          AnyWho
          BigFoot
          Four11
          WhoWhere?
WhoWhere? Web site

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