The Structure of a Namespace

The LDAP model defines a flexible namespace framework, which means that you can design a namespace to satisfy your requirements no matter what they may be. However, it also means that you have more choices to make than you might like.

The LDAP namespace model is inherited from the X.500 directory standard, which is intended to be used in a rigid, worldwide, hierarchical directory service. A typical X.500 namespace starts with countries at the top of the namespace, perhaps followed by states in the United States, and then organizations below that, with further hierarchy in each organization (see Figure 9.1). Although such a hierarchical namespace may suit your needs and has a certain aesthetic appeal , it has some serious drawbacks, which are discussed later in this chapter. Fortunately, the LDAP model is flexible enough to allow other, more practical designs such as those discussed in the section Analyzing Your Namespace Needs later in this chapter.

Figure 9.1. A Typical X.500 Namespace

As mentioned in Chapter 2, Introduction to LDAP, the basic LDAP model is hierarchical, or tree-structured. Each entry has exactly one parent, except for the root entry, and every entry may have any number of child entries beneath it. Figure 9.2 shows some examples of supported and unsupported namespace structures.

Figure 9.2. Sample Supported and Unsupported Namespace Structures

Of course, the simplest hierarchical case of a one-level , flat namespace is also allowed. LDAP does not directly support an arbitrarily connected namespace, or graph structure, in which an entry might be both child and parent of the same entry. LDAP does, however, support the concept of aliases, which can be used to construct such structures (see Chapter 2, Introduction to LDAP, for more information on aliases).

Also keep in mind that through the use of seeAlso and other distinguished name (DN) “valued attributes, you can construct arbitrary relationships among entries. We prefer the use of this latter approach over the use of aliases, which tend to cause problems with performance and consistency maintenance.

After determining the hierarchical relationship among entries (a subject we tackle later in this chapter), the next question is how each entry in the hierarchy is named. First, recall from Chapter 2 that an LDAP directory entry is a collection of attribute values. To create the name of an entry, we usually choose one of these attribute values to form a relative distinguished name ( RDN ).

For example, for the entry depicted in Figure 9.3, you could choose any of the RDNs shown, provided that none of the entry's sibling entries has the same name. An entry's RDN must be unique among all entries sharing the same parent entry.

It's possible to use more than one attribute value from the entry when forming the RDN. An RDN formed in this fashion is called a multivalued RDN . The multiple values that form the RDN are separated by a plus sign. For example, uid=babs+sn=jensen is a valid RDN for the entry shown in Figure 9.3. We recommend not using multivalued RDNs for the reasons discussed in Chapter 2. To review, multivalued RDNs introduce needless complexity, can adversely affect performance, and often don't solve the problems they are intended to solve.

When the RDN of an entry is chosen and its position relative to other entries in the hierarchy is determined, forming the entry's full name is simple: Just combine the RDNs of the entry and all its ancestor entries. The resulting name is called a distinguished name, or DN.

Figure 9.3 Examples of RDNs

 cn: Barbara Jensen            cn=Barbara Jensen cn: Babs Jensen               uid=babs sn: Jensen                    mail=[e-mail] title: Director uid: babs mail:[e-mail]        Entry                    Examples of RDNs 

Figure 9.4 Examples of DNs

 cn=Barbara Jensen, o=Netscape, c=us cn=Barbara Jensen, o=Netscape.com c=us o=Netscape, c=us dc=example, dc=com o="Mega Corp., Inc.", c=us 

In LDAP, DNs are written in little-endian order, like an e-mail address, rather than big-endian order, like a file system name. Little-endian means that the least significant component is written first, with increasingly more significant components written subsequently. Each component of the name is separated by a comma, and if the entry is named with a multivalued RDN, the multiple components of the RDN are separated by a plus sign. If these or other troublesome characters occur in one of the values used to form the name, they are escaped by means of a backslash quoting mechanism. Figure 9.4 shows some examples of DNs.

More information on the LDAP namespace model, including a discussion of special characters that must be escaped when used in DNs, can be found in Chapter 2, Introduction to LDAP.