3. THE X.500 MODEL OF DIRECTORY SERVICE
X.500 is a CCITT protocol which is designed to build a distributed, global directory. It offers the following features:
- Decentralized Maintenance: Each site running X.500 is responsible ONLY for its local part of the Directory, so updates and maintenance can be done instantly.
- Powerful Searching Capabilities: X.500 provides powerful searching facilities that allow users to construct arbitrarily complex queries.
- Single Global Namespace: Much like the DNS, X.500 provides a single homogeneous namespace to users. The X.500 namespace is more flexible and expandable than the DNS.
- Structured Information Framework: X.500 defines the information framework used in the directory, allowing local extensions.
- Standards-Based Directory: As X.500 can be used to build a standards-based directory, applications which require directory information (e-mail, automated resource locators, special-purpose directory tools) can access a planet's worth of information in a uniform manner, no matter where they are based or currently running.
3.1. Acronym City, or How X.500 Works
The '88 version of the X.500 standard talks about 3 models required to build the X.500 Directory Service: the Directory Model, the Information Model, and the Security Model. In this section, we will provide a brief overview of the Directory and Information Models sufficient to explain the vast functionality of X.500.
3.1.1. The Information Model
To illustrate the Information Model, we will first show how information is held in the Directory, then we will show what types of information can be held in the Directory, and then we will see how the information is arranged so that we can retrieve the desired pieces from the Directory.
3.1.1.1. Entries
The primary construct holding information in the Directory is the "entry". Each Directory entry contains information about one object; for example, a person, a computer network, or an organization. Each entry is built from a collection of "attributes", each of which holds a single piece of information about the object. Some attributes which might be used to build an entry for a person would be "surname", "telephonenumber", "postaladdress", etc. Each attribute has an associated "attribute syntax", which describes the type of data that attribute contains, for example, photo data, a time code, or a string of letters and numbers. As an example, let's look at part of an entry for a person.
Entry for John Smith contains:
attribute ---> surName= Smith <--- attribute value
|---> telephoneNumber= 999-9999 <--- attribute value
|---> title= Janitor <--- attribute value
...
The attribute syntax for the surName attribute would be CaseIgnoreString, which would tell X.500 that surName could contain any string, and case would not matter; the attribute syntax for the telephoneNumber attribute would be TelephoneNumber, which would specify that telephoneNumber could contain a string composed of digits, dashes, parenthesis, and a plus sign. The attribute syntax for the title attribute would also be CaseIgnoreString. A good analogy in database terms for what we've seen so far might be to think of a Directory entry as a database record, an attribute as a field in that record, and an attribute syntax as a field type (decimal number, string) for a field in a record.
3.1.1.2. Object Classes
At this point in our description of the information model, we have no way of knowing what type of object a given entry represents. X.500 uses the concept of an "object class" to specify that information, and an attribute named "objectClass" which each entry contains to specify to which object class(es) the entry belongs.
Each object class in X.500 has a definition which lists the set of mandatory attributes, which must be present, and a set of optional attributes, which may be present, in an entry of that class. An given object class A may be a subclass of another class B, in which case object class A inherits all the mandatory and optional attributes of B in addition to its own.
The object classes in X.500 are arranged in a hierarchical manner according to class inheritance; the following diagram shows a part of the object class hierarchy.
_____________
| | "top" has one mandatory
| top | attribute "objectClass",
|_____________| and nooptional attributes.
| | |
| | | every other object class is a
________________| | | subclass of "top"...
| | ...
______|________ _____|_______
| | | |"organization" inherits one
| country | | organization |mandatory attribute from
|_______________| |_______________|"top", "objectClass"; adds one
more mandatory attribute "O"
"country" inherits one (for organization), and has
mandatory attribute from "top", many optional attributes. Any
"objectClass", adds one more subclass of "organization"
mandatory attribute "c" (for would inherit all of the
country), and has two optional mandatory and optional
attributes, "description" and attributes from "organization"
"searchGuide". Any subclass of including the attribute which
"country" would inherit all of the "organization" inherited
mandatory and optional attributes from "top".
of the "country" class, including
the attribute which "country"
inherited from "top".
Figure 1.
One major benefit of the object class concept is that it is in many cases very easy to create a new object class which is only a slight modification or extension of a previous class. For example, if I have already defined an object class for "person" which contains a person's name, phone number, address, and fax number, I can easily define an "Internet person" object class by defining "Internet person" as a subclass of "person", with the additional optional attribute of "e-mail address". Thus in my definition of the "Internet Person" object class, all my "person" type attributes are inherited from "person". There are other benefits which are beyond the scope of this paper.
3.1.1.3. X.500's namespace.
X.500 hierarchically organizes the namespace in the Directory Information Base (DIB); recall that this hierarchical organization is called the Directory Information Tree (DIT). Each entry in the DIB occupies a certain location in the DIT. An entry which has no children is called a leaf entry, an entry which has children is called a non-leaf node. Each entry in the DIT contains one or more attributes which together comprise the Relative Distinguished Name (RDN) of that entry, there is a "root" entry (which has no attributes, a special case) which forms the base node of the DIT. The Distinguished Name of a specific entry is the sequence of RDNs of the entries on the path from the root entry to the entry in question. A diagram here will help to clarify this:
Level of DIT Root RDN Distinguished Name root * nothing { } / | \ country (other / | \ things at this / | \ c=us {c=us} level) c=gb c=us c=ca / | \ / | \ / | \ organization o=SRI o=Merit o=DEC o=Merit {c=us, o=Merit} (other things / | \ at this level) / | \ / | \ Third level cn=Chris Weider cn=Chris Weider {c=us, o=Merit, cn=Chris Weider} Figure 2: Building a DN from RDNs (adapted from a diagram in the X.500 (88) Blue Book)
Each entry in this tree contains more attributes than have been shown here, but in each case only one attribute for each entry has been used for that entry's RDN. As noted above, any entry in the tree could use more than one attribute to build its RDN. X.500 also allows the use of alias names, so that the entry {c=us, o=Merit, cn=Chris Weider} could be also found through an alias entry such as {c=us, o=SRI, ou=FOX Project, cn=Drone 1} which would point to the first entry.
3.1.2. The Directory Model
Now that we've seen what kinds of information can be kept in the Directory, we should look at how the Directory stores this information and how a Directory users accesses the information. There are two components of this model: a Directory User Agent (DUA), which accesses the Directory on behalf of a user, and the Directory System Agent, which can be viewed as holding a particular subset of the DIB, and can also provide an access point to the Directory for a DUA.
Now, the entire DIB is distributed through the world-wide collection of DSAs which form the Directory, and the DSAs employ two techniques to allow this distribution to be transparent to the user, called "chaining" and "referral". The details of these two techniques would take up another page, so it suffices to say that to each user, it appears that the entire global directory is on her desktop. (Of course, if the information requested is on the other side of the world, it may seem that the desktop directory is a bit slow for that request...)
3.2. The functionality of X.500
To describe the functionality of X.500, we will need to separate three stages in the evolution of X.500: 1) the 1988 standard, 2) X.500 as implemented in QUIPU, and 3) the (proposed) 1992 standard. We will list some of the features described in the 1988 standard, show how they were implemented in QUIPU, and discuss where the 1992 standard will take us. The QUIPU implementation was chosen because a) it is widely used in the U.S. and European Directory Services Pilot projects, and b) it works well. For a survey of other X.500 implementations and a catalogue of DUAs, see [Lang].
3.2.1. Functionality in X.500 (88)
There are a number of advantages that the X.500 Directory accrues simply by virtue of the fact that it is distributed, not limited to a single machine. Among these are:
- An enormously large potential namespace. Since the Directory is not limited to a single machine, many hundreds of machines can be used to store Directory entries.
- The ability to allow local administration of local data. An organization or group can run a local DSA to master their information, facilitating much more accurate data throughout the Directory.
The functionality built into the X.500(88) standard includes:
- Advanced searching capabilities. The Directory supports arbitrarily complex searches at an attribute level. As the object classes a specific entry belongs to is maintained in the objectClass attribute, this also allows Directory searches for specific types of objects. Thus, one could search the c=US subtree for anyone with a last name beginning with S, who also has either a fax number in the (313) area code or an e-mail address ending in umich.edu. This feature of X.500 also helps to provide the basic functionality for a Yellow Pages service.
- A uniform namespace with local extensibility. The Directory provides a uniform namespace, but local specialized directories can also be implemented. Locally defined extensions can include new object classes, new attributes, and new attribute types.
- Security issues. The X.500 (88) standards define two types of security for Directory data: Simple Authentication (which uses passwords), and Strong Authentication (which uses cryptographic keys). Simple authentication has been widely implemented, strong authentication has been less widely implemented. Each of these authentication techniques are invoked when a user or process attempts a Directory operation through a DUA.
In addition to the global benefits of the X.500 standard, there are many local benefits. One can use their local DSA for company or campus wide directory services; for example, the University of Michigan is providing all the campus directory services through X.500. The DUAs are available for a wide range of platforms, including X-Windows systems and Macintoshes.
3.2.2. Functionality added by QUIPU.
Functionality beyond the X.500 (88) standard implemented by QUIPU includes:
- Access control lists. An access control list is a way to provide security for each attribute of an entry. For example, each attribute in a given entry can be permitted for detect, compare, read, and modify permissions based on the reader's membership in various groups. For example, one can specify that some information in a given entry is public, some can be read only by members of the organization, and some can only be modified by the owner of the entry.
- Replication. Replication provides a method whereby frequently accessed information in a DSA other than the local one can be kept by the local DSA on a "slave" basis, with updates of the "slave" data provided automatically by QUIPU from the "master" data residing on the foreign DSA. This provides alternate access points to that data, and can make searches and retrievals more rapid as there is much less overhead in the form or network transport.
3.3. Current limitations of the X.500 standard and implementations.
As flexible and forward looking as X.500 is, it certainly was not designed to solve everyone's needs for all time to come. X.500 is not a general purpose database, nor is it a Data Base Management System (DBMS). X.500 defines no standards for output formats, and it certainly doesn't have a report generation capability. The technical mechanisms are not yet in place for the Directory to contain information about itself, thus new attributes and new attribute types are rather slowly distributed (by hand).
Searches can be slow, for two reasons: a) searches across a widely distributed portion of the namespace (c=US, for example) has a delay which is partially caused by network transmission times, and can be compounded by implementations that cache the partial search returns until everyone has reported back, and b) some implementations are slow at searching anyway, and this is very sensitive to such things as processor speed and available swap space. Another implementation "problem" is a tradeoff with security for the Directory: most implementations have an administrative limit on the amount of information which can be returned for a specific search. For example, if a search returns 1000 hits, 20 of those might be displayed, with the rest lost. Thus a person performing a large search might have to perform a number of small searches. This was implemented because an organization might want to make it hard to "troll" for the organization's entire database.
Also, there is at the moment no clear consensus on the ideal shape of the DIT, or on the idea structure of the object tree. This can make it hard to add to the current corpus of X.500 work, and the number of RFCs on various aspects of the X.500 deployment is growing monthly.
Despite this, however, X.500 is very good at what it was designed to do; i.e., to provide primary directory services and "resource location" for a wide band oftypes of information.
3.4. Things to be added in X.500 (92).
The 1988 version of the X.500 standard proved to be quite sufficient to start building a Directory Service. However, many of the new functions implemented in QUIPU were necessary if the Directory were to function in a reasonable manner. X.500 (92) will include formalized and standardized versions of those advances, including
- A formalized replication procedure.
- Enhanced searching capacities.
- Formalization of access control mechanisms, including access control lists.
Each of these will provide a richer Directory, but you don't have to wait for them! You can become part of the Directory today!