LDAP Authentication

For the ArsDigita Community System, by Lars Pind on April 13, 2000.

Not part of the ACS release yet; will be included in 4.0 release.

The Big Picure

Many companies have their own LDAP directory servers where they centrally store information on all the users of their computing equipment, including their user ids and passwords. We want to let users of an ACS-based web site log in using the same user id and password as everywhere else in their computing environment.

If you want to know more about what LDAP is, I've actually written up something about it.

The user/publisher perspective

An ACS installation is hooked up against one specific, trusted LDAP server. Every user of ACS has to be known to this LDAP server. Instead of the usual email and verifying passwords against our users table in Oracle, we login (bind) to the LDAP server.

The first time we see a particular user id, we query the LDAP server for email, name and other information and create a row in the users table with this information, including the LDAP user id. When this is done the first time, we needn't do it again. We know who it is just by the LDAP user id and authenticate it using the LDAP bind function.

Under The Hood

To access the LDAP server, we use the standard Java2 distribution, which happens to include an LDAP client library. We run the Java inside Oracle. Note that we only support LDAP v3. Sorry!

There's a Java procedure to call when a user logs in:

String login(String url, String base, String email, String password)

The URL is the LDAP server to use (e.g. ldap://ldap.arsdigita.com); the base is the node where searches start (e.g. dc=arsdigita, dc=com); email and password are obvious.

What it does is: Query the LDAP server to find the entry with the given email address. If there's any number but exactly one, we refuse to log the user in. Otherwise, we try to bind against the entry using the password. If we fail, we refuse to log the user in.

Now we know the identity (DN) of the authenticated user, but we haven't looked at our database yet. We do this now, by looking up by DN. If there already is a row, we synchronize that row with the new attribute values that we just got from the LDAP (depending on configuration). If there's no row, it means this is a new user, so we insert a row for him, filling in all the values we're configured to grab from the LDAP server.

Future Improvements

Store the LDAP url and base in our general configuration tool.
Store preferred SASL method in config tool.
Store mappings from LDAP attributes to columns in our users table in the same configuration tool thing. We'd want each of them to have synchronization options or 'never', 'on_login', 'regularly', etc.
Netscape has actually standardized an objectclass of passwordPolicy, whereby you can retrieve from the directory itself policies for min/max password length, how much history is kept, etc. We should probably use that.

Lars Pind