This chapter eXPlains the LDAP protocol and the concepts behind LDAP.
LDAP (Lightweight Directory Access Protocol) is the Internet directory protocol. Developed at the University of Michigan at Ann Arbor in conjunction with the Internet Engineering Task Force, LDAP is a protocol for accessing and managing directory services.
The chapter is organized in the following sections:
"How Directory Services Work"
"How LDAP Servers Organize Directories"
"How LDAP Clients and Servers Work"
"Understanding the LDAP v3 Protocol"
"For More Information"
If you are already familiar with LDAP, you can skip ahead to Chapter 2, "Using the Netscape Directory SDK for Java."
How Directory Services Work
A directory consists of entries containing descriptive information. For example, a directory might contain entries describing people or network resources, sUCh as printers or fax machines.
The descriptive information is stored in the attributes of the entry. Each attribute describes a specific type of information. For example, attributes describing a person might include the person's name (common name, or cn), telephone number, and email address.
The entry for Barbara Jensen might have the following attributes:
cn: Barbara Jensen
mail:
[email protected]
telephoneNumber: 555-1212
roomNumber: 3995
An attribute can have more than one value. For example, a person might have two common names (a formal name and a nickname) or two telephone numbers:
cn: Jennifer Jensen
cn: Jenny Jensen
mail:
[email protected]
telephoneNumber: 555-1213
telephoneNumber: 555-2059
roomNumber: 3996
Attributes can also contain binary data. For example, attributes of a person might include the JPEG photo of the person or the voice of the person recorded in an audio file format.
A directory service is a distributed database application designed to manage the entries and attributes in a directory. A directory service also makes the entries and attributes available to users and other applications. The Netscape Directory Server is an example of a directory service.
For example, a user might use the directory service to look up someone's telephone number. Another application might use the directory service to retrieve a list of email addresses.
LDAP is a protocol defining a directory service and access to that service. LDAP is based on a client-server model. LDAP servers provide the directory service, and LDAP clients use the directory service to access entries and attributes.
An example of an LDAP server is the Netscape Directory Server, which manages and provides information about users and organizational structures of users, such as groups and departments. Examples of LDAP clients might include the HTTP gateway to the Netscape Directory Server, Netscape Navigator, and Netscape Communicator. The gateway uses the directory service to find, update, and add information about users.
How LDAP Servers Organize Directories
Because LDAP is intended to be a global directory service, data is organized hierarchically, starting at a root and branching down into individual entries.
At the top level of the hierarchy, entries represent larger organizations. Under these larger organizations in the hierarchy might be entries for smaller organizations. The hierarchy might end with entries for individual people or resources.
Figure 1.1 illustrates an example of a hierarchy of entries in an LDAP directory service.
Figure 1.1 A hierarchy of entries in the directory
Each entry is uniquely identified by a distinguished name. A distinguished name consists of a name that uniquely identifies the entry at that hierarchical level (for example, bjensen and kjensen are different user IDs that identify different entries at the same level) and a path of names that trace the entry back to the root of the tree.
For example, this might be the distinguished name for the bjensen entry:
uid=bjensen, ou=People, o=Airius.com
Here, uid represents the user ID of the entry, ou represents the organizational unit in which the entry belongs, and o represents the larger organization in which the entry belongs.
The following diagram shows how distinguished names are used to identify entries uniquely in the directory hierarchy.
Figure 1.2 An example of a distinguished name in the directory
The data stored in a directory can be distributed among several LDAP servers. For example, one LDAP server at Airius.com might contain entries representing North American organizational units and employees, while another LDAP server might contain entries representing European organizational units and employees.
Some LDAP servers are set up to refer requests to other LDAP servers. For example, if the LDAP server at Airius.com receives a request for information about an employee in a Pacific Rim branch, that server can refer the request to the LDAP server at the Pacific Rim branch. In this way, LDAP servers can appear to be a single source of directory information. Even if an LDAP server does not contain the information you request, the server can refer you to another server that does contain the information.
How LDAP Clients and Servers Work
In the LDAP client-server model, LDAP servers (such as the Netscape Directory Server) make information about people, organizations, and resources accessible to LDAP clients. The LDAP protocol defines operations that clients use to search and update the directory. An LDAP client can perform these operations, among others:
searching for and retrieving entries from the directory
adding new entries to the directory
updating entries in the directory
deleting entries from the directory
renaming entries in the directory
For example, to update an entry in the directory, an LDAP client submits the distinguished name of the entry with updated attribute information to the LDAP server. The LDAP server uses the distinguished name to find the entry and performs a modify operation to update the entry in the directory.
To perform any of these LDAP operations, an LDAP client needs to establish a connection with an LDAP server. The LDAP protocol specifies the use of TCP/IP port number 389, although servers may run on other ports.
The LDAP protocol also defines a simple method for authentication. LDAP servers can be set up to restrict permissions to the directory. Before an LDAP client can perform an operation on an LDAP server, the client must authenticate itself to the server by supplying a distinguished name and passWord. If the user identified by the distinguished name does not have permission to perform the operation, the server does not execute the operation.
Understanding the LDAP v3 Protocol
Many LDAP servers support version 2 of the LDAP protocol. This version of the protocol is specified in RFC 1777 (you can find a copy of this RFC at http://www.ietf.org/rfc/rfc1777.txt).
The most recent proposed standard is version 3 of the LDAP protocol, which is specified in RFC 2251 (you can find a copy of this RFC at http://www.ietf.org/rfc/rfc2251.txt). Some LDAP servers, such as the Netscape Directory Server 3.0 and later, support this newer version of the protocol.
The Netscape Directory SDK for Java 4.0 supports both of these versions of the protocol. Clients built with this SDK can interact with LDAP v2 servers and LDAP v3 servers.
The LDAP v3 protocol includes these new features:
You can specify controls (both on the server and on the client) that extend the functionality of an LDAP operation.
You can request the server to perform extended operations (beyond the standard LDAP operations).
You can use Simple Authentication and Security Layer (SASL) mechanisms to authenticate to the directory.
Servers have DSEs (DSA-specific entries, where a DSA is a directory server) that provide information including the versions of the LDAP protocol supported, a list of the controls, extended operations, and SASL mechanisms supported by the server, and the naming contexts of the server (specifying the portion of the directory tree managed by this server).
Servers make their schemas available to clients. (You can get a directory server's schema from the root DSE.)
Both client and severs can support data in UTF-8 format. Clients can now request and receive data that is tagged with language information.
The Netscape Directory SDK for Java 4.0 supports both of these versions of the protocol. Clients built with this SDK can interact with LDAP v2 servers and LDAP v3 servers.
The LDAP v3 protocol includes these new features:
You can specify controls (both on the server and on the client) that extend the functionality of an LDAP operation.
You can request the server to perform extended operations (beyond the standard LDAP operations).
You can use Simple Authentication and Security Layer (SASL) mechanisms to authenticate to the directory.
Servers have DSEs (DSA-specific entries, where a DSA is a directory server) that provide information including the versions of the LDAP protocol supported, a list of the controls, extended operations, and SASL mechanisms supported by the server, and the naming contexts of the server (specifying the portion of the directory tree managed by this server).
Servers make their schemas available to clients. (You can get a directory server's schema from the root DSE.)
Both client and severs can support data in UTF-8 format. Clients can now request and receive data that is tagged with language information.
