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.

We've made a number of changes to our OpenID implementation:

• you cannot create more than one account with the same OpenID [1]
• when creating an account with an OpenID, "Create Account" becomes "Verify OpenID"
• after verifiying, the new login page clearly displays your OpenID and does not prompt for a password

[1] we are going to allow this in some future version; after login you can choose your account.

Onaswarm (and the BlogMatrix Platform in general) now supports OpenID:

• if you already have an account, you can associate an OpenID with it
• if you create a new account, you can start with an OpenID which will then be associated with your account
• you can log in with the OpenID associated with your account

It's actually simpler than it sounds! A few more notes:

• where possible, we take configuration information from your OpenID provider
• you'll see the OpenID logo in all appropriate locations
• we are not an OpenID provider yet -- you can't log into another site using onaswarm.com yet.
• if you have multiple accounts, you should use different OpenID logins. We'll do something about this later...
• if you're interested in trying it out, you may already have an OpenID; if not, I've been pretty happy with this provider.

The Read/Write Web (yes, them again) has a screencast on OpenID. The post also has information on the current state of single login and OpenID adoption.

See the OpenID tag for more analysis from us on OpenID.

Here's what we've posted about OpenID (developers). We hope you've enjoyed these posts and found them informative and if you have any questions, comments or notice any glaring faults please leave a message in the comments.

• OpenID: introduction (why we're writing these posts)
  
• OpenID: how the end user sees it (with diagram)
  
• OpenID: authentical details (with diagram)
• OpenID: identity page (how to use your own domain name)
  
• OpenID: further reading (links to places discussing and documenting OpenID)
  
• OpenID: sharing identity details; hCards and microformats (OpenID or microformats for sharing identity information such as full name, age, etc.)
  
• OpenID: security concerns (OpenID isn't perfect)
• OpenID: what's BlogMatrix doing? (when will you see it here)

You can read all the posts at this tag.

Here are BlogMatrix's current plans for OpenID:

• we're going to do something eventually, probably by year-end
• accounts will be created in the "normal way"; there will be a settings page for OpenID
• once you've setup your OpenID information, you'll bypass the BlogMatrix login stage. You will still, however, be logging into a "normal" BlogMatrix account
• the login page will have a little OpenID icon in the User ID field, for those in the know
• we're probably not going to be an identity server
• we may or may not do something about transfering identity information; I don't like what OpenID has done and I think microformats can handle it better

Blake in the comments notes the issue of phishing -- that is, making a fake website duplicating the look and feel of a real website to capture passwords and identity. As far as I can tell, OpenID has no good solutions (here's a discussion that doesn't end up being that helpful).

Here's a few ideas I've had mulling over this:

• run your own identity server with your own unique look and feel. This may not be too hard with Amazon EC2 type services, particularly if you could do something like run Java Servlets.
  
• Identity servers should mail you new sites that you've accessed, possibly putting a hold on your account if there's suspicious activities
• Identity servers could provide multiple levels of passwords; lesser passwords could be used for establishing identity at untrusted sites; the highest password could be used for direct administration of the identity account

On other security issues:

• preventing replay attacks (summary: it's handled by the best libraries)
  
• trust, spam and signing comments (summary: out of scope)

OpenID has a protocol extension that allows some simple identity information to be shared (i.e. so you don't have to type in the same info over and over again in every site you visit).

Here's the spec and here's what information is sharable:

• nickname
  
• email
  
• full name
  
• date of birth
  
• gender
  
• postal code
  
• country
  
• language
  
• timezone
  

My personal opinion is that the "Simple Registration Extension" was a mistake as it confuses what OpenID is all about, is inherently incomplete and doesn't build upon what's already out there. OpenProfile has taken the extra step and hooked up with vCard but let me propose something else based on microformats and hCard.

One issue I have with the utility of hCards is that often, as they are seen in the wild, they are basically trivial. From here:

<address class="author vcard">
  <a class="url fn" href="http://theryanking.com">Ryan</a>
</address>

Note that this is still good -- this marks real semantically useful data. However, I always get the feeling that this could be ... better, particularly since we know Ryan (King) has a real hCard right here with a mugshot and everything!

Why not build upon the concept of the identity URL? In particular, let's say that that http://theryanking.com is Ryan's identity URL. In addition to the link and meta tags added to the header for OpenID, let's add one for "person identity":

<link rel="identity.hcard" title="Ryan" href="http://theryanking.com/blog/contact/#vcard" /> 

We now use this in two different ways.

Firstly, from an OpenID perspect when Ryan creates a new account using http://theryanking.com, the consumer can automatically go get Ryan's hCard at http://theryanking.com/blog/contact/#vcard.

Secondly, we can indicate in Ryan's trivial hCard (seen on the microformats blog) that we can get Ryan's real hCard:

<address class="author vcard">
  <a class="url fn x-identity.hcard" href="http://theryanking.com">Ryan</a>
</address>

This has several nice attributes:

• We don't have to add verboten hidden data to indicate the location of the "best hCard"
• It's totally backwards compatible -- if we just used "url" we'd have to check too many spurious links for non-existent information
• It builds open microformats and OpenID -- public identity parameters only have to be specified in one location

Note: x-identity.hcard and identity.hcard are possibly just placeholder strings for something better, so don't get bent out of shape by that.

Here are some useful sites and pages about OpenID:

• OpenID -- the official home page
• spec
  
• OpenID Enabled -- for developers:
• Python
• Ruby
• Perl
• PHP
• DotNet
• Java
• Wikipedia -- this page could use some work
• Identity Servers:
• LiveJournal.com
• MyOpenID.com
• TypeKey
• VeriSign's PIP
• Many more...

In the diagrams earlier in this series, we used http://davidjanes.myopenid.com as David's "identity URL" -- basically, the analogous thing to a username in OpenID. David is also using MyOpenID as his "identity server" -- the site he will log into.

There is no requirement in OpenID that your "identity URL" be on your "identity server".

OpenID provides for a layer of indirection between your identity URL and your identity server. When logging in, the "consumer" (the role BlogMatrix.com is playing in the diagrams below) looks at the identity URL, reads the page, looks for a special link identifying the identity server and if found, uses that.

Let's spell that out with an example:

• David's identity URL is now http://www.davidjanes.com
• David types http://www.davidjanes.com into BlogMatrix's login page
• BlogMatrix reads the page at URL "http://www.davidjanes.com" and sees in the HTML header:
  
  <link rel="openid.server" href="http://www.myopenid.com/server" />
  <link rel="openid.delegate" href="http://davidjanes.myopenid.com/" />
  <meta http-equiv="X-XRDS-Location" content="http://davidjanes.myopenid.com/xrds" />
  
  
• BlogMatrix knows how to understand all that stuff to use MyOpenID as the server

Note that the particulars for all these fields will change if you're not using MyOpenID, but it'll be something very simular.

Here's a modified diagram of below, showing the additional steps that happen behind the scenes. A few more notes and caveats:

• the flow for this diagram comes from here; all mistakes are mine I'm sure
• this diagram is made from the perspective of how I think our application has to do it; there may be more to OpenID that I'm showing
• new parts are in redish
  
• I've try to simplify things so that "new to OpenID users" can easily understand what's going on. This required a couple of shortcuts:
• David's Identity Page (i.e. http://davidjanes.myopenid.com) doesn't have to on the same server or domain as the server that's actually doing the authentication (MyOpenID.com). David could, for example, use http://www.davidjanes.com to login and still get MyOpenID to do the login. We'll dedicate a whole post to this so stand by.
• The diagram uses the preferred login flow that uses a "Diffie Hellman exchange" to create the shared secret (a diagram of the gory details are here in comp-sci hieroglyphics). There's also a "dumb mode" that skips the shared secret stage and let's the "consumer" (i.e. the role BlogMatrix.com is playing) validate the login after the final redirect.
• If the MyOpenID has never seen David log in from BlogMatrix before, it is supposed to confirm first with David that he trusts BlogMatrix with his identity

You can follow all my posts on this subject at this page or this RSS feed.

Here's a little image I "visioed-up" explaining how a user David could log into BlogMatrix using his OpenID identity of "http://davidjanes.myopenid.com". It's a workflow that you read from top to bottom. The neat thing is that from David's perspective:

• he only needs to know one login/password pair for all his OpenID enabled accouts
• compared to a "normal" login session, there's an extra step -- rather than entering the username/password on the same page, he enters his username (i.e. OpenID identity) on one page and enters the password on the next page

Prompted by a Chris Messina post, I decided to do a little investigation into OpenID (wikipedia). I'll be doing this a series of posts over the next couple of days. Adding OpenID is an immediate priority for us (see Ross Rader for the though pattern involved) but as time becomes available I could see this being added.

You can follow all my posts on this subject at this page or this RSS feed.