Elements of LDAP Schemas
| In LDAP-based directories, a schema consists of attribute types, attribute syntaxes, matching rules, and object classes. These terms were introduced in Chapter 2, Introduction to LDAP, when we described the LDAP information model, but they are described in greater detail here. AttributesRecall that directory entries contain a collection of attribute types and values. Attribute types (or simply attributes ) hold specific data elements such as a name , business phone number, or printer's rated speed in pages per minute. In LDAP, the definition of an attribute type includes the following:
Attribute names are usually fairly short and somewhat cryptic, although they do not have to be. Attribute names have the following properties:
Examples of valid attribute names include cn , telephoneNumber , postalAddress , one-way , faxPhone2 , and pagesPerMinute . Some examples of invalid attribute names are last#, 2for2 , my.boss , and favorite_drink . Some standard attributes have historically been known by both a longer name and a shorter name (for example, commonName and cn ), but in most cases the shorter name is the standard that LDAP clients and servers use. Confusion about which attribute name to use caused LDAP client and server interoperability problems in the past. Some implementations , such as Netscape Directory Server, support longer names as aliases or synonyms for the shorter, standard names to increase compatibility with older LDAP applications. An attribute's OID is a unique numerical identifier usually written as a sequence of integers separated by dots. For example, the OID for the postalAddress attribute is 2.5.4.16 . OIDs are required by X.500 directory implementations because they are used within the X.500 family of protocols to identify attribute types. Although LDAP clients and servers can use OIDs in place of attribute names, names are almost always used in practice because they are much easier to work with than OIDs. In an entry stored in a directory server database, attributes have one or more attribute values associated with them. These values correspond to the data element values discussed in Chapter 7, Data Design. The attribute type provides the semantic meaning for a set of values. For example, the value 12 by itself is not very meaningful; but if you know that it is a value for the pagesPerMinute attribute, you can begin to imagine several uses for the value. The definition of the attribute type includes an indication of whether the type is allowed to hold only one value (single-valued) or several values (multivalued). Most attribute types are multivalued, which is the default. The attribute usage indicator is usually omitted from the definition of an attribute type because it defaults to user applications, which means that the attribute is of general purpose and can be used by any directory application. The other type of usage is operational (note that X.500 systems support several subcategories of operational usage). Operational attributes are used by the directory service itself for administrative or system- related purposes and are usually maintained by the directory servers themselves . These attributes are not visible to directory clients unless specifically requested , and a client typically cannot modify them. Table 8.1 shows some examples of operational attributes. Clients can retrieve operational attributes by explicitly asking for them by name. Work is also under way in the Internet Engineering Task Force (IETF) to define an LDAP control that allows a client to request the return of all operational attributes. Tip Once the forthcoming LDAPv3 control to retrieve all operational attributes has been widely implemented, it will be easy to retrieve all the attributes of an entry using one LDAP search command. In the meantime, you can perform an LDAP search command and ask for * (which stands for all regular attributes) plus a list of desired operational attributes. If you want to retrieve all the operational attributes that are present, you must first generate a list of the ones supported by your server. You can do this by consulting the server's documentation or by reading the server's schema over LDAP and using a scripting language such as awk or Perl to extract the attribute types that are marked as operational. See the section titled The LDAPv3 Schema Format later in this chapter for more information about how LDAP servers store schemas and how they can be retrieved over LDAP. An Attribute Type ExamplePeople generally like names and are pretty good at remembering them. Almost all real-world objects have a name of some kind, and we have already mentioned the cn (common name) attribute several times. Sometimes, though, it is helpful to associate longer text with an LDAP entry that describes the entry in more detail. LDAP defines a handy attribute called description for just that purpose. Listing 8.1 shows its definition. Table 8.1. Examples of Operational Attributes
Listing 8.1 The description Attribute( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch We will explain this format in more detail later in this chapter when we talk about using the LDAPv3 format from RFC 2252 to describe schemas. Translated into English, this definition says that the attribute named description is a string that can hold up to 1,024 characters. This attribute type uses the caseIgnore family of matching rules; therefore, the case of letters and leading and trailing space characters are ignored in comparisons of values. The OID of this attribute type is 2.5.4.13 , a sequence assigned by the X.500 standards committee. Attribute HierarchiesSome LDAP implementations, notably those closely aligned with the most recent X.500 standards, support attribute subtypes . Subtypes define attribute hierarchies in which general attribute types can be used to construct more specific types. For example, X.500 defines the cn attribute as a subtype of an attribute called name . Similarly, the sn ( surname ) attribute is also a subtype of name . The attribute called name is said to be the supertype of cn, and cn is said to be derived from name . Attribute subtypes inherit the characteristics of their supertype. In addition, a supertype can be used to simplify searches and retrieval of attributes derived from it. For example, because both the cn and sn attributes are subtypes of the attribute name , a search request that asks for all values of the name attribute type will get back all values of name , cn , sn , and any other subtypes of name . Figure 8.1 shows a portion of the attribute hierarchy for the name attribute type. Note that several other attribute types not shown in Figure 8.1 are also subtypes of name (it is a popular supertype!). Figure 8.1. The Attribute Hierarchy for the name Attribute Type Attribute subtypes are an interesting but potentially confusing feature. Most LDAP implementations do not even support attribute subtypes. Even if you like the idea of subtypes, think twice before you design a schema that relies on them. Attribute SyntaxesAs mentioned earlier, each attribute type has an associated attribute syntax that specifies exactly how data values are represented. Just as each attribute type has an OID, each syntax has one too. Although in LDAP most data values are carried as text strings (unlike in X.500's Directory Access Protocol, or DAP), additional rules may apply to the string. For example, dollar signs ($) are used to separate the pieces of information in a postal mailing address in LDAP. Table 8.2 shows some standard syntaxes. The great majority of attribute types have the DirectoryString syntax. Note that some LDAP server software packages, such as Netscape Directory Server, allow additional syntaxes to be defined through the use of software plug-ins, but generally the set of supported syntaxes is limited by the directory server software. Matching RulesAnother piece of the puzzle is that LDAP clients and servers must use special rules when comparing the values of different attribute types. For example, when comparing filenames on a Unix system, the case of the letters must be taken into account; on a Microsoft Windows system, however, filenames aren't case sensitive (for example, Windows would match WINDOWS ). The rules used for making attribute value comparisons are called matching rules . Table 8.3 shows some standard matching rules. Some directory service implementations still use the term syntax to refer to both the data representation itself and the matching rules because in the early X.500 standards no distinction was made. Also note that most directory server implementations support only a predetermined set of matching rules. Adding support for new matching rules usually requires code to be written, or it may be impossible to do at all. Table 8.2. Standard Syntaxes
Table 8.3. Standard Matching Rules
Object ClassesIn LDAP, object classes are used to group related information. Typically, an object class models a real-world object such as a person, printer, or network device (although this is not required). Each directory entry belongs to one or more object classes. The names of the object classes to which an entry belongs are always listed as values for a special multivalued attribute called objectclass . The set of object classes associated with an entry serves the following needs:
For example, an object class designed to hold information about people might require that a name be present and allow specific optional attributes to be included to hold personal and contact information about a person. If the object class is called person , a directory client could provide a way to search for only people entries by adding a component such as objectclass=person to the LDAP search filter it constructs. The definition of an LDAP object class includes all the following pieces of information:
The name of an object class is usually mnemonic and easily understood by humans, but good directory clients try to hide these names from end users. A name is the most common way for humans , clients, and servers to refer to the object class. As for attribute types, both the name and OID must be unique throughout the directory service. Some examples of object class names include person , printer , groupOfNames , and applicationEntity . The set of mandatory (required) attribute types is usually fairly short or even empty. The set of allowed (optional) attribute types is often quite long. It is the job of each directory server to enforce attribute type restrictions of an object class when an entry is added to the directory or modified in any way. The one exception is that read-only directory replicas do not need to check for schema violations; they can simply rely on the updatable server that supplies them to do the checking. The kind of object class indicates how the class is used. Structural classes , for example, describe the basic aspects of an object. In some directory server implementations, structural classes can be used to place restrictions on where an entry can be stored within the directory information tree (DIT). Most object classes are structural classes, and all entries should belong to exactly one structural object class. Examples of structural object classes include person and groupOfNames . Auxiliary classes place no restrictions on where an entry may be stored, and they are used to add a set of related attributes to an entry that already belongs to a structural class. As many auxiliary classes as desired can be "mixed in" to an entry; thus, auxiliary classes are sometimes called mix-in classes . Examples include simpleSecurityObject , mailRecipient , and cacheObject . Abstract classes , the third and last kind of object class, are rare and are used only for classes needed to support LDAP's basic information model. Two examples of abstract classes are top (discussed later in this chapter in the section titled Object Class Inheritance) and alias (which is used to create entry aliases, as described in Chapter 2, Introduction to LDAP). Some LDAP directory server implementations, including Netscape Directory Server, do not rigidly enforce restrictions based on the kind of object classes used in a schema (for example, they do not prevent you from creating an entry with two structural classes). However, the distinctions implied by the different kinds of classes are useful when you're designing your own schema. An Object Class ExampleOne of the most common uses of a directory system is to store information about people. To model these real-world "objects," we might define an object class called person . The information about people that is typically stored in a directory service includes name, contact information, department, job title or position, and any information needed to support software applications. For each piece of information, we would define an attribute type. For naming entries and to help directory clients, we may want to require that all person entries include a name. Other attributes would be allowed in an entry but would be optional. Not surprisingly, the X.500 designers had many of these same thoughts and defined a standard person object class that was adopted by the LDAP designers as well. It is shown in Figure 8.2. The person class is a structural object class used for entries that represent people. Some name-related attributes are mandatory; all others are optional. Figure 8.2. The Standard LDAP person Object Class The Presence of Multiple-Object ClassesThere is no limit to the number of different object classes a single entry can belong to, as long as only one of the classes is a structural class. If an entry belongs to more than one object class, we determine the set of attributes allowed in the entry simply by computing the union or aggregate of the attributes listed in all the object classes. Similarly, the set of mandatory attributes is the union of all the required attributes listed in all the object classes. This means that if an attribute is required in one of the object classes to which an entry belongs, it is required in the entry. The entire attribute namespace is a flat space with no hierarchy or other structure within the names. For example, suppose that the printer and networkDevice object classes are defined as shown in Listing 8.2 (using the LDAPv3 schema format described in more detail later in this chapter; of course, OIDn and OIDp would need to be replaced with real, numeric OIDs). Listing 8.2 printer and networkDevice Object Classes( OIDp NAME 'printer' SUP top STRUCTURAL MUST cn MAY ( description $ pagesPerMinute $ languages Given these definitions, the following attributes must be present in any entry that belongs to both classes: cn ipaddress The following attributes are optional: connectionSpeed description languages pagesPerMinute Notice that because the cn attribute is required in the printer class, a cn value must always be present in entries that belong to both classes (even though it is merely optional in the networkDevice class). Tip Even if an attribute type is listed in more than one object class, an entry that belongs to both classes has only one instance of that attribute type. That is, the attribute type space is flat and unrelated to the way in which attributes are assigned to object classes. In the example in Listing 8.2, it is impossible to distinguish between the cn attribute included in the printer class and the cn attribute included in the networkDevice class. They are the same attribute, and there is only one set of cn values in an entry that belongs to both object classes. Object Class InheritanceOne object class can be derived from another, in which case it inherits some characteristics of the other class. This is sometimes called subclassing , or object class inheritance . Figure 8.3 shows an example. Figure 8.3. Object Class Inheritance The inetOrgPerson object class defined by the directory designers at Netscape is also supported by most other implementations. It extends the person class and includes additional attribute types to store data elements commonly used on the Internet and within organizations. It is actually derived from an intermediate class called organizationalPerson , which is derived from the person class. Therefore, inetOrgPerson entries require all the attributes required of organizationalPerson entries (and therefore of person entries as well). Similarly, inetOrgPerson entries are allowed to include any of the optional attributes from the superior classes. In general, the class from which another class inherits some of its characteristics is called the superior class , or superclass (that is, organizationalPerson is the superior class of inetOrgPerson ). When one class is derived from another, it inherits the set of required attribute types, the set of optional attribute types, and the kind of object class from its superior. Also, an exception to the rule mentioned previously (each entry may belong to exactly one structural class) is that entries may belong to two or more structural classes if the classes are derived from each other. All structural object classes are ultimately derived from one special abstract object class called top . The definition of the top class consists of a single mandatory attribute called objectclass , which ensures that all LDAP entries contain at least one value for objectclass . Be careful when comparing LDAP's object class inheritance with the more sophisticated class inheritance supported by many object-oriented programming languages. For example, LDAP implementations do not support multiple inheritance, in which a single object class is derived from two or more superior classes. As we have seen, however, LDAP does support aggregation because an entry can be a member of more than one object class. Also there is no way to "override" any of the schema rules defined by the superior class. For example, if the superior class requires the cn attribute to be present, then it must always be present in all subclasses. The LDAPv3 extensibleObject Object ClassLDAPv3 defines a special object class called extensibleObject that is supported by all compliant implementations. This object class allows an open -ended set of attribute types ”that is, any valid attribute is allowed in extensibleObject entries. Note that the attribute types must be defined in the schema; using extensibleObject only eliminates the requirement that the correct object classes be included in an entry. In general, this class is rarely used, for the same reasons that most administrators do not entirely disable schema checking: It may give users and applications too much freedom to store unstructured data in the directory. This class can be useful when you want to create entries that are largely free from schema constraints, especially if it is used by only a small set of applications that you control. Schema Element SummaryIn summary, LDAP schemas are made up of attribute types, each of which has a syntax and a set of matching rules. Attributes are used to hold specific kinds of data, and they are grouped into logical units through the definition of object classes. It is the job of each directory server to enforce the restrictions imposed by the schemas when entries are created or modified. Figure 8.4 shows all the elements of LDAP schemas and how they relate to one another. Figure 8.4. Directory Schema Elements Tip The schemas used by a directory service typically include dozens of object classes and hundreds of attribute types. Thankfully, the number of attribute syntaxes is usually small (a dozen or fewer), and the number of widely used object classes is also limited. Do not be overwhelmed by the number of available schemas. Focus on your needs and use an incremental approach as you select schema elements for your service. |
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) 
EAN: 2147483647
Pages: 242