Figure 1. X.500 information model
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.