Information Model

---

LDAP, the lightweight counterpart of the X.500 DAP, was first used as a front-end process to access X.500 via a gateway. Thus it is not surprising to learn that LDAP inherits one of the cornerstones of its architecture, the information model, from X.500. The information model contains many new concepts. Let us briefly review what you will encounter in this chapter.

You will learn that the information model is all about entries. These entries are made up of attributes, each attribute having an attribute type and one or more attribute values. The attribute type defines exactly the kind of values an attribute can hold, i.e., numbers, case-sensitive letters, case-insensitive letters, phone numbers, etc. This is achieved by the use of "syntax definitions." The attribute type also defines how the single attribute values are to be compared in the case of queries. This is achieved by the use of "matching rules."

Once we have a basic understanding, we can look at the details. It is possible to begin working with LDAP without a deep knowledge of the details, so if you are in a hurry to get to work, you can skip the details and come back later if you want to learn more. On the other hand, it is helpful to have a certain understanding of what is really going on. LDAP is defined in a number of RFCs. Unfortunately, the various implementations of this standard make their own extensions of these standards. Moreover, they often use their own syntax in configuration files or in the documentation delivered with the product. It is helpful to distinguish between what the standard requires and what the standard allows. Confronted with your particular implementation, you will find differences in the syntaxes used in the configuration file. This chapter will give you some help to understand the underlying concepts. Once you know what is going on "under the hood," you are less likely to be confused by the appearance of "strange names and numbers" in the configuration files of your LDAP product.

The following introductory section provides an overview of the whole picture to give you a rough understanding of the information model. In the later sections, we will look into the details. I hope that this approach keeps you from getting lost in details without understanding how the single pieces fit together.

Introduction

This introductory section gives a brief overview of the information model. The basic unit of information is the entry. We will see that the object class defines how an entry should look. Entries are made up of attributes, and just as entries are defined by object classes, so attributes are defined by the "attribute types." Everything is held together by the schema of the directory. Therefore we will now have a look at entries, objects, and object classes and see how these concepts are related. To make things easier, we will begin with an example.

The information model is centered on entries. To understand that better, let us have a look at a typical directory. Exhibit 1 shows you the content of a directory exported into an ASCII file. We use the directory that we created in Chapter 2, so you will be somewhat familiar with its content. Note that Exhibit 1 shows only a small part of the directory. The format of the ASCII file used here is called LDIF (LDAP data interchange format) and is standardized in RFC 2849, "The LDAP Data Interchange Format (LDIF) — Technical Specification." We have just seen the LDIF format in Chapter 2, and Chapter 4 examines LDIF in greater depth.

 dn: o=ldap_abc.de objectclass: top objectclass: organization o: ldap_abc.de 1: Munich dn: ou=IT, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Information Technologies dn: ou=HR, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: HR description: Human Resources dn: uid=RVoglmaier, ou=IT, o=ldap_abc.de objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson ou: IT cn: Reinhard Erich Voglmaier cn: Reinhard E. Voglmaier cn: Reinhard Voglmaier sn: Voglmaier givenName: Reinhard Erich uid: RVoglmaier mail: ReinhardVoglmaier@ldap_abc.de mobile: [phone] dn: uid=SParker, ou=HR, o=ldap_abc.de objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson ou: HR cn: Sarah Parker sn: Parker givenName: Sarah uid: SParker mail: SarahParker@ldap_abc.de 

Exhibit 1: Example of Entries

Exhibit 2: Relationship between Entries and Attributes

The excerpt of the directory shown in the exhibit can be broken down into smaller data structures. These data structures are the "entries" or objects that we will explore in this chapter. Exhibit 1 shows three different types of entries. The first type of entry describes the whole organization, the second a single organizational unit, and the third a single person.

Note that each of these entries begins with a field labeled "dn," an abbreviation of "distinguished name." This field identifies the entry unambiguously and has to be unique within the entire directory. Notice furthermore that each entry also contains information describing what it is or, more precisely, to which object class it belongs. This information is called "objectClass."

To summarize, we have three different types of objects, each representing a different object class:

1. The whole organization is identified by an "o":

    o=ldap_abc.de 

2. The individual departments, called "organizationalUnit," are abbreviated with "ou":

    ou=IT, o=ldap_abc.de ou=HR, o=ldap_abc.de 

3. The entry for a single person, called "inetOrgPerson," is identified as follows:

    uid=RVoglmaier, ou=IT, o=ldap_abc.de uid=SParker, ou=HR, o=ldap_abc.de 

Each entry corresponds directly to an object in the real world, i.e., a person, a printer, a computer, an organization, etc.

Looking at Exhibit 1 again, note that each entry consists of several lines, with each line corresponding to one attribute. In other words, an entry is a collection of attributes. One of these attributes, the distinguished name (DN), we have already seen before. The distinguished name uniquely identifies the entry within the directory. We have also seen the attribute "objectClass." Note that the attribute "objectClass" is one of the attributes that can have more than one value.

Every attribute is made up of two pieces of information: the attribute name and one or more attribute values. Exhibit 2 shows how entries and attributes are related. Note that LDAP knows what entries can be inserted into the directory from its configuration files, which contain a number of class definitions and attribute-type definitions. The entries in the directory are instances of the classes defined in the configuration files, and the attributes building the entries are defined by the attribute types, such as the classes, fixed in the configuration files. Consider an object of the type "person." The entry for "person" contains such attributes as name, surname, phone number, etc. For example, there is an attribute with the name "surname" and the value "Voglmaier." For now, it is enough to understand that the directory contains a number of entries, each of them mapping real-world objects and consisting of a number of attributes.

If LDAP is to function as a well-behaved repository, it must have rules specifying how information is to be stored. The collection of these rules is called a "schema," and the schema information is kept in the configuration files. Using version 3 of the LDAP protocol, the client can explore the schema that the server is using. You may be familiar with the concept of a schema if you have experience working with a relational database management system (RDBMS). The schemas used by both systems are similar, but there are some important differences:

• LDAP software ships with a number of working schemas. The user selects a schema and begins filling in the data. With RDBMS software, the first thing the user has to do is define the schema. Until the schema is defined, the RDBMS software is useless.

• The LDAP schema is simpler and does not know anything about complicated structures such as "joins," nor are there any triggers, i.e., procedures to be executed when the data is inserted, deleted, or updated.

The schema in LDAP is defined in RFC 2252, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions":

The Schema is a collection of object class definitions and attribute type definitions and other information which a server uses to determine how to match a filter or attribute value assertion (in a "compare" operation) against the attributes of an entry, and whether to permit "add" and "modify" operations.

The schema therefore contains:

• Object-class definitions describing the different types of entries in the directory

• Attribute-type definitions describing the different attributes of the objects

• Syntax definitions to describe how the attribute values are to be compared during queries

At this point, you have an overview of the important aspects of the information model. You understand the concepts of entry and attribute, and you know that both of them are defined in configuration files in the form of object classes and attribute types. You know what a schema is and that a client can explore the contents of the schema. Now we will revisit all these preceding points in greater detail. We begin our journey through the information model with a section dedicated to the object classes.

Object Classes

A directory typically holds a large number of objects. The objects stored in the directory are called "entries." These entries in the directory correspond then to "real objects" in "the real world." Every entry in the directory is made up of a number of attributes, and each entry must have at least one attribute of the attribute type "objectClass."

If you write an application using an object-oriented language, the first thing you do is define classes. After that, you can define objects to implement the previously defined classes. The same thing holds in LDAP. Every directory is configured to recognize a number of classes, called "object classes." The objects in the directory (called "entries" in LDAP parlance) are implementations of these classes. In other words, the object class defines the nature of the entries in the directory. Every directory server implementation therefore needs a number of object-class definitions specifying the type of entries the directory can hold.

Let us revisit the previous example and look at Exhibit 1, which contains five entries. (Each entry begins with "dn:".) These five entries implement a total of three different object classes: the object class "organization," the object class "organizationalUnit," and the object class "inetOrgPerson." Therefore, we have:

• One object or entry implementing the object class "organization":

   o=ldap_abc.de 

• Two objects (entries) implementing the class "organizationalUnit":

   ou=IT, o=ldap_abc.de ou=HR, o=ldap_abc.de 

• Two objects (entries) implementing the class "inetOrgPerson":

   uid=RVoglmaier, ou=IT, o=ldap_abc.de uid=SParker, ou=HR, o=ldap_abc.de 

You may be wondering why some entries (objects) have more than one value for the attribute "objectClass." New object classes can be constructed hierarchically by inheriting characteristics from an existing object class. For instance, the object class "organization" is derived from the "root" object class by inheritance. The root of all object classes, i.e., the object class from which all other object classes are inheriting, is the object class "top." Thus the object class "inetOrgPerson" derives from the previous object class "organizationalPerson," which inherits from the previous object class "person," which in turn inherits from the root object class "top." Given this hierarchical system of inheritance, we can see why most entries "belong" to more than one object class: Each entry belongs to a specific object class as well as the ladder of increasingly broader classes from which it was derived. The attribute "objectClass" describes all of the object classes to which the entry belongs.

The fact that an entry can belong to several object classes caused us to do some extra typing in Chapter 2, when we had to key in all of the object classes to which the object "person" belongs. In reality, these lines were just a shortcut for the list of characteristics of the single classes. In other words, instead of writing the characteristics of each object class, write only the object class. We will learn more about object-class inheritance later on. For the moment, it is enough to understand why the attribute "objectClass" has more than one value.

Some attributes in an entry are required, while other attributes are optional. Attributes that are neither required nor optional are not allowed at all. Thus every objectClass declaration contains a list of optional attributes and a list of required attributes for that specific object. Again, the reason for the multivalued attribute "objectClass" becomes clear. If an entry has more than one objectClass value, the entry must contain the union of all required attributes and may contain the union of all optional attributes of the object classes it implements.

The root object class "top" is the ancestor of all object classes and contains the required attribute "objectClass." Since all entries inherit directly or indirectly from the root "top," every object class MUST contain the attribute "objectClass." However, as we will learn later, the root object class cannot be used directly.

An example makes this clear. The object with the distinguished name "o = ldap_abc.de" implements the object class organization. Exhibit 1 shows that the attribute "objectClass" of this entry has the two values: "top" and "organization." Now look at Exhibit 3, which contains the object class definitions of "top" and "organization." The definition shows which attribute are required (MUST) and which attributes are optional (MAY). We see that "top" must only contain the attribute "objectClass." "Organization," on the other hand, inherits all attributes from top and must also contain o (organization). This means that the entry must contain the attributes "objectClass" and o (organization). We further note that "top" does not have any optional attributes. In contrast, "organization" has many optional attributes: userPassword, searchGuide, seeAlso, businessCategory, x121Address, registeredAddress, destinationIndicator, preferredDeliveryMethod, telexNumber, teletexTerminalIdentifier, telephoneNumber, internationaliSDNNumber, facsimileTelephoneNumber, street, postOfficeBox, postalCode, postalAddress, physicalDeliveryOfficeName, st, 1, and description.

Objectclass top:

 (2.5.6.0  NAME 'top'  ABSTRACT  MUST (  objectClass  ) ) 

Objectclass organization:

 (2.5.6.4  NAME 'organization'  SUP top  STRUCTURAL  MUST (   o  MAY (   userPassword   searchGuide   seeAlso   businessCategory   x121Address   registeredAddress   destinationIndicator   preferredDeliveryMethod   telexNumber   teletexTerminalIdentifier   telephoneNumber   internationaliSDNNumber   facsimileTelephoneNumber   street   postOfficeBox   postalCode   postalAddress   physicalDeliveryOfficeName   st   1   description  ) ) 

Exhibit 3: Object-Class Definition for top and organizationalUnit

In this section we have learned what an object class looks like and that new object classes can be obtained from existing ones through inheritance.

Formal Definition of Object Classes

Before looking at further examples, let us see how object classes can be defined formally. This is not the only way you will find object classes defined, but this is the form you will find in most RFCs. Once you have seen this type of object-class definition, you will understand other syntaxes as well.

Exhibit 4 shows such an object-class description drawn from RFC 2252, "LADP (v3) Attributes." The syntax used in this RFC is Backus Naur form (BNF), used also in the construction of compilers, where it provides the formal description of the syntax of the language understood by the compiler. Following are some lines explaining the example cited in Exhibit 4.

 ObjectClassDescription = "(" whsp  numericoid whsp ; ObjectClass identifier  [ "NAME" qdescrs ]  [ "DESC" qdstring ]  [ "OBSOLETE" whsp ]  [ "SUP" oids ] ; Superior ObjectClasses  [ ("ABSTRACT"/"STRUCTURAL"/"AUXILIARY") whsp ]  ; default structural  [ "MUST" oids ] ; AttributeTypes  [ "MAY" oids ] ; AttributeTypes  whsp ")" 

Exhibit 4: Object-Class Description from RFC 2252

• whsp: White space

• numericoid: Numeric object identifier (OID)

• oid: Either a numericoid or a human-readable description

• qdescr: A quoted description

• qdstring: A quoted-string UTF8-encoded string

• Strings included in round parentheses "()" are to be typed as they are. For example, "(" means that an object-class definition begins with a parenthesis.

• Strings surrounded with square brackets are optional. For example, the line ["NAME" qdescrs] means: NAME "inetOrgPerson."

• A semicolon ";" indicates that the line is a comment.

With this information at hand, let us look at the previous syntax of an object-class definition. It tells us that every description of an object class must contain first the numeric object identification of this object class. We will return to this object identification after a few examples of object-class descriptions. The remaining data — included in square brackets — is optional. Each of these lines is in the form of a keyword in capitals enclosed within quotation marks and an optional value. The allowed keywords are defined as follows:

• "NAME" is simply the name of the object.

• "DESC" is a human-readable description of the object.

• "OBSOLETE" does not need a value. It indicates that this object should not be used any more and exists only for compatibility with older implementations.

• "SUP" contains the OID of the object superclass. Here we see the reason for the existence of both "oid" and "numericoid." "Numericoid" is an OID consisting of only numbers, but the OID can also contain the description defined with the keyword "DESC," thus making it understandable to a human reader.

• "ABSTRACT"/"STRUCTURAL"/"AUXILIARY" are the three possible values used to specify the type of the object class. Every object can be one of these three types. In BNF the "/" means "or," so in this case it means one of these three keywords. You will learn more about these object types later, after the examples.

• "MUST" defines one or more attributes that an object of this class is required to contain.

• "MAY" defines the attributes that an object of this class may contain.

Some Words about Object-Class Inheritance

Before we get to the examples, we have a few more words about object classes and inheritance. As the object-oriented paradigm states, you do not have to reinvent the wheel every time you define a new object type. Instead, you can inherit from an existing object. In LDAP, this is achieved by inheriting from object classes.

As we have seen earlier, the fact that one object class inherits from another is expressed in LDIF format using the "objectClass" attribute. You see it furthermore for the attribute objectClass using the command-line tools when you have to type in several lines when you add new-entries into the directory. However, the knowledge of inheritance should simply be defined in the directory schema or, better yet, in the standard definition of the object classes. Indeed, looking back to the previous section, you will notice the keyword "SUP" in the object-class definition.

The keyword "SUP" indicates the superclass from which the actual class is inheriting. This new class inherits all of its attributes from its ancestor. Therefore, the new class must contain all of the required attributes of the superclass plus the additional required attributes that define the new class. In addition, it may also contain all the optional attributes from its superclass along with any optional attributes defined in the new class. Attributes that are not defined in the superclass or in the actual class are not allowed at all.

All object classes have one common origin, the object class "top." It is also possible to subclass again an object class that is derived from another object class. A good example is the object class "inetOrgPerson," which is derived from the object class "organizationalPerson," which in turn is derived from "person," which, at last, has the parent "top."

Some Examples of Object-Class Definitions

To gain a better understanding of the concept of inheritance with object classes, take a look at Exhibit 5 through Exhibit 8, which show examples of object-class definitions for the object class "inetOrgPerson" that we encountered in Exhibit 1. This also illustrates the concept of multiple inheritance.

The object class "top" in Exhibit 5 is one of the simplest object classes. As mentioned previously, all object classes derive from the object class "top." The only purpose for the object class "top" is to ensure that every object contains the "objectClass" attribute, since it is the only required attribute in the object class "top." It exists only to be subclassed, as indicated by "ABSTRACT" in Exhibit 5. An object class not intended to be instantiated is called an "abstract object class." This means that you will not find an entry for object class "top" in the directory. The object class "top" holds only one (the only and required) attribute, the attribute "objectClass." Because every object class inherits from "top," every object class must contain the attribute "objectClass."

 (2.5.6.0   NAME 'top'   ABSTRACT   MUST (    objectClass   ) ) 

Exhibit 5: Example of Object-Class Definition, objectClass Top

Exhibit 6 shows the objectClass "person," which derives from "top." Besides the attribute "objectClass" inherited from "top," every "person" entry also must have the attributes "sn" and "cn." The line with "SUP top" expresses that the object class "top" is its ancestor. We also could use the numeric OID here, so we could say as well:

 SUP '2.5.6.0' 

 (2.5.6.6   NAME 'person'   SUP top   STRUCTURAL   MUST (    sn $ cn   )   MAY (     userPassword $ telephonNumber $ seeAlso $ description   ) ) 

Exhibit 6: Example of Object-Class Definition, objectClass Person

The only difference is that an alphabetic OID is more easily understood by a human user. Note that the attributes "userPassword," "telephone-Number," "seeAlso," and "description" are optional.

Exhibit 7 shows the object class "organizationalPerson," which is derived from, and is a specialization of, the object class "person." The organizationalPerson object class has a number of attributes useful for implementing an employee object, such as fax number, organizational unit, and so on. This means that, in addition to the optional attributes "userPassword," "telephoneNumber," "seeAlso," and "description" defined in the object class "person," the organizationalPerson object can also contain a title or any of the added properties indicated by the keyword "MAY." Note that no new required attributes are added, although the organizationalPerson still needs to contain the inherited required attributes "objectClass," "sn," and "cn."

 (2.5.6.7  NAME 'organizationalPerson'  SUP person  STRUCTURAL  MAY (    title $ x121Address $ registeredAddress $destination Indicator $    preferredDeliveryMethod $ telexNumber $ teletexTerminal Identifier $   telephoneNumber $ internationaliSDNNumber $    facsimileTelephoneNumber $ street $ postOfficeBox $    postalCode $    postalAddress $ physicalDeliveryOfficeName $ ou $ st $ 1   ) ) 

Exhibit 7: Example of Object-Class Definition, Object Class "organizationalPerson"

The last item in the inheritance chain is the "inetOrgPerson" object class (see Exhibit 8), important enough to be defined in a separate RFC (RFC 2798, "Definition of the inetOrgPerson LDAP Object Class"). This class was intended to accommodate information about a person in a typical Internet/Intranet environment. Indeed, attributes like mail, userSMIMECertificate, and jpegPhoto have been added, as were other useful attributes like businessCategory or roomNumber which were still missing from "organizationalPerson."

 (2.16.840.1.113730.3.2.2  NAME ' inetOrgPerson '  SUP organizationalPerson  STRUCTURAL  MAY (    audio $ businessCategory $ carLicense $ departmentNumber $    displayName $ employeeNumber $ employeeType $ givenName $    homePhone $ homePostalAddress $ initials $ jpegPhoto $    labeledURI $ mail $ manager $ mobile $ o $ pager $    photo $ roomNumber $ secretary $ uid $ userCertificate $    x500uniqueIdentifier $ preferredLanguage $    userSMIMECertificate $ userPKCS12  ) ) 

Exhibit 8: Example of Object-Class Definition, objectClass InetOrgPerson

Object-Class Types

As mentioned previously, there are three types of object classes:

1. Abstract

2. Structural

3. Auxiliary

An object in LDAP is a representation of a real-world object in the directory. Real-world objects can be classified using a set of common properties. In LDAP parlance, you would say that the classification is based on a common set of attributes. Classification in LDAP leads, via subclassing, to a certain object hierarchy.

The upper level of this hierarchy is built by classes of the type "abstract." Classes from the object class "abstract" are not intended to be actually implemented. An example is the "top" class. There is no entry implementing the object class "top," but it is from this class that all other classes are derived. The "top" class exists to ensure that all classes derived from it contain the attribute "objectClass." Consequently, there is no need to use an object of this class.

Objects whose object class is of the type "structural" can be stored in the directory. Examples of this type are person, organizationalPerson, and inetOrgPerson. Some server implementations use structural classes to define where in the directory information tree a certain object can be stored.

We could just be happy with these two object types, so what is the third one for? This is for situations when you need a new object class extending from an existing one. Unfortunately, new data such as this does not fit very well in the object structure. To get around this problem, you can define all the data the new object needs to hold together in an auxiliary class. An object of type "auxiliary" can be attached anywhere in the directory information tree.

An example of an object of the type "auxiliary" is the extensible-Object that can hold any number of attributes defined in the schema. Another example is the subschema object, which holds the schema for the directory server, i.e., object-class definitions, attribute-type definitions, matching rules, etc.

A further example of an auxiliary object class is the "dcObject" class. The abbreviation stands for "domain component object." It is used to describe objects having DN being similar to DNS like domain names. The object class "dcObject" has the attribute "dc," which stands for "domain component." More about this in the section called "Directory Suffix," which appears later in the chapter. This dcObject class can be used to implement an organization object with the DN: dc=I.dapAbc,dc=org.

You cannot use the object class "o," because this objectClass does not allow the attribute "dc." The object class "dcObject," on the other hand, does not allow the attribute "o" or "description." The solution is to mix the two; the auxiliary object class allows this mixing. You can, therefore, obtain the following entry:

• DN: dc=LdapAbc,dc=org

• objectclass: top

• objectclass: dcObject

• objectclass: o

• dc: LdapAbc

• dc: org

• o: Abc's of LDAP

• description: Organization promoting usage of LDAP

• 1: Munich

Object Identifiers

Object identifiers (OIDs) are not only used for object classes, but also for attribute types. The concept of OID is another important concept imported into LDAP from the X.500 standard. The OID standard is not limited only to object classes and attribute types. It can be used to identify uniquely any type of object. It is not only used for LDAP and X.500, but also for other protocols such as SNMP (Simple Network Management Protocol), just to mention one frequent "user."

An OID is syntactically a string of numbers divided by dots, such as the OID 2.5.6.6 for the object class "person" (see Exhibit 6) or 2.16.840.1.113730.3.2.2 for the object class "inetOrgPerson" (see Exhibit 8). The namespace of all OIDs implements an OID tree. A subtree in the OID tree is called an "arc." This concept greatly simplifies the administration of the OID tree, inasmuch as it allows one to delegate administration of the subtrees or arcs.

You can get your own OID subtree from IANA (Internet Assigned Numbers Authority). Their Web site (http://www.iana.org) provides further information. The particular syntax makes it possible to understand where a certain object comes from. All you have to do is trace the route from the object to the root of the tree to understand the object's origin. For example, all attributes and objects defined by the IETF begin with 2.5.4, e.g., 2.5.4.0 for the attribute "object-Class."

You will need an OID subtree whenever you need to extend the directory schema. You can, of course, invent your own OIDs. However, you will run into trouble if you have to exchange information with systems that have reserved this OID for another purpose. So if you extend your schema, it is wise to ask for an OID and to construct your own hierarchy based on this OID. Remember to keep a list for what OID is used for which object to avoid name collisions.

A good introduction and much more information can be obtained from the Web site of Harald Alvestrand at http://www.alvestrand.no/objectid. From this site, you can also navigate in the OID tree.

Attribute-Type Definitions

Just as there are standard object classes known by all LDAP servers, there are also standard attributes for the classes. Some of these attributes we have already seen, for example the attribute called "objectClass." Every entry in the directory has two or more attributes (one of these being the attribute "objectClass"). Every attribute has an attribute name and one or more attribute values. Now we will look somewhat closer at the attribute types.

The attribute types all LDAP servers should implement are described in RFC 2252, "Lightweight Directory Access Protocol: Attribute Syntax Definitions." Before proceeding any further, see Exhibit 9 — showing a couple of attributes — to get an idea of what an attribute definition looks like. As you might surmise, attribute types can also inherit from each other. That happens, for example, with sn and c, which both derive their definition from the attribute type "name."

 (2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch   SUBSTR caseIgnoreSubstringsMatch   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}) (2.5.4.4 NAME 'sn' SUP name) (2.5.4.6 NAME 'c' SUP name SINGLE-VALUE) 

Exhibit 9: Examples of Attribute Definitions from RFC 2256

Formal Definition of Attributes

Like object classes, attribute types also can be defined formally. Exhibit 10 gives the complete definition as found in RFC 2252. The syntax used in this RFC is Backus Naur form (BNF), used for the formal description of syntaxes. What we need to know is that values included in square brackets, like [ "SUP" woid ], are optional; values between quotation marks are to be typed literally, for example the keyword "SUP" or the parenthesis "(" after the assignment operator. The quote-enclosed slash "/" means "or" and indicates alternative possibilities.

 AttributeTypeDescription="(" whsp  numericoid whsp                 ; AttributeType identifier  [ "NAME" qdescrs ]              ; name used in AttributeType  [ "DESC" qdstring ]             ; description  [ "OBSOLETE" whsp ]  [ "SUP" woid ]                  ; derived from this other                                  ; AttributeType  [ "EQUALITY" woid ]             ; Matching Rule name  [ "ORDERING" woid ]             ; Matching Rule name  [ "SUBSTR" woid ]               ; Matching Rule name  [ "SYNTAX" whsp noidlen whsp ]  ; see section 4.3  [ "SINGLE-VALUE" whsp ]         ; default multi-valued  [ "COLLECTIVE" whsp ]           ; default not collective  [ "NO-USER-MODIFICATION" whsp ] ; default user modifiable  [ "USAGE" whsp AttributeUsage ] ; default userApplications  whsp ")" 

Exhibit 10: Attribute-Type Description from RFC 2252

The attribute-type description is nearly self-explanatory, but we will take a closer look at it to resolve any potential doubts. Like the object-class description, the attribute-type description comprises the numeric object identification (OID) of this attribute type. You can learn more about the OID in the section on object classes presented earlier in this chapter. The rest of the data is optional, as indicated by the square brackets. The data is in the form of (1) a keyword in capitals enclosed within quotation marks and (2) an optional value. The allowed keywords are as follows:

• "NAME" is simply the name of the object.

• "DESC" is a human-readable description of the attribute.

• "OBSOLETE" does not need a value. It indicates that this object should not be used anymore and exists only for compatibility with older implementations.

• "SUP" contains the OID of the attribute from which this attribute is derived. The term "woid" indicates an OID surrounded by two white spaces. Remember that an OID can be the numericoid or a human-readable description.

• "EQUALITY" defines a matching rule to test equality. A later section in this chapter provides more information about matching rules.

• "ORDERING" defines a matching rule for ordering purposes, i.e., fewer or more operators. Matching rules are discussed later in this chapter.

• "SUBSTR" specifies that a query evaluates as true only if it matches a given substring. The matching requirements follow as a parameter. Matching rules are discussed later in this chapter.

• "SYNTAX" explains what type of data you can put into this attribute. The "noidlen" term specifies the maximum length of the attribute. Syntax is discussed later in this chapter.

• "SINGLE-VALUE" is a flag indicating that this attribute can have only a single value.

• "COLLECTIVE" is a flag indicating that this is a collective attribute. Collective attributes are inherited from X.500 and are stored not directly in this entry, but in a special entry called "subentry." An example of a collective attribute could be a fax number common to an entire group of entries.

• "NO-USER-MODIFICATION" is a flag indicating that the user cannot modify the entry.

• "USAGE" defines the use of this attribute. Exhibit 11 lists the possible uses. ^[1] This is discussed at greater length in the following "Attribute Types" section.

   AttributeUsage=  "userApplications"     /  "directoryOperation"   /  "distributedOperation" / ; DSA-shared  "dSAOperation"           ; DSA-specific, value depends on server 

  
  Exhibit 11: Attribute Usage from RFC 2252

Attribute Types

There are two substantially different types of attributes: user attributes and operational attributes.

1. User attributes are modifiable by the user if the server is configured to allows this action.

2. Operational attributes apply to the server and are not modifiable by the user. We will see later that there are three different types of operational attributes.

Examples of operational attributes are the attribute "modifyTimeStamp," indicating the time the entry was last modified, or the attribute "modifierName," which identifies the user who modified the entry. Examples of user attributes are "cn" for Common Name (full name of a person) and "sn" for Surname.

The attribute type is defined within the "usage" parameter. Per default, the attribute type is set to "User Attribute," as expressed by the line

 "USAGE" userApplications 

inside the attribute-type description. You will seldom see this statement, even though it is the default value.

As seen in Exhibit 11, there are four possible values for the usage parameter: one for user attribute and three operational attributes:

• userApplications: A user attribute

• directoryOperations: An operational attribute relative to directory entries

• distributedOperations: An operational attribute relative to other directories

• dsAOperations: An operational attribute relative to the DSA

The "normal" or default attributes are of the type "userApplications." Two examples are:

• cn: Common name or full name of a person

• sn: Surname of a person

The operational attribute "directoryOperations" is the first of the three operational-attribute types to be used to maintain a kind of metadata. Examples include:

• modifyTimeStamp

• modifiersName

Exhibit 12 shows examples of the operational attributes "distributedOperations" and "dsaOperations."

distributedOperations: These attributes are used to maintain information of data distribution among several servers. Examples are:

• ref: also known as "named referral," is an attribute of the object class "referral" that is used to point the server to an entry that contains the requested information

• sharedRef: general information that can be shared among several servers in the global LDAP naming domain

dsaOperations: These attributes contain DSA (directory service agent) information about the directory. DSA is a simple synonym for the process or processes used to maintain the directory. Examples are:

• supportedLDAPVersion: gives information about the LDAP versions supported by this server, only available in LDAP (v3).

• namingContexts: identifies partitions of the directory held in a server, only available in LDAP (v3).

• createTimeStamp: time the entry was added

• modifyTimeStamp: time the entry was modified

• creatorsName: dn of user who added the entry

• modifiersName: dn of user who modified the entry

• subschemaSubentry: dn of subschema entry for this entry. For a complete description, see RFC 2252, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions."

• dITStructureRules

• dITContentRules

• matchingRules

• attributeTypes

• objectClasses

• nameForms

• matchingRuleUse

Exhibit 12: Examples of Most Frequently Used Attributes of Type "distributedOperations" and "dsaOperations"

Matching Rules

The entries in a directory can have a large numer of attributes. These attributes can be written in different forms.

There are attributes where lowercase or uppercase letters do not matter. Examples are the Distinguished Name, the description, the street, etc. There are also particular attributes, such as telephone number, that you can write in completely different ways; for example [phone] can also be written as [phone] 903.

In case of queries, you need to make comparisons in order to find from all entries the one you are interested in. Comparisons are not only necessary in query operations, but also in "delete," "update," and "add" operations.

You should also tell your directory server how to make comparisons between atribute values. You do this in the form of so-called "matching rules."

As an example, look at the telephone number attribute mentioned above. The two versions of the same telephone number should be considered equal by the server and therefore the matching rule should specify the following:

• ignore extra white spaces

• ignore hyphens ("-")

• ignore opening and closing parenthesis

The matching rules are defined by standard and everyone has a name and an OID. The rule describing the matching of telephone nubmers for example is called "telephoneNumberMatch" and has the OID 2.5.13.20.

As defined in RFC 2252, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions," you can define three different matching behaviors:

• "EQUALITY" defines the matching rule for equality filters.

• "ORDERING" describes actions such as "less than" or "greater than" on attributes.

• "SUBSTRING" defines the matching rules that decide when the matching of the substring is sufficient.

Matching rules are defined in RFC 2252, and every matching rule has its own OID, as do object classes and attribute types. The method of obtaining a new OID for a matching rule is exactly the same as for every type of object, such as object classes or attribute types, and is described in the previous section about OIDs. Exhibit 13 shows the most frequently used matching rules. With their OIDs and the syntax of the attributes, the matching rule works on. The syntax is listed in the form of its OID. More about syntaxes in the following section. For a complete description of matching rules and the complete list of OIDs, refer to RFC 2252. The names of the matching rules are self-descriptive.

OID	Name	Syntax
2.5.13.1	distinguishedNameMatch	1.3.6.1.4.1.1466.115.12 1.1.12
2.5.13.2	caseIgnoreMatch	1.3.6.1.4.1.1466.115.12 1.1.15
2.5.13.8	numericStringMatch	1.3.6.1.4.1.1466.115.12 1.1.36
2.5.13.11	caseIgnoreListMatch	1.3.6.1.4.1.1466.115.12 1.1.41
2.5.13.14	integerMatch	1.3.6.1.4.1.1466.115.12 1.1.27
2.5.13.16	bitStringMatch	1.3.6.1.4.1.1466.115.12 1.1.6
2.5.13.20	telephoneNumberMatch	1.3.6.1.4.1.1466.115.12 1.1.50
2.5.13.22	presentationAddressMatch	1.3.6.1.4.1.1466.115.12 1.1.43
2.5.13.23	uniqueMemberMatch	1.3.6.1.4.1.1466.115.12 1.1.34
2.5.13.24	protocolInformationMatch	1.3.6.1.4.1.1466.115.12 1.1.42
2.5.13.27	generalizedTimeMatch	1.3.6.1.4.1.1466.115.12 1.1.24
1.3.6.1.4.1.1466.109. 114.1	caseExactIA5Match	1.3.6.1.4.1.1466.115.12 1.1.26
1.3.6.1.4.1.1466.109. 114.2	caseIgnoreIA5Match	1.3.6.1.4.1.1466.115.12 1.1.26
2.5.13.28	generalizedTimeOrdering Match	1.3.6.1.4.1.1466.115.12 1.1.24
2.5.13.3	caseIgnoreOrderingMatch	1.3.6.1.4.1.1466.115.12 1.1.15

Exhibit 13: Examples of Most Frequently Used Attributes Matching Rules

In theory, you could define your own matching rules, but this option is interesting only if you are writing your own implementation of a directory server, since you have to develop the code executing the matching algorithms.

Syntaxes

The last point we have to address are the syntaxes, which are simply a formal description of what values an entry can hold. Like the matching rules, which were covered in the previous section, syntaxes can be extended to fit your particular needs. This means that you can define your own syntaxes. However, this also means that you have to rewrite pieces of the code of your directory server to define the new syntaxes. This topic is interesting, but it is beyond the scope of this book. You can learn more about this subject on the Web site of the open-source project OpenLDAP and the connected discussion groups at http://www.openldap.org.

Syntaxes are defined in RFC 2252. The concept is inherited from the original X.500 protocol. We have just seen that matching rules, object classes, and attribute types are identified by a unique OID. The same holds true for syntaxes. You will find many shorthand names for the syntax in various LDAP implementations and in the literature. Exhibit 14 shows the most frequently used syntaxes with their shorthand names and OIDs.

OID	Shorthand	Description
1.3.6.1.4.1.1466.115.121.1.5	bin	binary value
1.3.6.1.4.1.1466.115.121.1.12	dn	distinguished name
1.3.6.1.4.1.1466.115.121.1.15	cis	case insensitive string
1.3.6.1.4.1.1466.115.121.1.26	ces	case sensitive string
1.3.6.1.4.1.1466.115.121.1.27	int	integer
1.3.6.1.4.1.1466.115.121.1.50	tel	telephone number

Exhibit 14: The Most Frequently Used Syntaxes with Their Shorthand Names

Exhibit 15 shows some of the syntax definitions as defined in RFC 2252. It shows the same syntaxes as Exhibit 14. In the first column, you see the syntax name; in the second, you see if the information of the corresponding attribute is "Human Readable"; and in the last column, you see its unique OID. Note that not all vendors of LDAP implementations or authors of LDAP documentation divide the concepts of syntax and matching rule as we did here. When we discuss syntax, we mean a description of the values the attributes can hold (syntax) plus a description of how comparisons have to be executed (matching rule).

Value Being Represented	Human Readable	Syntax
ACI item	Y	1.3.6.1.4.1.1466.115.121.1.1
Access point	Y	1.3.6.1.4.1.1466.115.121.1.2
Attribute type description	Y	1.3.6.1.4.1.1466.115.121.1.3
Audio	N	1.3.6.1.4.1.1466.115.121.1.4
Binary	N	1.3.6.1.4.1.1466.115.121.1.5
Bit string	Y	1.3.6.1.4.1.1466.115.121.1.6
Boolean	Y	1.3.6.1.4.1.1466.115.121.1.7
Certificate	N	1.3.6.1.4.1.1466.115.121.1.8
Certificate list	N	1.3.6.1.4.1.1466.115.121.1.9
Certificate pair	N	1.3.6.1.4.1.1466.115.121.1.10
Country string	Y	1.3.6.1.4.1.1466.115.121.1.11
DN	Y	1.3.6.1.4.1.1466.115.121.1.12

Exhibit 15: Example of Syntaxes from RFC 2252

Conclusion for Information Model

The information model is a cornerstone of the Lightweight Directory Access Protocol, much of it inherited from its predecessor, X.500. In contrast to X.500, LDAP tends to use short mnemonic names for object classes and attribute types.

The directory holds a great number of entries, and each entry consists of attributes. In turn, each attribute has an attribute type and an attribute value. Both object classes and attribute types are identified uniquely by a string of integers and dots called an "object identifier" (OID). The attribute types are defined by (1) a syntax describing the values that the attribute can hold and (2) the matching rules governing how comparisons in operations are made. Every directory server holds a schema containing all relevant object classes and attribute types.

A warning regarding the notations used for object classes and attribute types: In this chapter we used the same notation used in the RFCs. An LDAP implementation can use other notations. We will learn more about them in Chapter 4, where we will also speak about the naming model, which explains how to assemble the various entries into a directory information tree.

^[1]The DSA in Exhibit 11 means ''directory server agent." It is a synonym for the directory server process, another word inherited from the X.500 standard.

---