LDAP and OpenLDAP (Part II)

If you just only want to know how to use a directory server, you may not to know the models of LDAP. But there do exist four models of LDAP. They're information model, name model, function model and security model, and they help us to learn what makes a LDAP server and how LDAP works.

Information model
The basic unit of information is the entry. We have seen 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.

The excerpt of the directory can be broken down into small data structures which are called "entry" or "object". "Organization" and "organization unit" etc. are all objects.

Note the example listed in last article that each entry have several lines, each line corresponding to one attribute. In other words, entry is a collection of attributes, with each attribute having one or more values.

LDAP has rules to specify how information is to be saved. The collection of these rules is called schema which are kept in the configuration files. In version 3 of LDAP, client can explore the schema that the server is using. The schema in LDAP software are likely but having some important difference comparing with those in RDBMS:

1. LDAP software are shipped with a number of schemas. The user selects schema and begins filling in data. While in RDBMS, the first user has to define the schema.

2. The LDAP schema is simpler and does not know anything about complicate structure such as "join", nor are there any triggers.

The schema contains:
1. object-class definitions describing the different types of entries in the directory.
2. Attribute-type definitions describing the different attributes of the objects.
3. Syntax definitions to describe how the attribute values are to be compared during queries

If you write an application using a object-oriented language such as C++ or Java, the first thing you do is define classes. Then you can define objects to implement the previously defined classes. The same will happen in using LDAP. Every directory is configured to recognize a number of classes called "object class". The objects in the directory are implementations of these classes. Following is the example of object class definition stored in schema files:

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
)
)
)

In this example class top and organization are defined. Class organization are inherited from class top using "SUP top". The inheritance is similar to that in object-oriented languages.

The "MUST" section in this definition contains those attribute which must have some value while defining objects. The value of he attributes in "MAY" section is optional while defining objects. What type of value of these attribute should have is defined in BNF(Backus Naur form), i.e., the attribute such as "userPassword" or "searchGuide" is predefined in the schema file and the valid value type of them is also defined. For example the attribute "c"(stand for country) is predefined in core.schema file as:

attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )
DESC 'RFC2256: ISO-3166 country 2-letter code'
SUP name SINGLE-VALUE )

The object class "top" is one of the most simplest object class. And all other classes derived from the class "top". The only purpose for class "top" is to ensure that every object contains the "objectClass" attribute, since it is the only required attribute in the class "top". It exists only to be inherited, as indicated as "ABSTRACT". An object is not intended to be instantiated is called "abstract object class". That means you'll never find an entry for class "top" in the directory.

objectclass ( 2.5.6.6 NAME 'person'
DESC 'RFC2256: a person'
SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

Example listed above is the definition of class "person". 2.5.6.6 is the object id(oid) of the class. It inherit attribute "objectClass" from class "top". Object for this class should have the values of attibute "sn" and "cn". Other attribute of the object for class "person" is optional.

As mentioned previously, there are three types of object classes:
1. Abstract
2. Structure
3. Auxiliary

Abstract class is the class of class. Structure class can be implemented as object to be stored in directory.

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.

The concept of OID is another important concept imported into LDAP from the X.500 standard. Object identifiers (OIDs) are not only used for object classes, but also for attribute types. The OID standard is not limited only to object classes and attribute types. It can be used to identify uniquely any type of object.

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". 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.

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.

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:
1. ignore extra white spaces
2. ignore hyphens ("-")
3. 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