Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Duck typing in directory access (20070722)
One of the assumptions in X.500 carried into LDAPv3 that has hindered its success is that for a particular branch of the directory information tree, the directory servers that store that branch, schema used by entries in that branch, and the applications that create and update entries in that directory branch, are all under a single administrative control.
As a result, while through subschema LDAP servers can publish their schema and DIT constraints (supported object classes and attributes, name forms, DIT structure rules, etc.), typically don't maintain and advertise a separation between schema and DIT constraints which are:
- design artifacts of the directory server implementation (e.g., that a server might only allow objects representing users to be represented as leaf entries below a domain entry),
- design choices of the DIT administrator for how to represent objects as entries (e.g., that uid is the naming attribute),
- schema elements of directory-enabled applications that are intended to be shared between applications, and
- schema elements of directory-enabled applications that are intended to be private to the application (e.g., Netegrity defined attributes for representing Siteminder state which is opaque to any other application).
This is problematic as configuring "yet another" directory enabled application to leverage a particular organization's deployed directory service is a far more difficult process than it should be.
- Some commercial products that are "directory-enabled applications" require a so-called green-fields deployment: one in which the directory tree has not yet been populated or used by any applications, and fail to work correctly when the directory service is already an operational service. Other directory-enabled applications require arbitrary changes to existing directory information trees and schemas, which might break other applications.
- Even if the application does not modify the schema, directory tree structure, or entries, the application must be customized to be able to find objects of interest to their application, and understand how the directory server, the DIT administrator, and other applications are modelling those objects in the directory.
Some of the issues can be discussed in the context of "duck typing". Duck typing in programming languages is the concept that an object can be interchangeable with any other object so long as they both implement sufficiently compatible interfaces, regardless of whether the objects have a related inheritance hierarchy
(from the Wikipedia page on Duck typing). In C++ for example, templates can be used for one form of duck typing in programs written in that language.
In LDAP directory applications, duck typing can be thought of as a limited form of schema independence. A duck typed LDAP application doesn't assume there is a particular structure rule or object class in use in a particular directory: so long as the attributes match, the application will work. For example,
| Not duck typed | Duck typed | |
|---|---|---|
| The Read operation | Subtree searching | |
| ou=People branch | Searching from the base of the naming context | |
| families of entries | ||
| Not duck typed | Duck typed | |
|---|---|---|
| Searching for (&(objectClass=person)...) | Only having auxiliary classes (if at all) in search filters | |
| Application-specific object classes (e.g., fooPerson) | extensibleObject | |
| Not duck typed | Duck typed | |
|---|---|---|
| OIDs in search filters or in requested attribute lists | Using string names for attribute types | |
| Application specific attribute types | ||
Duck typing, however, is not a cure for directory interoperability problems. In paricular, duck typing can be dangerous as two attributes with the same name may not be semantically equivalent. Is passwordExpiry a date, a number of seconds, or a boolean?. Checking against the object identifier (OID) of the attribute in the directory server's schema before using it has a greater chance of ensuring the attribute type is the same as that assumed by the application, although some vendors arbitrarily change the OIDs of standard schema elements (e.g., inetOrgPerson).