X.500 is the OSI directory service. X.500 defines the following components:
- An information model-determines the form and character of information in the directory.
- A namespace-allows the information to be referenced and organized.
- A functional model-determines what operations can be performed on the information.
- An authentication framework-allows information in the directory to be secured.
- A distributed operation model-determines how data is distributed and how operations are carried out.
The information model is centered around entries, which are composed of attributes. Each attribute has a type and one or more values. The type determines the attribute's syntax, which defines what kind of information is allowed in the values.
Which attributes are required and allowed in an entry are controlled by a special objectClass attribute in every entry. The values of this attribute identify the type of entry (e.g., person, organization, etc.). The type of entry determines which attributes are required, and which are optional. For example, the object class person requires the surname and commonName attributes, but description, seeAlso, and others are optional.
Entries are arranged in a tree structure and divided among servers in a geographical and organizational distribution. Entries are named according to their position in this hierarchy by a distinguished name (DN). Each component of the DN is called a relative distinguished name (RDN). Alias entries, which point to other entries, are allowed, circumventing the hierarchy. Figure 1 depicts the relationship between entries, attributes, and values and shows how entries are arranged into a tree.
The X.500 model is centered around entries composed of attributes that
have a type and one or more values. Entries are organized in a tree structure.
Alias entries can be used to build non-hierarchical relationships.
Functionally, X.500 defines operations in three areas: search and read, modify, and authenticate. In the first category, the read operation retrieves the attributes of an entry whose name is known. The list operation enumerates the children of a given entry. The search operation selects entries from a defined area of the tree based on some selection criteria known as a search filter. For each matching entry, a requested set of attributes (with or without values) is returned. The searched entries can span a single entry, an entry's children, or an entire subtree. Alias entries can be followed automatically during a search, even if they cross server boundaries.
In the second category, X.500 defines four operations for modifying the directory. The modify operation is used to change existing entries. It allows attributes and values to be added and deleted. The add and delete operations are used to insert and remove entries from the directory. The modify RDN operation is used to change the name of an entry.
The final category defines a bind operation, allowing a client to initiate a session and prove its identity to the directory. Several authentication methods are supported, from simple clear-text password to public key-based authentication. The unbind operation is used to terminate a directory session. An abandon operation is also defined, allowing an operation in progress to be canceled.
Each X.500 operation and result can be signed to ensure its integrity. Signing is done using the originating client's or server's public key. The signed request or result is carried end-to-end in the protocol, allowing integrity to be checked at every step. This guards against connection hijacking or modification by intermediate servers. Service controls can be specified that determine information such as how an operation will be carried out, whether aliases should be dereferenced, the maximum number of entries to return, and the maximum amount of time to spend on an operation.
In X.500, the directory is distributed among many servers (called DSAs for Directory System Agent). No matter which server a client connects to, it sees the same view of the directory. If a server is unable to answer a client's request, it can either chain the request to another server, or refer the client to the server.