LDAP APIs

Understanding and Deploying LDAP Directory Services > 8. Namespace Design > The Structure of a Namespace

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078214175008054159210039088

The Structure of a Namespace

The LDAP model defines a flexible namespace framework, which means that you can almost certainly 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 fairly 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 8.1). While 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 next section.

Figure 8.1 A typical X.500 namespace.

The basic LDAP model is hierarchical, or tree-structured. 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 3, "An Introduction to LDAP," for more information on aliases).

Also, keep in mind that through the use of seeAlso and other directory name -valued attributes, you can construct arbitrary relationships among entries. This approach is similar to the way relations work in a relational database. We prefer the use of this latter approach to the use of aliases, which tend to cause performance and consistency maintenance problems. Some examples of supported and unsupported namespace structures are shown in Figure 8.2.

Figure 8.2 An example of supported and unsupported namespace structures.

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 3 that an LDAP directory entry is a collection of attribute values. The name of an entry is created by choosing one or more of these attribute values to form a relative distinguished name (RDN). Multiple attribute values may be chosen , but only one from each attribute.

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

Figure 8.3 Examples of relative distinguished names (RDNs).

We recommend not using multivalued RDNs for reasons discussed in more detail in the next section. In short, 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 of its ancestor entries. The resulting name is called a distinguished name, or DN.

In LDAP, DNs are written in little-endian order, like an email 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 multiple components of an RDN are separated by a plus sign. If these or other troublesome characters actually occur in one of the values used to form the name, they are escaped using a backslash quoting mechanism. Some examples of distinguished names are shown in Figure 8.4.

Figure 8.4 Examples of distinguished names.

More information on the LDAP namespace model, along with a formal grammar for generating and recognizing distinguished names, is described in Chapter 3.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

aliases
          namespace models
design
         namespace
                    LDAP model 2nd 3rd
                    naming entries 2nd 3rd
directories
         namespaces
                    LDAP model 2nd 3rd
                    naming entries 2nd 3rd
DNs
         namespace entries
                    little-endian order
entries
         namespace
                    naming 2nd 3rd
hierarchies
          namespace models 2nd
                    aliases
                    naming entries 2nd 3rd
little-endian order (DNs)
models
          namespace 2nd
                    aliases
                    naming entries 2nd 3rd
multivalued RDNs
          namespace entries
namespaces
          LDAP model 2nd
                    aliases
          naming entries 2nd 3rd
naming
         namespace entries
                    DNs
                    RDNs 2nd
RDNs
          namespace entries 2nd

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net