Why LDAP isn’t more widely adopted… or WTF?!?

Here are some perceived problems and recommendations. My recommendations are coming from a total newbie, so they are fairly worthless.

This post is about barriers to adoption and will be the most negative of this series. I will be dropping some fbombs.

Let’s start with some nice things… we’ll get to the constructive feedback soon enough

LDAP is a protocol, not an API. This is actually really cool and very in-fashion.

LDAP directories are distributed (in more than one way), sweet.

Another cool thing about LDAP is that records can have some flexibility to their schema, but they still have a schema. You can augment a record with an “auxiliary” type. Types can have mandatory and optional elements. Ad-hoc elements aren’t allowed, they must be in a schema. This seems like a sweet spot for some classes of data storage solutions.

For such an ancient and storied beast, OpenLDAP gets many things right. If you were to re-launch it as a new NoSQL project, written in NodeJS, you’d probably get some love. Developer’s love the new hawtness.

Problem: Bizarre keywords

Technically these aren’t keywords, but to a programmer just encountering LDAP, that is what they seem like.

Attributes are standardized and have inconsistent and wacky names. As a programmer, I’m used to creating my universe on top of a standard library. A programmer approaching data and data definitions… I make that up as I go, right?

dn

What the fuck is a dn. Oh it’s a distinguished name. Well… how … distinguished.

A DN is like an ID or a KEY. People know those terms. It’s okay if it isn’t technically accurate. Humans remember a good story over a technically accurate story.

dn = distinguishedName… Okay, so everything is supper abbreviated, I can dig it… Let’s see O=Acme Services, telephoneNumber=+1 800 555 9834, postalAddress= 98177, l=Seattle…

What, what? Inconsistent much? So it appears that objectclasses and attributetypes can have multiple aliases.

o is an alias for OrganizationName and l for localityName.

Tweet you’ll never see:

OH: Hey @Jill, I forgot, which localityName do you live in again? #onthebus

This causes my WTF/minute to spike. I imagine one of the following created these names:

• Regional oddity
• Authors crashed on earth in space pod
• The authors took a break from speaking Esperanto long enough to form a quorum and vote in the schema
• Maybe that schema was baked in a BOF at DirectoryCon in Atlantis 1872

Who knows… once you grok the names and the semantics, it’s all good.

Mixed Case

Why do I see o and O used for attributetype names? Because it’s case-insensitive. Like Windows 3.1.
o_O

Recommendation:

Objectclasses and AttributeTypes may have multiple names. Always use the
most descriptive name or invent aliases that aren’t totally fucked. Don’t use more than one alias. I know naming things is hard.

Problem: Discoverability

It’s very hard to ‘view source’ on an existing app and understand WTF is a dn… These things are buried deep in the system in .schema or .ldif files. When you read them, they read like a Dewey Decimal’s Bureaucratic Vision of the New World Order.

Recommendation:

I haven’t found a really good document or manual of the existing standardized schemas. One that makes it easy to see data types, reasons they exist, etc. I have to resort to greping the schema files or browsing via Apache Directory Studio.

Problem: LDAP Directories do too much

I can sympathize with the successive generations of decisions that went into creating LDAPv3.
In system design there are lots of hard decisions around when to separate policy (application level minutia) from application (or service). What do you

• Bake in?
• Make Controllable programatically?
• Make Configurable?

LDAP makes very different design decisions (than say a SQL92 DB) in terms of what is provided via the LDAP protocol vs what is Application level or what should be provided by other tools.

An Example is Search.

LDAP schemas encode what is a valid search strategy, instead of delegating this
to a search layer outside of the LDAP Schema (or at outside of LDAP entirely)…

Oh my. Wanna swap out Sphinx for elasticsearch? It’s not that type of party.

So your schema will encode that you can search with ‘o*’ against country fields and get back a boat-load of countries. You might expect to handle this at the application layer. So if you don’t want to allow wild card characters, or you want to make sure that search results are conservative, you’ll need to remove ‘*’ from search input or post-process the search results.

Recommendation:

We haven’t talked about ACL. This explains why search is tightly coupled.

I punt. Software is hard.

Problem: The CRM/CMS/Groupware problem

I think it’s incredibly heard to create large, general, reusable applications. Look at Sharepoint, Plone, Netscape Suite, etc.

Really good software is small and tailored exactly to the organization or social function it serves. Building really good general purpose software is usually impossible. Hats off to (any) level of success here.

Recommendation:

I punt. Software is hard.

Problem: Schemas and Data

Snippet of LDIF (serialized data):

dn: uid=john,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: john
sn: Doe
givenName: John
cn: John Doe
displayName: John Doe
uidNumber: 1000
gidNumber: 10000
gecos: John Doe

Wow. Really?

The idea that LDAP v3 specifies schema is odd and surprising. Maybe the protocol doesn’t (I haven’t read the RFCs), but it’s deeply ingrained in the culture that you use at least the 4 most popular schemas out of the box.

There is an amazing amount of redundant information. Looking at ldif files, they violate the DRY principal. Tooling can fix the DRY issue.

But an inetOrgPerson out of the box? It’s a bit akin to a programming language providing a Person class in it’s standard library. How’s that working out for you?

No respectable RDBMS comes with a predefined schema. I’d giggle if MySQL offered inetOrgPerson tables with organizationalName or localityName columns. Again this is the “too many layers to understand at once” problem.

Related Problem:

If I start whipping up my own schema… I quickly run into the crazy constraints that every schema on the planet is in the same namespace. W… T…F… My slapd server can host multiple directories, but it can’t have attribute name clashes between my different projects. What the What? (We’ll cover OID in another post).

LDAP and x.500 were designed many moons ago. This is an inferior strategy for distributed system design.

Recommendation:

Schema should be namespaced and more cleanly separated from the daemon that provides LDAP Directory services. I doubt a LDAPv4 could add this w/o breaking backwards compatibility. Java’s package namespacing conventions have done good work here.

Problem: Unexcepted data and programming models

The great thing about learning new systems or languages is that it stretches your mind. Having casual contact with LDAP, there is a lot of unexpected idioms.

• Search check to see if something exists, doesn’t always return a value
• Advanced and nuanced binding is baked in, uses unusual terminology
• Type systems are hierarchical, data is hierarchical, the two don’t have to be related

The way data is modeled and organized is very different than RDBMS.

To this last point, exploring the data sets in LDAP directories can be a much more natural experience than wading through tables in a RDBMS.

LDAP Directories are fairly sophisticated. This means quite a bit of training is required before someone feels comfortable using or tweaking things. Ruby has a concept of POLA. For whatever reason, LDAP has a lot of surprises.

There are several great books and free materials out there on OpenLDAP, so I don’t think this is a deal-breaker, it just reduces casual adoption.

So there are some initial thoughts from a web developer trying to understand LDAP. LDAP systems are widely deployed in IT Departments, but never a first tool to reach for in the startup and Internet programming worlds.

These assumption and confusions hopefully show some of the disconnects for potential adoption by new users. Seeing code that uses LDAP or seeing snippets of schemas or ldif files can make a programmer feel uneasy. It seems like foreign territory.

Having read (the two resources above) and implemented a toy project (a recipe directory), OpenLDAP doesn’t seem that crazy or foreign. It’s got a few warts and scars like any real world, successful technology.

Instead of just jovial complaining, my next two posts will help MySQL oriented users as well as OO programming oriented users get started with OpenLDAP concepts and tools.