What Else Is There Besides OpenLDAP?

The Stunted Leech asks: "I am trying to develop an LDAP interface to an existing customer database and would like to implement a simple LDAP listener that could be queried from e-mail clients. Before everyone suggests importing the data to OpenLDAP or developing a back-end for it, let me just say that it isn't very feasible: I'm the only person assigned to the project, and my company doesn't have the time or hardware resources to maintain an LDAP server. So I'm looking for very simple implementations of LDAP servers, preferably in a scripting language like Perl or Python (we use Perl for CGIs and wxPython for GUI front-ends). I've come across a couple of Java-based ones, but they seemed overly complex - all I need to do is retrieve a contact's e-mail or phone number from our database. Pointers to any sort of simple LDAP servers are welcome, even if they do little more than return the same result to all queries."

Comments

LDAP CONSIDERED HARMFUL

[Slipped_Disk]

Well, some applications of it (LDAP for user management) anyway, but that's a subject for a different rant.

To address your question -- you are in a situation similar to me: You need to implement LDAP access to some data you already have stored somewhere else (presumably in a format "better" than an LDAP directory).

Your best bet would be to implement an OpenLDAP or iPlanet/Netscape/Sun directory server, seed it with the data you already have(a conversion script could probably be written easily), and "educate" the software you use to maintain your current database so that it updates LDAP as well as the current system (using the Net::LDAP module for Perl, or something similarly generic that would work with any LDAP server).

However, since this is not what you want (you don't have the "time or hardware resources" to maintain an LDAP server), you are unfortunately stuck with plan B: Write a listener on port 389 that understands LDAP queries, goes into your current database, grabs the data and spits it out in an LDAP-Like way.

Were I you, I would re-evaluate the cost and difficulty of running an LDAP server and maintaining the synchronization (or migrating the data to LDAP entirely, if it lends itself well to the directory/tree structure of LDAP). Plan B generally pretty much SUCKS, and will inevitably require more time/effort/money to implement and maintain.

Nonetheless, the Net::LDAP library for Perl would be a good place to start with this task. You could also look at the OpenLDAP software as a reference implementation (the code is a fairly easy read (to me anyway) and should be helpful in designing your serverlike hybrid.

You may also wish to look into commercial "metadirectory" products which take one central authoritative datasource and multiplex it out in a variety of formats. When I last looked at these they all sucked, but the "best of breed" back then was something called "DC Directory Server". If you could find one that suits your needs it may be the way to go.

I know this wasn't very helpful, the truth is (as I have been discovering myself) anything LDAP is still kinda raw, and anything complex like what you are trying to do is really not well-explored (or at least not well-documented). Maybe some other slashdotters can be more insightful than me though :-D

Good luck

Re:LDAP CONSIDERED HARMFUL

[Slipped_Disk]

My concern WRT "Plan B" is that you now have a second point of entry into the existing database which must be kept up-to-date with internal structure changes and the like (we no longer store "fullname" on the person table, you now get it by concatenating "firstname" and "lastname", etc.).

This basically adds to the maintainer's job, whereas "Plan A" (modifying the existing UI to update LDAP) consolidates all the DB Updating bits into one program (and presumably the LDAP server is configured only to allow that program to make updates, by host or binding-user restrictions).

As far as initial coding effort, 200 lines of code could easily implement the LDAP command parsing (in perl or C, and assuming a limited subset of the available commands), however you must take in to account the code to translate from internal storage schema (presumably some RDBMS, or (*gag*) flatfiles) to output that an LDAP client can parse without vomiting on itself. This is where I see the expense and work coming in.

I also have a visceral dislike for reinventing the wheel, since such reimplementations often result in rather defective wheels - How long has it taken OpenLDAP to get to the state it is in now? And anyone who uses it knows it still has bugs and issues...

Ldaptor is a Python lib and a collection of apps

[Tv]

Ldaptor is a pure-python LDAP library and a collection of utilities and apps such as a web interface.

There's not much of the server side implemented yet -- only a dummy server that answers all search requests with "nothing found", but the protocol decoding etc. is all there.