Introduction to LDAP
In this chapter, we will discuss:
- Directory basics
- LDAP information models
- LDIF format for representing LDAP data
- A sample application
We all deal with directories on a daily basis. We use a telephone directory to look up phone numbers. When visiting a library, we use the library catalog to look up the books we want to read. With computers, we use the file system directory to store our files and documents. Simply put, a directory is a repository of information. The information is usually organized in such a way that it can be retrieved easily.
Directories on a network are typically accessed using the client/server communication model. Applications wanting to read or write data to a directory communicate with specialized directory servers. The directory server performs read or write operation on the actual directory. Figure 1-1 shows this client/server interaction.
Figure 1-1. Directory server and client interaction
The communication between the directory server and client applications is usually accomplished using standardized protocols. The Lightweight Directory Access Protocol (LDAP) provides a standard protocol model for communicating with a directory. The directory servers that implement the LDAP protocol are usually referred to as LDAP servers. The LDAP protocol is based on an earlier X.500 standard but is significantly simpler (and hence lightweight) and easily extensible. Over the years, the LDAP protocol went through iterations and is currently at version 3.0.
LDAP Overview
The LDAP defines a message protocol used by directory clients and directory servers. LDAP can be better understood by considering the following four models upon which it is based:
- The Information model determines the structure of information stored in the directory.
- The Naming model defines how information is organized and identified in the directory.
- The Functional model defines the operations that can be performed on the directory.
- The Security model defines how to protect information from unauthorized access.
We will be looking at each of these models in the sections that follow.
Beginners often get confused and picture an LDAP directory as a relational database. Like a database, an LDAP directory stores information. However, there are several key characteristics that set a directory apart from relational databases.
LDAP directories typically store data that is relatively static in nature. For example, employee information stored in LDAP such as his phone number or name does not change every day. However, users and applications look up this information very frequently. Since the data in a directory is accessed more often than updated, LDAP directories follow the WORM principle (http://en.wikipedia.org/wiki/Write_Once_Read_Many) and are heavily optimized for read performance. Placing data that change quite often in an LDAP does not make sense.
Relational databases employ techniques such as referential integrity and locking to ensure data consistency. The type of data stored in LDAP usually does not warrant such strict consistency requirements. Hence, most of these features are absent on LDAP servers. Also, transactional semantics to roll back transactions are not defined under LDAP specification.
Relational databases are designed following normalization principles to avoid data duplication and data redundancy. LDAP directories, on the other hand, are organized in a hierarchical, object-oriented way. This organization violates some of the normalization principles. Also, there is no concept of table joins in LDAP.
Even though directories lack several of the RDBMS features mentioned above, many modern LDAP directories are built on top of relational databases such as DB2.
The basic unit of information stored in LDAP is referred to as an entry. Entries hold information about real world objects such as employees, servers, printers, and organizations. Each entry in an LDAP directory is made up of zero or more attributes. Attributes are simply key value pairs that hold information about the object represented by the entry. The key portion of an attribute is also called the attribute type and describes the kind of information that can be stored in the attribute. The value portion of the attribute contains the actual information. Table 1-1 shows a portion of an entry representing an employee. The left column in the entry contains the attribute types, and the right column holds the attribute values.
Table 1-1. Employee LDAP Entry
| Employee Entry | |
|---|---|
| objectClass | inetOrgPerson |
| givenName | John |
| surname | Smith |
|
[email protected] [email protected] |
|
| mobile | +1 801 100 1000 |
Note Attribute names by default are case-insensitive. However, it is recommended to use camel case format in LDAP operations.
You will notice that the mail attribute has two values. Attributes that are allowed to hold multiple values are called multi-valued attributes. Single-valued attributes, on the other hand, can only hold a single value. The LDAP specification does not guarantee the order of the values in a multi-valued attribute.
Each attribute type is associated with a syntax that dictates the format of the data stored as attribute value. For example, the mobile attribute type has a TelephoneNumber syntax associated with it. This forces the attribute to hold a string value with length between 1 and 32. Additionally, the syntax also defines the attribute value behavior during search operations. For example, the givenName attribute has the syntax DirectoryString. This syntax enforces that only alphanumeric characters are allowed as values. Table 1-2 lists some of the common attributes along with their associated syntax description.
Table 1-2. Common Entry Attributes
| Attribute Type | Syntax | Description |
|---|---|---|
| commonName | DirectoryString | Stores the common name of a person. |
| telephoneNumber | TelephoneNumber | Stores the person’s primary telephone number. |
| jpegPhoto | Binary | Stores one or more images of the person. |
| Surname | DirectoryString | Stores the last name of the person. |
| employeeNumber | DirectoryString | Stores the employee’s identification number in the organization. |
| givenName | DirectoryString | Stores user’s first name. |
| IA5 String | Stores person’s SMTP mail address. | |
| mobile | TelephoneNumber | Stores person’s mobile number. |
| postalAddress | Postal Address | Stores the location of the user. |
| postalCode | DirectoryString | Stores the user’s ZIP or postal code. |
| st | DirectoryString | Stores the state or province name. |
| uid | DirectoryString | Stores the user id. |
| street | DirectoryString | Stores the street address. |
In object-oriented languages such as Java, we create a class and use it as a blueprint for creating objects. The class defines the attributes/data (and behavior/methods) that these instances can have. In a similar fashion, object classes in LDAP determine the attributes an LDAP entry can have. These object classes also define which of these attributes are mandatory and which are optional. Every LDAP entry has a special attribute aptly named objectClass that holds the object class it belongs to. Looking at the objectClass value in the employee entry in Table 1-1, we can conclude that the entry belongs to the inetOrgPerson class. Table 1-3 shows the required and optional attributes in a standard LDAP person object class. The cn attribute holds the person’s common name whereas the sn attribute holds the person’s family name or surname.
Table 1-3. Person Object Class
| Required Attributes | Optional Attributes |
|---|---|
| sn | description |
| telephoneNumber | |
| cn | userPassword |
| objectClass | seeAlso |
As in Java, it is possible for an object class to extend other object classes. This inheritance will allow the child object class to inherit parent class attributes. For example, the person object class defines attributes such as common name and surname. The object class inetOrgPerson extends the person class and thus inherits all the person’s attributes. Additionally, inetOrgPerson defines attributes that are required for a person working in an organization, such as departmentNumber and employeeNumber. One special object class namely top does not have any parents. All other object classes are decedents of top and inherit all the attributes declared in it. The top object class includes the mandatory objectClass attribute. Figure 1-2 shows the object inheritance.
Figure 1-2. LDAP object inheritance
Most LDAP implementations come with a set of standard object classes that can be used out of the box. Table 1-4 lists some of these LDAP object classes along with their commonly used attributes.
Table 1-4. Common LDAP Object Classes
| Object Class | Attributes | Description |
|---|---|---|
| top | objectClass | Defines the root object class. All other object classes must extend this class. |
| organization | o | Represents a company or an organization. The o attribute typically holds the name of the organization. |
| organizationalUnit | ou | Represents a department or similar entity inside an organization. |
| person | sn cn telephoneNumber userPassword |
Represents a person in the directory and requires the sn (surname) and cn (common name) attributes. |
| organizationalPerson | registeredAddress postalAddress postalCode | Subclasses person and represents a person in an organization. |
| inetOrgPerson | uid departmentNumber employeeNumber givenName manager | Provides additional attributes and can be used to represent a person working in today’s Internet- and intranet-based organization. The uid attribute holds the person’s username or user id. |
The LDAP directory schema is a set of rules that determine the type of information stored in a directory. Schemas can be considered as packaging units and contain attribute type definitions and object class definitions. Before an entry can be stored in LDAP, the schema rules are verified. This schema checking ensures that the entry has all the required attributes and does not contain any attributes that are not part of the schema. Figure 1-3 represents a generic LDAP schema.
Figure 1-3. LDAP generic schema
Like databases, directory schemas need to be well designed to address issues like data redundancy. Before you go about implementing your own schema, it is worth looking at several of the standard schemas available publicly. Most often these standard schemas contain all definitions to store the required data and, more importantly, ensure interoperability across other directories.
The LDAP Naming model defines how entries are organized in a directory. It also determines how a particular entry can be uniquely identified. The Naming model recommends that entries be stored logically in a hierarchical fashion. This tree of entries is often referred to as directory information tree (DIT). Figure 1-4 provides an example of a generic directory tree.
Figure 1-4. Generic DIT
The root of the tree is usually referred to as the base or suffix of the directory. This entry represents the organization that owns the directory. The format of suffix can vary from implementation to implementation but, in general, there are three recommended approaches, as listed in Figure 1-5.
Figure 1-5. Directory suffix naming conventions
Note DC stands for domain component.
The first recommended technique is to use the organization’s do- main name as the suffix. For example, if the organization’s domain name is example.com, the suffix of the directory will be o=example. com. The second technique also uses the domain name but each component of the name is prepended with “dc=” and joined by commas. So the domain name example.com would result in a suffix dc=example, dc=com. This technique is proposed in RFC 2247 and is popular with Microsoft Active Directory. The third technique uses X.500 model and creates a suffix in the format o=organization name, c=country code. In United States, the suffix for the organization example would be o=example, c=us.
The Naming model also defines how to uniquely name and identify entries in a directory. Entries that share a common immediate parent are uniquely identified via their Relative Distinguished Name (RDN). The RDN is computed using one or more attribute/value pairs of the entry. In its simplest case, RDN is usually of the form attribute name = attribute value. Figure 1-6 provides a simplified representation of an organization directory. Each person entry under ou=employees has a unique uid. So the RDN for the first person entry would be uid=emp1, where emp1 is the employee’s user id.
Figure 1-6. Example of an organization directory
Note The distinguished name is not an actual attribute in the entry. It is simply a logical name associated with the entry.
It is important to remember that RDN cannot be used to uniquely identify the entry in the entire tree. However, this can be easily done by combining the RDNs of all the entries in the path from the top of the tree to the entry. The result of this combination is referred to as Distinguished Name (DN). In Figure 1-6, the DN for Person 1 would be uid=emp1, ou=employees, dc=example, dc=com. Since the DN is made by combining RDNs, if an entry’s RDN changes, the DNs of that entry and all its child entries also changes.
There can be situations where a set of entries do not have a single unique attribute. In those scenarios, one option is to combine multiple attributes to create uniqueness. For example, in the previous directory we can use the consumer’s common name and e-mail address as a RDN. Multi-valued RDNs are represented by separating each attribute pair with a +, like so:
cn = Balaji Varanasi + [email protected]
Note Multi-valued RDNs are usually discouraged. In those scenarios, it is recommended to create a unique sequence attribute to ensure uniqueness.
The LDAP Functional model describes the access and modification operations that can be performed on the directory using LDAP protocol. These operations fall in to three categories: query, update, and authentication.
The query operations are used to search and retrieve information from a directory. So every time some information needs to be read, a search query needs to be constructed and executed against LDAP. The search operation takes a starting point within DIT, the depth of the search, and the attributes an entry must have for a match. In Chapter 6, you’ll delve deep into searching and look at all the available options.
The update operations add, modify, delete, and rename directory entries. The add operation, as name suggests, adds a new entry to the directory. This operation requires the DN of the entry to be created and a set of attributes that constitute the entry. The delete operation takes a fully qualified DN of the entry and deletes it from the directory. The LDAP protocol allows only the leaf entries to be deleted. The modify operation updates an existing entry. This operation takes the entry’s DN and a set of modifications such as adding a new attribute, updating a new attribute, or removing an existing attribute. The rename operation can be used to rename or move entries in a directory.
The authentication operations are used for connecting and ending sessions between the client and LDAP server. A bind operation initiates an LDAP session between the client and LDAP server. Typically, this would result in an anonymous session. It is possible for the client to provide a DN and set of credentials to authenticate itself and create an authenticated session. The unbind operation, on the other hand, can be used to terminate existing session and disconnect from the server.
LDAP V3 introduced a framework for extending existing operations and adding new operations without changing the protocol itself. You will take a look at these operations in Chapter 7.
The LDAP Security model focuses on protecting LDAP directory information from unauthorized accesses. The model specifies which clients can access which parts of the directory and what kinds of operations (search vs. update) are allowed.
The LDAP Security model is based on the client authenticating itself to the server. This authentication process or bind operation as discussed above involves the client supplying a DN identifying itself and a password. If the client does not provide DN and password, an anonymous session is established. RFC 2829 (www.ietf.org/rfc/rfc2829.txt) defines a set of authentication methods that LDAP V3 servers must support. After successful authentication, the access control models are consulted to determine whether the client has sufficient privileges to do what is being requested. Unfortunately, no standards exist when it comes to access control models and each vendor provides his own implementations.
LDAP has gained a wide support from a variety of vendors. There has also been a strong open source movement to produce LDAP servers. Table 1-5 outlines some of the popular Directory Servers.
Table 1-5. LDAP Vendors
ApacheDS and OpenDJ are pure Java implementation of LDAP directories. You will be using these two servers for unit and integration testing of the code throughout this book.
The LDAP Data Interchange Format (LDIF) is a standard text-based format for representing directory content and update requests. The LDIF format is defined in RFC 2849 (www.ietf.org/rfc/rfc2849.txt). LDIF files are typically used to export data from one directory server and import it into another directory server. It is also popular for archiving directory data and applying bulk updates to a directory. You will be using LDIF files to store your test data and refreshing directory server between unit tests.
The basic format of an entry represented in LDIF is as follows:
#comment
dn: <distinguished name>
objectClass: <object class>
objectClass: <object class>
...
...
<attribute type>: <attribute value>
<attribute type>: <attribute value>
...
Lines in the LDIF file starting with a # character are considered as comments. The dn and at least one objectClass definition of the entry are considered required. Attributes are represented as name/value pairs separated by a colon. Multiple attribute values are specified in separate lines and will have the same attribute type. Since LDIF files are purely text-based, binary data needs to be Base64 encoded before it is stored as part of the LDIF file.
Multiple entries in the same LDIF file are separated by blank lines. Listing 1-1 shows an LDIF file with three employee entries. Notice that the cn attribute is a multivalued attribute and is represented twice for each employee.
Listing 1-1. LDIF File with Three Employee Entries
# Barbara’s Entry
dn: cn=Barbara J Jensen, dc=example, dc=com
# multi valued attribute
cn: Barbara J Jensen
cn: Babs Jensen
objectClass: person sn: Jensen
# Bjorn’s Entry
dn: cn=Bjorn J Jensen, dc=example, dc=com
cn: Bjorn J Jensen
cn: Bjorn Jensen
objectClass: person
sn: Jensen
# Base64 encoded JPEG photo
jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
# Jennifer’s Entry
dn: cn=Jennifer J Jensen, dc=example, dc=com
cn: Jennifer J Jensen
cn: Jennifer Jensen
objectClass: person
sn: Jensen
Throughout this book you will be working with a directory for a hypothetical book library. I have chosen library because the concept is universal and easy to grasp. A library usually stores books and other multimedia that patrons can borrow. Libraries also employs people for taking care of daily library operations. To keep things manageable, the directory will not be storing information about books. A relational database is probably suitable for recording book information. Figure 1-7 shows the LDAP directory tree for our library application.
Figure 1-7. Library DIT
In this directory tree I have used the RFC 2247 (www.ietf.org/rfc/rfc2247.txt) convention for naming the base entry. The base entry has two organizational unit entries that hold the employees and patrons information. The ou=employees part of the tree will hold all the library employee entries. The ou=patrons part of the tree will hold the library patron entries. Both library employee and patron entries are of the type inetOrgPerson objectClass. Both employees and patrons access library applications using their unique login id. Thus the uid attribute will be used as the RDN for entries.
Summary
LDAP and applications that interact with LDAP have become a key part of every enterprise today. This chapter covered the basics of LDAP Directory. You learned that LDAP stores information as entries. Each entry is made up of attributes that are simply key value pairs. These entries can be accessed via their Distinguished Names. You also saw that LDAP directories have schemas that determine the type of information that can be stored.
In the next chapter, you will look at communicating with an LDAP directory using JNDI. In the chapters following Chapter 2, you will focus on using Spring LDAP for developing LDAP applications.