65 articles and counting

LDAP Object Oriented Programmers

As I’m learning OpenLDAP, it seems useful to draw on programming language concepts to understand the system.

Data from (and the schema behind) a LDAP directory is object oriented and seems to have less of an impedance mismatch between code and data, than the more popular RDBMS.


Schema definition appears to be highly inspired by object oriented inheritance, a popular programming paradigm. Every record has a structural objectclass. Classes come in three flavors:

  • Abstract
  • Structural
  • Auxiliary

These notions are quite familiar to OO programers. Structural classes are the work horses of Schema definition and are basically what most languages prove as a class. Abstract are like abstract base classes in Java. Auxiliary are like interfaces in Java or mixins in Ruby.

Let’s look at an example Schema – an objectclass for countries

objectclass ( NAME 'country'
        DESC 'RFC2256: a country'
        SUP top STRUCTURAL
        MUST c
        MAY ( searchGuide $ description ) )

A record cannot be created for an abstract objectclass. All records must have one or more structural classes. The root of the LDAP Schema inheritance hierarchy comes from top which has one mandatory attribute objectclass.

An objectclass can use the SUP keyword to inherit from another objectclass. The default value for SUP is top. Objectclasses declare what attributes MUST and MAY appear in a record. A record can’t have arbitrary elements, the field must have been declared in the schema.

Multiple Inheritance diagram.

It is illegal to do multiple inheritance where a record has two
structural object classes that diverge, such as D and E in the diagram

A record can have multiple objectclasses, so a record that declares A, B, and D is fine.

Records may freely mix in auxiliary objectclasses to pick up new well understood properties on existing structural classes. So this is a multiple inheritance like pattern.

To figure out which is the most concrete class, the system looks for the structural objectclass furthest from top.

In addition to objectclasses being hierarchical, the attributes on an objectclass are also hierarchical. The mechanism is also the SUP keyword.

Again like objectclass, if no parent for an attributetype is defined, it is top by default. You may always add top to be explicit.

Let’s see an example of attributetype schema:

attributetype ( NAME 'name'
       EQUALITY caseIgnoreMatch
       SUBSTR caseIgnoreSubstringsMatch
       SYNTAX{32768} )

Ignore, it is the object id (OID) for a utf-8 string. We’ll cover OID in the next (MySQL oriented) blog post.

The SYNTAX of an attribute specifies what kind of data can be stored in the field. UTF-8 strings, phone numbers, JPEG binary blobs, etc. These values can also be given a max length via {n} syntax.

Continuing looking at how to model countries, let’s look at the definition of ‘c’ that the earlier objectclass declared as a MUST have attribute.

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

Pretty straightforward. We inherit from ‘name’. Notice the SINGLE-VALUE keyword. An attribute can be a list of values, unless you constrain it to a single value. This seems like a pretty elegant solution when modeling data.

Looking at all the attributetypes and objectclasses is a bit like looking at a Django project’s models.py.

So these schemas capture the static aspects of a directory.

At runtime, the records in the system also exhibit Object Oriented behavior.


Several declarations of an attribute control how search works. Equality and substring matching are controlled declaratively.

As noted this is kind of bizarre, but a LDAP Directory provides search, so there you go. If your blogTitle should be searchable just like a person’s Given name, then you can look through the schema and make it inherit from name or use the same values for the matchingRules property.

These Attributes settings can be inherited and many attributes in the base schemas inherit from name.

A directory’s layout is hierarchical, but doesn’t have to follow the same structure as the objectclass structure. Records are grouped under grouping objectclasses. Data is organized with regard to data access patterns and how ACL will be written.

You can think of an LDAP directory as a web service that returns LDIF instead of JSON. Your code runs in the application or middleware layer, which you have full control over. The LDAP protocol provides a sophisticated protocol for reading, writing, and searching objects.

Here is some example LDIF for which captures a country:

dn: c=United States,dc=example,dc=com
c: United States
description: The marshmallow filling between Mexico and Canada.

The dn is the only funky bit here, otherwise this looks like an easy format, perhaps a cousin of JSON.

As noted, a record may have multiple object classes and can be much richer than this small snippet.


Hey OOAD fans, directories are inherently OO! An object class is part of every record. This schema information says what can, must, and can’t be in a record’s attributes. Also… a record can have multiple object classes… Hello mixins! A record must have one super class which is called the structural object class, because that sounds tough.

Hopefully this gives us another perspective for starting to understand LDAP directories.

2 Responses to “LDAP Object Oriented Programmers”

Robert Kaiser - 14/06/11
Erm, wasn't c to be a "ISO-3166 country 2-letter code"? In that case, it must be "US" in your example ;-)
ozten - 14/06/11
LOL. Ya I guess there is a more modern field for country. Sorry about that.