Large enterprises often find that administering a single, centralized directory for all users is easier than creating accounts and passwords for each user on every server and application.
To make this directory useful, a means must be provided to retrieve data from the directory and deliver it to applications. The Lightweight Directory Access Protocol (LDAP) provides a standardized set of requests and responses that applications can use to get many types of information about users from centralized directories.
LDAP is often a key part of the user Authentication, Authorization and Accounting (AAA) services employed by enterprises such as television broadcasters to control access to their internal data and asset management systems. LDAP can also be used for a broad range of end-user services, such as customer authentication by television delivery websites (see my article last month about TV Everywhere) and remote user access via IP Tunneling applications.
DIRECTORIES
LDAP directories are collections of information about people or objects that can be accessed for many applications. Two classic examples are telephone directories and library card catalogs. LDAP is frequently used to access phone and e-mail directories within many companies, and is also used for providing information about corporate network resources such as printer IP addresses and capabilities.
LDAP is a fairly simple protocol that works on a client-server basis. The server contains (or has access to) the directory and the client is an application that needs information about a specific person or object. The information in the directory is organized hierarchically, with each directory entry identified by a Distinguished Name (DN). Each entry also has a set of attributes, which are the data values relevant to the entry.
For example, one attribute within an entry for a person might be a telephone number, and another attribute might be an e-mail address. These attributes can also be used for searching, so it is entirely permissible to search for any persons who have, say, the string "simpson" in their e-mail address.
Every attribute must be defined within a schema, and every attribute must be contained within an objectclass. The schema is a formal definition of the contents of the directory; the LDAP server must know the schemas of all the directory entries so it can understand how to access the data contents.
The objectclasses are intended to be globally unique, meaning that each object class has a unique object identifier (OID) that is part of a hierarchy managed by the International Standards Organization (www.iso.ch/) For example, the objectclass "person" has an OID of 2.5.6.6, and has two required attributes: "commonName" (abbreviated "cn") and "surname" (abbreviated "sn") as well as a variety of optional attributes.
Fig. 1 shows an example of a "person" entry in a hypothetical directory in LDAP Data Interchange Format (LDIF) as defined in RFC 2849, which is human-readable form of the binary codes used inside LDAP directories.
Fig. 1: Sample LDA P entryREADING A DIRECTORY
Fig. 2 shows the flow of a query from a client to an LDAP server. The first step in accessing data from an LDAP directory is to establish a binding between the client and the server.
During this process, security (in the form of Transport Layer Security or TLS) can be enabled, which makes transactions between a client and an LDAP server as secure as the secure HTTP (called HTTPS) transactions used extensively throughout the World Wide Web. This makes LDAP useful for obtaining the security credentials that a remote user might need in order to access a corporate database over the Internet from a laptop in a hotel room.
Fig. 2: Simple LDA P Protocol Sequence Once the connection is established, the client can request any kind of data using a query command. Queries are fairly open-ended, although the basic rules for searching must be defined inside the schema, which belong to the directory. Because LDAP is highly standardized, commands can easily be forwarded from one server to another, allowing legal queries for data not contained in the first LDAP server contacted to often be answered by a second associated server.
Although LDAP directories are optimized for searches and queries, LDAP commands also support updating directory data. These can be used for changing data values as well as creating and deleting entries in a directory. When a client program no longer needs access to a given directory, it should issue an "unbind" command to release the connection and free up server resources.
AVAILABLE DATA
LDAP is highly standardized and works across platforms from many different vendors. Microsoft's Active Directory product can be configured to provide an LDAP interface for other applications. LDAP has also been implemented by a number of other database systems and open source projects, supporting many different uses for common directories within an enterprise.
LDAP is defined in IETF Standard Track RFCs covering the newest version 3. The LDAP protocol itself is defined in RFC 4511.
IBM has published a very informative Red Book about LDAP.
Wes Simpson is an industry consultant and author of "Video Over IP, Second Edition," from Focal Press. Your comments are welcome to wes.simpson@gmail.com.
