Chapter 3: LDAP Models

---

Chapter 1 provided a rough overview of LDAP. This chapter provides some theoretical background that will give you an impression of the concepts underlying LDAP. Most of these concepts are covered in the requests for comments (RFCs). The standardization of LDAP is still a work in progress, so please refer to RFCs on the IETF Web site (www.ietf.org) if you want stay up to date. Recall from Chapter 1 that LDAP is the lightweight counterpart of the original X.500 Directory Access Protocol. Consequently, most of the concepts in LDAP are inherited from X.500. As a lightweight protocol, LDAP lacks several seldom-used features included in the X.500 protocol. However, some of these features are now being added to the protocol. As we said, LDAP is a work in progress.

Introduction

LDAP can be viewed as an implementation of four models. This is a useful approach because it allows us to view the LDAP protocol from four different points of view. The four models are:

1. Information model

2. Naming model

3. Functional model

4. Security model

The information model describes the basic units that LDAP uses to store information. Recall from the previous chapter that these basic units are called "entries," which map real-world objects to data structures in the directory. Every entry has a unique name and a unique object identifier (OID) to he identified among all LDAP implementations. The information model describes what these entries look like. You will see that the entries consist of entities called "attributes" and that every one of these attributes is built from two pieces of information: an attribute name and one or more attribute values. The attribute name, like the entry name, has to be unique and also has an object identifier. It is also a good idea to register the OIDs with the Internet Assigned Numbers Authority (IANA), which will guarantee compatibility with other implementations, for example, if you integrate a vendor-supplied directory in your application. Furthermore, the information model describes how searches execute comparisons between attributes. This is needed to define matches during a search, to ascertain whether an attribute is already present, and to sort attribute values. The information model finds its implementation in the directory schema, which consists of several configuration files that are loaded at the start of the server process.

The naming model describes the structure of the directory. The entries are accessed via an index called "distinguished name" (DN). This distinguished name is constructed using a particular syntax that we will discuss in this section. This particular syntax is used to construct a treelike structure. Note that this method is not just used to be syntactically "elegant," but has important performance implications. As we have seen in Chapter 1, the entries are finally stored in a database. Thus, the distinguished name is actually used to construct a tree. In most implementations, the database uses the distinguished name to construct index files that speed up information retrieval. Both the indexing mechanism and the hierarchical tree increase the speed of retrieving information in the directory.

The functional model defines the functions that LDAP offers to help in accessing, maintaining, and managing the directory. There are functions that make it possible to search, compare, add, modify, and delete entries in the directory. Strictly speaking, LDAP does not offer functions. Because LDAP is a message-oriented protocol, what LDAP actually provides is a means of sending a server requests to search, compare, add, modify, and delete entries in the directory on behalf of a client. However, it is easier to refer to these as functions, so that is what we will do. These requests, sent from the client to the server, provide the basis for implementing functions or methods of accessing LDAP directories using your preferred programming language. Nearly every programming language has one or more "collections" of function calls or methods. Chapter 6 provides more detail about the most prominent application programming interfaces (API) available to the programmer.

The security model describes two processes: authentication and authorization. Authentication verifies the identity of the user before granting access to the system. Authorization, also called "access control" in LDAP literature, makes it possible to define the level of access for each user, thus controlling "who can do what with which data." Access control is normally stored in the form of access control lists (ACL), and the information that the ACLs provide for the server is called "access control information" (ACI). Authentication is defined in two RFCs (RFC 2829, "Authentication Methods for LDAP," and RFC 2830, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security"). Access control is less standardized. At the time of this writing, the standards expressed in the RFCs offer only a recommendation describing what functionality the implementation should offer, but they do not describe any standards for implementing this functionality. The RFCs also do not define how and where the ACLs should be stored. However, this lack of standards does not mean that access control is not implemented. Any implementation has the means of providing the server with the ACI it needs to decide whether to allow or deny the client to perform the requested action. The downside is that every vendor uses its own mechanism to implement access control in its directory server. Thus access control information is stored in different ways in these different implementations, and there is no way to exchange information about access control between the different implementations.

With knowledge of these four models — combined with the protocol aspects of LDAP learned in Chapters 1 and 2 — we are finally ready to see how LDAP works. This is one of the longest chapters in this book. When you have finished it, you will have learned the most important information needed to understand LDAP.

---