Common Ways Applications Use Directories

Understanding and Deploying LDAP Directory Services > 7. Schema Design > Elements of LDAP Schemas

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078214170105114232209169090

Elements of LDAP Schemas

In LDAP-based directories, a schema consists of attribute types, attribute syntaxes, and object classes. These terms were introduced in Chapter 3, "An Introduction to LDAP," when we described the LDAP information model, but they are described in greater detail here.

Attributes

Recall 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:

  • A name that uniquely identifies the attribute type

  • An object identifier (OID) that also uniquely identifies the attribute

  • An indication of whether the attribute is multivalued or single-valued

  • An associated attribute syntax and set of matching rules

  • A usage indicator (for applications or for operation of the directory service itself)

  • Restrictions on the range or size of the values that may be stored in the attribute

Attribute names are usually fairly short and somewhat cryptic, although they do not have to be. Attribute names have the following properties:

  • Attribute names are not case sensitive; that is, cn and CN both refer to the same attribute.

  • Characters used within attribute names are limited to ASCII letters and the hyphen character. Attribute names must begin with a letter.

  • An attribute name must be unique across your entire directory service because LDAP applications generally refer to an attribute using its name.

Examples of valid attribute names include cn , telephoneNumber , postalAddress , one-way , 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 (e.g., 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 the 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 6. 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 actually support several subcategories of operational usage). Operational attributes are used by the directory service itself for administrative or system- related purposes, and they are usually maintained by the directory servers themselves . These attributes are not visible to directory clients unless specifically asked for, and they often cannot be modified by a client.

Some examples of operational attributes are shown in Table 7.1.

Table  7.1. Examples of operational attributes
Attribute Name Where Found Description
modifyTimeStamp Any entry Date/time an entry was last modified
modifiersName Any entry Name (DN) of the entry that made the last modification
namingContexts LDAPv3 root DSE Partitions of the directory held in a server
supportedLDAPVersion LDAPv3 root DSE Versions of the LDAP protocol supported by server
aci Any entry Access control information (Netscape-specific)

Operational attributes are not returned when a directory client asks for all attributes, but clients can retrieve them by explicitly asking for them by name.

An Attribute Type Example

People 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. Its definition is shown in Listing 7.1.

Listing 7.1 The definition of the description attribute

description ATTRIBUTE ::= { WITH SYNTAX DirectoryString {1024} EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID 2.5.4.13 }

We will explain this format in more detail later in this chapter when we talk about using ASN.1 to describe schemas. Translated to English, this definition says that the attribute named description is a string that can hold up to 1024 characters. This attribute type uses the case-ignore family of matching rules; therefore, the case of letters and leading and trailing space characters are ignored when comparing values. Its OID is 2.5.4.13 , a sequence assigned by the X.500 standards committee.

Attribute Hierarchies

Some LDAP implementations, notably those closely aligned with the most recent X.500 standards, support attribute subtypes . Subtypes are used to 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 for the name attribute type will actually get back all values for name , cn , sn , and any other subtypes of name . Figure 7.1 shows a portion of the attribute hierarchy for the name attribute type.

Figure 7.1 The attribute hierarchy for the name attribute type.

Note that several other attribute types not shown in Figure 7.1 are also subtypes of name (it is a very popular supertype!).

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 Syntaxes and Matching Rules

As mentioned earlier, each attribute type has an associated attribute syntax that specifies exactly how data values are represented and how comparisons between values are made. Although in LDAP most data values are carried as text strings (unlike in X.500's DAP), there may be additional structure rules for the string. For example, the pieces of information in a postal mailing address are separated by dollar sign characters in LDAP.

Another piece of the puzzle is that special rules must be used 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; however, on a Microsoft Windows system filenames aren't case sensitive ( Windows would match WINDOWS ).

The rules used for making attribute value comparisons are called matching rules . Recent revisions of the X.500 standard separate the attribute syntax from the matching rules associated with an attribute type, but many directory service implementations still use the term syntax to refer to both the data representation itself and the matching rules. Also note that most directory server implementations support only a predetermined set of syntaxes and matching rules. Adding support for new attribute syntaxes and matching rules usually requires code to be written, or it may be impossible to do at all.

Object Classes

In LDAP, object classes are used to group related information. Typically, an object class models some 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:

  • Determines which attribute types must be included in the entry

  • Determines which attribute types may be included in the entry

  • Provides a convenient way for directory clients to retrieve a subset of entries during search operations

For example, an object class designed to hold information about people might require that a name be present and allow a number of 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:

  • A name that uniquely identifies the class

  • An OID that also uniquely identifies the class

  • A set of mandatory attribute types

  • A set of allowed attribute types

  • A kind (structural, auxiliary, or abstract)

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 your entire 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 writable 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 do not place any 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 called "Object Class Inheritance") and alias (which is used to create entry aliases, as described in Chapter 3).

Many LDAP directory server implementations, including Netscape Directory Server, do not rigidly enforce restrictions based on the kind of object classes used in a schema (e.g., 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 designing your own schema.

An Object Class Example

One of the most common uses for a directory system is to store information about people. To model this real-world object, 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 optional.

Not surprisingly, the X.500 designers had a lot 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 7.2.

Figure 7.2 The standard LDAP person object class.

The person class is a structural object class used for entries that represent people. Some name-related attributes are mandatory, and all others are optional.

The Presence of Multiple-Object Classes

There 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, the set of attributes allowed in the entry is determined by simply 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 of the required attributes listed in all the object classes. This means that if an attribute is required in one of the object classes that an entry belongs to, it is required in the entry. Note that because the entire attribute namespace is flat, LDAP avoids some of the problems of multiple inheritance that plague other systems.

For example, suppose the printer and networkDevice object classes are defined as shown in Listing 7.2 (using the simple slapd.conf schema format that is described in more detail later).

Listing 7.2 printer and networkdevice object classes

objectclass printer requires cn allows description, pagesPerMinute, languages objectclass networkDevice requires ipaddress allows cn, connectionSpeed

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 still 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 printer example in Listing 7.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 Inheritance

One object class can be derived from another, in which case it inherits some of the characteristics of the other class. This is sometimes called subclassing, or object class inheritance . An example of this is shown in Figure 7.3.

Figure 7.3 Object class inheritance.

The inetOrgPerson object class defined by the directory designers at Netscape is also supported by some 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 that another class inherits some of its characteristics from is called the superior class, or superclass (i.e., 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.

There is one special abstract object class called top , from which all structural object classes are ultimately derived. 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. However, as we have seen, 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 that the cn attribute be present, then it must always be present in all subclasses.

The LDAPv3 extensibleObject Object Class

LDAP version 3 defines a special object class called extensibleObject that is supported by many implementations. This object class allows an open -ended set of attribute types ”that is, any valid attribute is allowed in extensibleObject entries.

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 Summary

In 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 7.4 shows all the elements of LDAP schemas and how they relate to one another.

Figure 7.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 actual number of widely used object classes is also quite 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 .





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

Index terms contained in this section

abstract object classes
allowed attribute types
          object classes
attributes
          schemas
                    description 2nd
                    matching rules
                    names 2nd 3rd
                    object classes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th
                    OIDs (object identifiers)
                    operational 2nd 3rd
                    single-valued vs. multivalued
                    subtypes 2nd 3rd
                    syntaxes
                    usage indicators
auxiliary object classes
classes
         object
                    schemas 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th
comparing
          attribute values
description attribute
          schemas 2nd
directories
          schemas 2nd
                    attributes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th
extensibleObject object class (LDAPv3) 2nd
hierarchies
         attribute
                    schemas 2nd 3rd
inetOrgPerson object class
inheritance
          object classes 2nd 3rd
                    superclasses
LDAPv3
         object classes
                    extensibleObject 2nd
mandatory attribute types
          object classes
matching rules
          attribute values
mix-in classes, see auxiliary object classes
multiple object classes 2nd 3rd
          networkDevice 2nd 3rd
          printer 2nd 3rd
multivalued attributes
          schemas
names
         attributes
                    schemas 2nd 3rd
          object classes
Netscape Directory Server
networkDevice object class 2nd 3rd
object classes
          schemas 2nd 3rd 4th
                    abstract
                    allowed attribute types
                    auxiliary
                    extensibleObject (LDAPv3) 2nd
                    inetOrgPerson
                    inheritance 2nd 3rd
                    mandatory attribute types
                    multiple classes 2nd 3rd 4th 5th 6th
                    names
                    networkDevice 2nd 3rd
                    organizationalPerson
                    person example
                    printer 2nd 3rd
                    structural
                    superclasses
                    top 2nd
object identifiers, see OIDs
objectclass attribute
OIDs (object identifiers)
         attributes
                    schemas
operationa attributes
          schemas 2nd 3rd
organizationalPerson object class
person object class example
printer object class 2nd 3rd
rules
          comparing attribute values
schemas 2nd
          attributes
                    description 2nd
                    matching rules
                    names 2nd 3rd
                    object classes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th
                    OIDs (object identifiers)
                    operational 2nd 3rd
                    single-valued vs. multivalued
                    subtypes 2nd 3rd
                    syntaxes
                    usage indicators
single-valued attributes
          schemas
structural object classes
subclassing, see inheritance
subtypes
         attribute
                    schemas 2nd 3rd
superclasses
          object class inheritance
syntaxes
         attribute
                    schemas
top object class
          objectclass attribute
usage indicators
         attributes
                    schemas
values
         attribute
                    comparison rules
                    schemas

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