Why have thee forsaken me, oh SSO?

OpenIDImage via Wikipedia

As I've talked about before, I'll talk about the requirement gathering first.

Currently, I'm looking into SSO solutions on *NIX like systems. Which is a certainly interesting field (lots of commercial vendors, in case you need somebody to sue, as Justin Gehtland put it in his RubyConf '07 presentation Ruby and Identity: OpenID, CAS and Information Card at RubyConf 2007).

However, I don't want to buy a solution. My solution shall work with open source software as much as possible (which is a topic for another day).

Since I am using Ruby, my options are currently severely limited:
These two options are the best supported for Ruby, which means that both the client as well as the server are available in Ruby. There are quite a few SSO solutions available, but most run as a Java application, or as a C solution. While the latter isn't much of an issue, the former is. I don't want to suck out the whole memory and CPU of a small server just for single sign on!

[Edit for clarity: I am taking a look at the storage and retrieval of users and their credentials, before I actually use SSO. On the one hand: I can create the infrastructure from scratch, on the other hand I have to create the infrastructure from scratch, and can't just gear it all towards my little app, but have to consider a lot of usage scenarios. The information about SSO solutions is more about context, than the focus of my post. - Phill]

But what about the backend? How do you integrate the user database, I hear you ask.

This is the fun part (or frustrating):

Almost all SSO solutions come back, in one way or another, to OpenLDAP (or another LDAPv3 compatible directory service), as storage service for user data. The authentication is, usually, done via Kerberos.

Quoth Wikipedia:
Kerberos is the name of a computer network authentication protocol, which allows individuals communicating over a non-secure network to prove their identity to one another in a secure manner.
And while I like to apply a certain extend of.. overkill to a solution, this isn't really feasible. It is one (1) server that is being used, with three (3) users (current projection). Not concurrent users. Maximum users. Even LDAP is over the top for this solution (however, it allows for 'true' SSO on *NIX, via PAM).

Both OpenID and CAS can plug into LDAP, and you can use LDAP as authentication source.

But what about if you cannot use LDAP? Well, the other option is to authenticate a user against /etc/passwd. Ruby surely is able to do that out of the box. It comes with the Etc module, after all. Well, yes, but no. While it does come with the Etc module, I haven't found a way to use built-in Ruby tools to authenticate against /etc/passwd (well, there's Ruby-PAM, but the last release was in 2004. Not quite trust-generating for authentication).

So, at the moment I am considering using (parts) of Jamis Buck's Net::SSH to hack together an OpenID or Ruby-CAS authenticator. This solution has The Smell, though, and already feels brittle. I cringe just thinking about it.

The benefit of this hackish solution would be, though, that no server excpet the SSH daemon would be required. And that one is already available (also, I don't have to care about details like user maintenance, since the SSH daemon handles that for me).

But would the pain of maintaining something like this outweigh the pain of installing and configuring OpenLDAP? That is for the client to decide. I'll talk about the actual solution once a decision has been made.

Also, if you have worked with ruby-pam and pam-ruby or have valuable experience regarding OpenLDAP (Especially on FreeBSD 5.4!), it'd be great if you could leave a comment.

Kicking off the blog (and the project, too)

I promised myself, that I'd chronicle my efforts in developing a project from start to finish.

Well, this won't quite work out, since I already have the contract in hand. ;)

However, I'll write up what I am going to do, what I am doing, and the milestones reached. Well, a software development blog.

So, what's the project about?

I have to build a web-based Document management system.

Requested Features:

  • Single Sign On
  • Import documents from a network share
  • Storage of metadata (an odd one in this case is, that physical locations have to be recorded, too, in case the government agency sending it cannot deal with electronic documents. Legal requirements are fun like that)
  • Fortunately, no detailed tracking for SOX or other such regulations.

What's coming up

At first, I'll post progress about gathering requirements, proposals and recommendations of solutions for these requirements that go out to the client (after I've sent them, though).

After that, I'll report my progress with the application: What I did, why I did it, and what the challenges were.

And last but not least, I'll talk about the deployment of the application, and its maintenance.

So, what are you using?

The web application framework is going to be Ruby on Rails, the database back-end MySQL, the webserver will be Apache of some sort. What'll serve the Rails pages I don't know yet. Maybe Glassfish with JRuby, maybe mod_rails, possibly the classic Apache + Pack of Mongrels solution. We'll see when I get there.

My development OS will be Windows XP together with a Debian VM and a Kubuntu 8.04 installation as primary development OS.

The deployment will be on FreeBSD 5.4 (I know, I can't influence that, and neither can my client).

The approach I'll be using, even though I'm just one person, is a simple variant of Agile Development: Sprints, and loads of tests before I write the actual code.