Directories

Information system directories are everywhere. Most systems have multiple directories for address books, password files, lists of authorized users for particular applications, and so on. Even the much-maligned Windows registry is a directory. IT departments maintain large, enterprise-wide directories. In fact, the average IT organization maintains dozens of different directories of all types.

A directory service is a network-aware directory that allows a directory to be centrally managed and, at the same time, supply directory information to distributed applications. While we typically think of directories associating information with people, directories are useful for a wide range of IT and business needs. As such, directories are a critical part of the identity management infrastructure in most organizations.

A directory service contains a structured repository of information, often with complex interrelationships. The structure is defined in a schema : the metadata that defines the overall relationship of each piece of data stored in each entry in the directory to the others. The schema defines a structure within which the data is stored.

The schema specifies what properties can be associated with an entry, the allowed format or type of the property, and whether it is optional or mandatory. Each entry is defined as an object in the directory, and a given object contains the properties associated with that entry. Attributes can be thought of as name-value pairs, because it is customary to ask the value of a property with a given name for some specific entry.

As we've seen, it is not unusual for a namespace to be hierarchical and so too with directories. The hierarchical structure of the directory is stored in the directory tree. The directory objects at the nodes of the tree are called container objects, which can contain other container objects, or leaves or terminal objects. For example, there might be a container object that represents the organization that holds other container objects for the major organizational departments and so on, until you get to the people, printers, offices, and other resources at the leaves.

A directory service provides methods for querying the directory and managing the entries. These methods may be accessed by client programs designed for human interaction or by other programs that need access to the information contained in the directory.

In practice, directories can be physically distributed and their actions coordinated to produce a single, logical directory. Directories are also often replicated for both reliability and scalability reasons.

From the description just given, it may be hard to distinguish a directory service from a standard database. Indeed, directories can be built inside databases, and many of the directories in use are just that. Still, enterprise-class directories are usually different from databases in some significant ways:

  • Directories are usually hierarchical whereas databases are usually relational. A directory can tell you all the people whose manager is Mary Jones and all the people who work in Salt Lake, but it can't easily tell you all the people whose manager is located in Salt Lake—a trivial task with a relational database.

  • Retrieval is more important than updating in a directory, and consequently, directories are optimized for retrieval. Typically, about 90% of the accesses in a directory are retrievals or queries with the remainder being additions or updates.

  • Directories are optimized for storing and managing many millions of small objects, whereas databases are typically optimized to store smaller numbers of larger objects.

  • Directories do not usually support transactions, meaning that operations on the directory cannot be coordinated with the operations of other applications so that they are atomic (i.e., all happen or none happen).

  • Directories offer extensive support for matching, partial matching, filtering, and other query operations.

  • Most directories have preconfigured schemas so that they are immediately usable for common purposes and are customizable only in very specific ways. Databases typically require considerable schema work before any data can be stored.

  • Directories are intended for external, wide-area use by default.

  • Directories are simpler to manage than relational databases. Trained database administrators, who specialize in creating and managing schemas, optimizing queries, and so forth typically manage databases.

  • Because queries and retrievals predominate, directories are easier to replicate for redundancy and performance reasons.

Even with these differences, and the advantages directories have in storing identity information, many organizations persist in using full-scale databases for relatively simple directory work.

The http://Utah.gov directory I mentioned at the beginning of this chapter was more than a simple association of email addresses and authentication information. The http://Utah.gov directory contained as complete a collection of contact information for employees, contractors, and others as we could manage.

The http://Utah.gov directory contains names, phone numbers, job titles, email addresses, and office locations. The schema of this kind of directory is fairly simple, merely defining the fields stored in the directory and which are mandatory. Mandatory fields might include email address and phone number, or at least one or the other.

Such a directory is useful for more than just letting employees search for other employees. The directory can serve as an authoritative record of the employees and drive other enterprise information systems, including the email system, the HR system, and the finance and payroll systems. Also the directory serves as the authentication and authorization repository for systems and applications.

In a perfect world, the online directory is fed directly from authoritative sources. For example , employee phone numbers should be fed from the phone system's records so that they are always as accurate as possible. Alternately, the phone system could be fed from the directory. Of course, any printed version of the phone directory should be printed directly from the directory.

In creating an authoritative directory, it is important to understand the relationships between various enterprise information systems, know who updates what information, specify what information is authoritative, or canonical, and create a schema that can service these many needs. As I mentioned in the story about the http://Utah.gov directory, the politics are often the hardest part of a directory project. We'll discuss governance in Chapter 14.

There are hundreds of different directory implementations in use. There are a few however, that are pervasive, or that serve as good examples of a type. This section discusses a few of these.

The Domain Name System (DNS ) is the directory that maps domain names to IP addresses. DNS is built around the hierarchical domain namespace that we discussed earlier. DNS is a distributed directory and serves as the enabling infrastructure for a single, global directory of domain names. This directory is built from thousands of servers owned by thousands of organizations around the world. The architecture of DNS allows those machines to efficiently and cooperatively answer queries regarding domain name mappings and, at the same time, provide for delegated control over the mappings for any given namespace.

When a machine needs to resolve a domain name into an IP address, it queries a DNS server, looking to one of a few, usually local, servers for the answer. The local server may know the answer because the query regards a local machine or because it regards a machine that the DNS server has recently looked up. If it does not, the hierarchical structure of the name is used to arrive at an answer.

Suppose that a distant machine is looking for http://www.windley.com (see Figure 9-2). The machine contacts its local server, but that server does not know the answer. The local server contacts what is known as the root server for the top-level domain (TLD), in this case .com. The root server does not know the mapping for http://www.windley.com, but it does know the addresses of every DNS server for the domains in its TLD. The root server refers the local server to the DNS server handling http://windley.com, and the local server contacts the http://windley.com DNS server. Since that server knows the address for http://www.windley.com, the address is returned to the local server, cached, and sent to the original requestor. Of course, domain namespaces can be more than three deep and so can the associated servers. This process just goes on longer in those cases, but an answer is eventually returned as long as the mapping exists and the servers are properly configured and registered.


RMI is the Java Remote Method Invocation facility that provides the groundwork for creating client-server architectures over a network. RMIRegistry is the RMI directory. I refer to RMIRegistry only as an example of a class of directories that are largely unseen, but important to the enterprise. RMIRegistry and its cousins provide a directory for named references to remote objects in a programming environment.

Figure 9-3 shows RMIRegistry in action. When a particular server starts, it registers with RMIRegistry, giving it a name and a reference to the method on the server. Later, when the client accesses the method, it does not use a specific reference to the method, or even the machine and port the service is running on, but rather asks the RMIRegistry to return the reference to a service with a particular name. Once the RMIRegistry has returned the reference, the client can use it to contact the server and invoke the method.

There are several advantages to using a named directory of remote references:

  • The client does not need to be aware of implementation and deployment-specific information. Because it is insulated from this detail, the service is free to change these details without interrupting service or requiring the clients to be reconfigured.

  • The indirection created by the name can be used to scale the service since multiple copies of the server could be servicing clients. Similarly, the clients could be directed to the server that is most lightly loaded or one that is closer (in a network sense) to the client.


X.500 is sometimes referred to as the granddaddy of directory services, because its definition is the basis for many of the directories used in enterprises. X.500 is a comprehensive specification of directory services that was originally conceived as a distributed, network-independent directory service for a messaging service whose specification was called X.400. X.500 specified an online white pages for the messaging system.

X.500 is actually a family of specifications developed by the International Standards Organization (ISO) and the International Telecommunications Union (ITU). Perhaps the most familiar of this family is the X.509 authentication framework specification that we discussed in Chapter 6. As we saw, X.509 specifies the public-key infrastructure that is the basis for the use of digital certificates in many applications.

X.500 defines a distributed directory service that is hierarchical in nature and operates on a common namespace. The service is designed to be vastly scalable and extensible. The X.500 standards are a canonical reference for directory service functionality and, as such, are frequently used by industry in defining the functionality, architecture, and terminology for other directory services.

LDAP, the lightweight directory access protocol, was created to provide simplified access to some of the functionality of X.500. Building clients to work with X.500 is complex because of all the options built into the specification. X.500 also was built and modeled on an OSI network protocol stack rather than TCP/IP, the standard protocol of the Internet. LDAP was originally conceived as a protocol that could be implemented by a gateway to an X.500 directory service. Using the lightweight protocol, clients could more easily access the X.500.

Moreover, LDAP specifies an API for clients, something that X.500 lacks. Having an API allows standard software development kits (SDKs) to be created that contain much of the code necessary to use the directory service.

LDAP has evolved to be a complete directory service, instead of just a gateway to X.500 services, and a number of native LDAP directory servers exist on the market. Like X.500, LDAP specifies a network-based server with a hierarchical namespace. LDAP also specifies a method for doing referrals to other directories so that multiple LDAP servers can cooperate to create a single virtual namespace from the namespaces of the individual servers. While most LDAP servers provide a means of replication, there is, as yet, no replication standard, and so LDAP servers from different vendors do not always interoperate.

Many commercial directories, including eDirectory from Novell and Active Directory from Microsoft, are LDAP compliant, meaning they support the LDAP client API. Consequently, applications that understand the LDAP API can use them with relative ease. For example, Brigham Young University's staff and student directory has an LDAP interface, and I was able to couple Apple's Address Book application to it in just a few minutes, allowing me to search the directory using the same application I store all my contacts in. If you're interested in exploring LDAP and how it works, I recommend OpenLDAP, an open source LDAP server that is available at http://www.openldap.org.