Joe’s Amazing Technicolor Weblog

Here’s the configuration I’ve been working on: control access to Apache webserver by checking (over LDAP) against our existing user database, held in an OS X Open Directory. It’s taken me more casting about than I’d expected, but it looks like I’m finally there.

In the beginning, I got a little confused by the HTTP auth options. I’d been hoping to use Digest mode, but a comment on this post points out the logical problem with that: Digest doesn’t involve the password making its way to Apache, so there’s no way for it to pass the password along over LDAP.

BTW this is under Tiger (OS X 10.4) — I’m not sure if anything changes with other versions of OS X.

Once figuring out that I did need to use Basic auth, Production Monkeys got me most of the way with my Apache config. What I missed is that, at least with our OD configuration, it’s necessary to include the server name in the dc list. Here’s what worked for me:

<Location "/somewhere">
AuthType Basic
AuthName "Whatever You Call This Auth"
Require valid-user
AuthBasicProvider ldap
AuthLDAPURL ldap://servername.yourdomain.org/cn=users,dc=servername,dc=yourdomain,dc=org?uid
AuthzLDAPAuthoritative off
 </Location>

One of the first things that struck me about the IT systems at my current gig is that there are a bunch of different, unsyncronized authentication systems. In other words, to add a new user, you go to a handful of different admin interfaces and type in the same username and password for that person.

Being a programmer, this kind of duplication smells bad to me, so I dug around for possible solutions. One of the systems happens to be Apple’s Open Directory, which speaks LDAP — seemed like the obvious integration point. However, it turned out that none of our other systems was predisposed to pulling in the auth info over LDAP. Since I only have a few dozen users to support, I filed the whole thing deep on my todo list and basically forgot about it.

Now, however, I’m starting to roll out new services, which are mostly web-based. Being loath to make the dup auth situation worse, I gave some more thought to this issue, and realized that OpenID might be a good solution. Off I went in search of an in-house OpenID server to store my user data. ( there is a tool for OpenID-enabling your LDAP server, but reading about implementing it makes my head hurt )

Surprisingly, there don’t seem to be a huge amount of people running their own organization-level OpenID providers. After digging around for a while, I ended up at a page on the openid.net wiki, which does list a number of projects that enable you to run your own OpenID provider. Most of them look a bit half-baked or abandoned, but two appear to be alive and potentially appropriate for my needs: clamshell and community-ID.

Next steps, then, are to install one or both & see how it goes.