LDAP Models (Con't) - Page 5

Let's take a look at one of the entries in particular:

dn: mail=jc@myorg.com, o=myorg, c=us
cn: James Close
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
l: San Franscisco
mail: jc@myorg.com
telephonenumber: 789 456 7890
telephonenumber: 111 000 2222
Description: Dot com dude

Tracing the entry from the top of the tree representation, we see that the DN of the entry is mail=jc@myorg.com, o=myorg, c=us.

The cn label corresponds to the common name attribute, the mail label corresponds to the e-mail address, telephonenumber indicates the telephone number, l indicates the location, and Description corresponds to a textual description of the person. Of course the objectclass labels indicate the class hierarchy from which this entry has been derived.

Note the second telephonenumber entry that has been added above; this could be the home telephone number of the person. It serves to illustrate the fact that an attribute could occur more than once and therefore have multiple values.

We can use cn as the RDN for this entry. Then its DN would become cn=James Close, o=myorg, c=us. We chose the e-mail address since the chances of it being unique are much more than a regular name.

Naming Model

The LDAP naming model specifies how the directory data is organized. The analogy to this organization is the UNIX directory structure resembles an inverted tree. In the LDAP data organization there is a root entry that has other entries below it that in turn might contain sub-entries. However, in the LDAP hierarchy the root entry is merely conceptual and we cannot place data into it as opposed to the UNIX directory structure, where there can be files in the root directory. Also, the LDAP entries are read backwards with respect to file system objects, such as, a UNIX file could be referred to as /home/foo/myfile, whereas in the LDAP model, this could be cn=myfile, dc=foo, dc=home.

So, why do we need a naming model? We need one because we need some way to uniquely address an entry. Let's look at the entry for James Close once again. The DN for this entry would be mail=jc@myorg.com, o=FooWid, c=US.

Tracing backwards, we see that this is sufficient to uniquely address this entry. Also note that the spaces after the commas are entirely optional.

We saw that mail=jc@myorg.com is an RDN, this means that there cannot be another entry under o=FooWid, c=US with the value jc@myorg.com for the mail attribute, if not the uniqueness is lost. Note that by default, while the names of the attributes are case- sensitive, the values are not; in this case cn is case-sensitive while James Close is not.

Functional Model

This model defines the operations that can be performed on the data stored in the directory. It also dictates which clients the users can access and which parts of the directory they can change. There are nine basic operations that can be divided into three of the following categories:

• Query operations
• Update operations
• Authentication and control operations

Query Operations

These are essentially search and compare operations which allow us to search the directory and compare two or more entries and their attributes. We can use search filters to perform the search and compare operations. Further there are Boolean operators that can be used to combine search filters.

LDAP clients need to access data residing on the directory using criteria that are specified at search time. For example, consider a directory that stores e-mail addresses; we have an e-mail client that is LDAP?enabled. The e-mail client connects to the LDAP server using LDAP (thus acting as an LDAP client) and allows us to search for the e-mail addresses of those you wish to send mail to. To perform this search, the client would need to specify a search criterion (a search-filter). The search-filter is a regular expression with the names of attributes and operators that might match the entries with the appropriate attributes.

For example, in the FooWid organizational chart, a search filter of the form:

(cn=*) will match all entries with a cn attribute.

LDAP Models - Page 4
Professional PHP4 Programming
Update Operations - Page 6