The Directory Server allows access to a type of database that stores information in a hierarchical structure similar to the way that the i5/OS integrated file system is organized.
If the name of an object is known, its characteristics can be retrieved. If the name of a particular individual object is not known, the directory can be searched for a list of objects that meet a certain requirement. Directories can usually be searched by specific criteria, not just by a predefined set of categories.
A directory is a specialized database that has characteristics that set it apart from general purpose relational databases. A characteristic of a directory is that it is accessed (read or searched) much more often than it is updated (written). Because directories must be able to support high volumes of read requests, they are typically optimized for read access. Because directories are not intended to provide as many functions as general-purpose databases, they can be optimized to economically provide more applications with rapid access to directory data in large distributed environments.
A directory can be centralized or distributed. If a directory is centralized, there is one directory server (or a server cluster) at one location that provides access to the directory. If the directory is distributed, there are multiple servers, usually geographically dispersed, that provide access to the directory.
When a directory is distributed, the information stored in the directory can be partitioned or replicated. When information is partitioned, each directory server stores a unique and non-overlapping subset of the information. That is, each directory entry is stored by one and only one server. The technique to partition the directory is to use LDAP referrals. LDAP referrals allow the users to refer Lightweight Directory Access Protocol (LDAP) requests to either the same or different name spaces stored in a different (or same) server. When information is replicated, the same directory entry is stored by more than one server. In a distributed directory, some information can be partitioned and some information can be replicated.
The LDAP directory server model is based on entries (which are also referred to as objects). Each entry consists of one or more attributes, such as a name or address, and a type. The types typically consist of mnemonic strings, such as cn for common name or mail for e-mail address.
The example directory in Figure 1 shows an entry for Tim Jones that includes mail and telephoneNumber attributes. Some other possible attributes include fax, title, sn (for surname), and jpegPhoto.
Each directory has a schema, which is a set of rules that determine the structure and contents of the directory. You can view the schema using the Web administration tool. For more information about the schema, see Schema.
Each directory entry has a special attribute called objectClass. This attribute controls which attributes are required and allowed in an entry. In other words, the values of the objectClass attribute determine the schema rules the entry must obey.
In addition to the attributes defined by the schema, entries also have a set of attributes that are maintained by the server. These attributes, known as operational attributes, include such things as when the entry was created and access control information. For more information about operational attributes, see Operational attributes.
Traditionally, LDAP directory entries are arranged in a hierarchical structure that reflects political, geographic, or organizational boundaries (see Figure 1). Entries that represent countries or regions appear at the top of the hierarchy. Entries representing states or national organizations occupy the second level down in the hierarchy. The entries below that can then represent people, organizational units, printers, documents, or other items.
LDAP refers to entries with Distinguished Names (DNs). Distinguished names consist of the name of the entry itself as well as the names, in order from bottom to top, of the objects above it in the directory. For example, the complete DN for the entry in the bottom left corner of Figure 1 is cn=Tim Jones, o=IBM, c=US. Each entry has at least one attribute that is used to name the entry. This naming attribute is called the Relative Distinguished Name (RDN) of the entry. The entry above a given RDN is called its parent Distinguished Name. In the example above, cn=Tim Jones names the entry, so it is the RDN. o=IBM, c=US is the parent DN for cn=Tim Jones. For more information about DNs, see Distinguished names (DNs).
To give an LDAP server the capability to manage part of an LDAP directory, you specify the highest level parent distinguished names in the configuration of the server. These distinguished names are called suffixes. The server can access all objects in the directory that are below the specified suffix in the directory hierarchy. For example, if an LDAP server contained the directory shown in Figure 1, it would need to have the suffix o=ibm, c=us specified in its configuration in order to be able to answer client queries regarding Tim Jones.
You are not limited to the traditional hierarchy when structuring your directory. The domain component structure, for example, is gaining popularity. With this structure, entries are composed of the parts of TCP/IP domain names. For example, dc=ibm,dc=com might be preferable to o=ibm,c=us.
Say that you want to create a directory using the domain component structure that will contain employee data such as names, telephone numbers, and email addresses. You use the suffix or naming context based on the TCP/IP domain. This directory might be visualized as something similar to the following:
/
|
+- ibm.com
|
+- employees
|
+- Tim Jones
| 555-555-1234
| tjones@ibm.com
|
+- John Smith
555-555-1235
jsmith@ibm.com
When entered in the Directory Server this data might actually look similar to the following:
# suffix ibm.com dn: dc=ibm,dc=com objectclass: top objectclass: domain dc: ibm # employees directory dn: cn=employees,dc=ibm,dc=com objectclass: top objectclass: container cn: employees # employee Tim Jones dn: cn=Tim Jones,cn=employees,dc=ibm,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: publisher objectclass: ePerson cn: Tim Jones cn: "Jones, Tim" sn: Jones givenname: Tim telephonenumber: 555-555-1234 mail: tjones@ibm.com # employee John Smith dn: cn=John Smith,cn=employees,dc=ibm,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: publisher objectclass: ePerson cn: John Smith cn: "Smith, John" sn: Smith givenname: John telephonenumber: 555-555-1235 mail: jsmith@ibm.com
You will notice that the each entry contains attribute values called objectclass. The objectclass values define what attributes are allowed in the entry, such as telephonenumber or givenname. The allowed object classes are defined in the schema. The schema is a set of rules that defines the type of entries allowed in the database.
Directory clients and servers
Directories are usually accessed using the client-server model of communication. The client and server processes might or might not be on the same machine. A server is capable of serving many clients. An application that wants to read or write information in a directory does not access the directory directly. Instead, it calls a function or application programming interface (API) that causes a message to be sent to another process. This second process accesses the information in the directory on behalf of the requesting application. The results of the read or write are then returned to the requesting application.
An API defines the programming interface a particular programming language uses to access a service. The format and contents of the messages exchanged between client and server must adhere to an agreed on protocol. LDAP defines a message protocol used by directory clients and directory servers. There is also an associated LDAP API for the C language and ways to access the directory from a Java application using the Java Naming and Directory Interface (JNDI).
Directory security
A directory should support the basic capabilities needed to implement a security policy. The directory might not directly provide the underlying security capabilities, but it might be integrated with a trusted network security service that provides the basic security services. First, a method is needed to authenticate users. Authentication verifies that users are who they say they are. A user name and password is a basic authentication scheme. Once users are authenticated, it must be determined if they have the authorization or permission to perform the requested operation on the specific object.
Authorization is often based on access control lists (ACLs). An ACL is a list of authorizations that might be attached to objects and attributes in the directory. An ACL lists what type of access each user or a group of users is allowed or denied. In order to make ACLs shorter and more manageable, users with the same access rights are often put into groups.