Many enterprises - include most I would guess that are Microsoft-centric - use LDAP to establish user identity and profiles.In the Web 2.0 world, the emerging standard is OpenID. Is there a way to use OpenID to provide logins within the Enterprise buthave it backed by LDAP, the obvious benefit being one could install off-the-shelf intranet tools inside one's organization butnot have to LDAP-enable them or create a parallel account system
The OpenID-LDAP Project (http://www.openid-ldap.org/) offers such a tool.
We're testing this on a Macintosh, but there seems to be no reason this won't work on any UNIX-y system.
Installation
First, download an unpack the code into the web server directory.
$ cd ~/Sites
$ curl --location 'http://www.openid-ldap.org/releases/openid-ldap-0.8.5-noarc.tar.gz' >openid-ldap-0.8.5-noarc.tar.gz
$ tar zxvf openid-ldap-0.8.5-noarc.tar.gz
This extracts the code into a non-versioned subdirectory called ‘openid-ldap'. It would be much better form if the directorywas called ‘openid-0.8.5'.
Interlude: Enabling PHP on Mac OS X Leopard
Leopard has PHP but it has to be explicitly enabled by editing configuration files (if you haven't enabled Apache on yourMac, see the links below)
$ su -
# cd /etc/apache2
# vi httpd.conf
remove the hash sign on the ‘LoadModule php5_module' line
# apachectl restart
Here are some helpful links if you need more information:
- http://blog.phpdoc.info/archives/83-php-5.2.5-on-Leopard.html
- http://www.phpmac.com/articles.php?view=225
Running to Stand Still
Without configuring anything, let's see what happens when we visit the page:
- http://localhost/~davidjanes/openid-ldap/
Note that URL is Leopard's way of referencing a user's (i.e. "davidjanes") local webpage.
A webpage appears with a field for entering a username - but not a password. Entering a username - e.g. dpjanes - redirectsus to the 404 page:
- http://localhost/~davidjanes/openid-ldap/dpjanes
... which definitely wasn't expected.
Reading through their documentation, it looks like they're mainly doing this using SSL/HTTPS and to do that one has to addsome rewrite rules to the Apache configuration. Since we're not doing that - at least not yet - we're probably using aninfrequently used code path, thus hitting a bug. Perusing the code we should see the URL above should be internally rewrittento:
- http://localhost/~davidjanes/openid-ldap/index.php?user=dpjanes
To fix this we have modify the Apache configuration again. Changing ".htaccess" does not work because Apache on Leopard isconfigured "AllowOverride None" which means the rewrites will be ignored
$ su -
# cd /etc/apache2/users
# vi davidjanes.conf
And then we add the following:
RewriteEngine On
RewriteBase /~davidjanes/openid-ldap/
RewriteCond %{REQUEST_URI} ^/.*[/]([a-z][-a-z0-9_]*)$
RewriteRule ([A-Za-z0-9]+)$ /~davidjanes/openid-ldap/index.php?user=$1 [P]
And then
# apachectl restart
Note that these rules are predicated on that we're going to be logging in using OpenID's "uid" which will be lower caseletters, numbers, dash or underscore.
Configuring LDAP
This is obviously the part where we're going to part paths - everyone does LDAP their own way. We don't have an
ActiveDirectory setup here, but we do have VMWare Fusion (http://www.vmware.com/products/fusion/) and a JumpBox for
OpenLDAPappliance (http://www.vmware.com/appliances/directory/1105) so it should be just a simple matter of figuring out the
rightcombination of configuration settings.
The OpenID appliance has the following configuration:
- JumpBox Name: openldap 0.9
- Application Page: http://192.168.1.120/
- Management Page: https://192.168.1.120:3000/
I've already configured a few accounts on this, but for example we have a user:
- o=Directory
- ou=users
- cn=David Janes
In LDAP terms this gives us a "Distinguished Name" which is the really way LDAP (as I understand it) uniquely identifies
arecord. In this particular case our Distinguished Name is "cn=David Janes,ou=users,o=Directory".
This user has the following configuration:
- cn: David Janes
- gidNumber: 1000
- givenName: David
- homeDirectory: /home/users/default/dpjanes
- objectClass:
- inetOrgPerson
- posixAccount
- top
- sn: Janes
- uid: dpjanes
- uidNumber: 1000
We're going to use "uid" as the login ID - note that this is by no means a universal choice nor is it universally availableon all LDAP servers. I've seen LDAP servers use "name" to provide a unique identifier and it's possible - maybe even probably -that many LDAP servers don't provide short unique names at all.
Note then how LDAP logins should probably work:
- one provides a part of the record we are looking for, for example "uid=dpjanes", where the user at login time provides the "dpjanes" part and the configured application prepends "uid="
- given a starting point - the "searchdn" in the configuration below - we look for a matching record
- when we have the matching record, we get the Distinguished Name which uniquely identifies a record and that we ask LDAP to validate it with a password
Note that OpenID-LDAP doesn't actually work quite this way; we'll explain this further down.
Configuring OpenID-LDAP to contact LDAP
Following, the instructions in openid-ldap/docs/README.txt, especially point (5) we get the key points of configuration -edit "ldap.php" and fill in the values.
The original connection settings look like this:
'primary' => '10.0.0.111',
'fallback' => '10.0.0.222',
'protocol' => 3,
'binddn' => 'cn=<name>,cn=users,dc=domain,dc=local',
'password' => '<pass>',
'searchdn' => 'cn=users,dc=domain,dc=local',
'filter' => '(&(cn=%s)(mail=*))',
'testdn' => 'cn=%s,cn=users,dc=domain,dc=local',
'nickname' => 'uid',
'email' => 'mail',
'fullname' => array('givenName', 'sn'),
'country' => 'c'
Our new connection settings look like this:
'primary' => '192.168.1.120',
'fallback' => '',
'protocol' => 3,
'binddn' => '',
'password' => '',
'searchdn' => 'ou=users,o=Directory',
'filter' => 'uid=%s',
'testdn' => 'uid=%s,ou=users,o=Directory',
Note the reasons for this:
- primary: as per the VMWare notes above
- fallback: we don't have a backup server
- binddn & password: it works without this; but we assume there's LDAP configurations that require you to login with a well-known Distinguished Name and password before you can do a search
- searchdn & filter: the ‘%s' is replaced with the user's login name (i.e. from the login form) and then these items are put together to search for the user's record
- testdn: when actually logging in, the ‘%s' is replaced as above; the page then tests the modified testdn with the password provided against the server
Note then the difference between OpenID-LDAP and our hypothetical login scenario in the previous section - OpenID-LDAPsearches for the login but after validating that it exists, ignores the Distinguished Name and just tries to log in using asimply constructed testdn and password. This works, but it strikes me that the search is either unnecessary or the loginprocedure is insufficient.
Failure
Alas, at this point we're going to have to stop, unless someone has a suggestion. When I attempt to log in with "dpjanes" weend up with OpenID-LDAP bridge trying to log in with "uid=dpjanes,ou=users,o=Directory", which simply doesn't work. Whetherthis is specific to my LDAP implementation or not is unknown.
If I alter the rules so that I'm logging in with "David Janes" / "cn=David Janes,ou=users,o=Directory" the (slightlymodified) Apache rewrite rules get confused because of the space. I could probably fix these but quite frankly I don't want tobecause I want "dpjanes" to be recognized as the login.
So, that's as far as I'm getting with this. If anyone has further suggestions, please let me know and I'll modify thisdocument and necessary.