Understanding and Deploying LDAP Directory Services > 8. Namespace Design > The Structure of a Namespace |
The Structure of a NamespaceThe 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.
|
Index terms contained in this sectionaliasesnamespace 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. |