It seems that Ruby-PAM (or PAM-Ruby, confusing naming scheme) might be good enough for my purposes, so that I could hook into that, or an LDAP backend, depending on the properties.

However, my gripe isn’t as much with ‘OMG, Ruby tools can do so little!’ but with ‘Dang, LDAP by default, everything else is roll your own’ (essentially).

There is also PAM-MySQL, so that a MySQL DB could be used for authentication.

The trouble is, I’m building on a contract. And while I have a lot of options, I’m severely limited (for example that the OS in question is FreeBSD 5.4. ARGH!) in other regards.

Also, I don’t want to use more than is necessary to solve the SSO problem I have. I could drop this feature entirely, but I don’t want to, since it is an elegant solution in principle. I just don’t like the details involved.

What is a big selling point for me is, that RubyCAS’ documentation mentions that it is easy to write an Authenticator. With Ruby- OpenID, my options are to either use an internal OpenID server (back to the choice of back ends), or use an external OpenID server (doable, but not good for something that is, essentially, an intranet on a WAN).

I haven’t used it yet, and I’ll have to look at it in detail (not just the wiki on Google Code), so I can’t say if or where needs improvement.

(Justin’s RubyConf 2007 presentation looks like it is quite feature complete, and I don’t think that you neglected RubyCAS since then .

Currently I am looking into what *back-end* I’ll have available for user administration, which I *then* can use with Ruby-OpenID or RubyCAS (and RubyCAS looks like the better choice, here, since creating an authenticator for it should be easier, and more geared towards internal uses, than OpenID is).

And yes, a PAM authenticator would be nice. And I’ll have to investigate Ruby PAM a bit more (the project shows activity), and write it and contribute it to RubyCAS.

So, my post isn’t about anything specific regarding the options I have (except that all authentication leads back to LDAP in one way or another, given what I see), and particularly not a gripe about RubyCAS, at all. My apologies if you saw it as such.

Or is it something else?

So, the actual server that I use to access this data is a bit fuzzy right now, since it depends on what the backend will be.

After I have the backend, I’ll look at interfaces to my databse of users. I guess implementing an OpenID or CAS server (or whatever else I dig up) after that will be trivial.

In the worst case, I’ll have to use something like pam_mysql, and connect to this database for authentication.

Still, it hinges on the backend used for storage.

Thanks, and now I’m going to tackle RFC2307..

After I made coffee.

This allows you to put all the stuff *NIX needs for authN/authZ – such as uid, gid, home dir, and the like – into your LDAP directory.

Then you point your NIS wotsit at your LDAP directory and supposedly it all just works.

You should be able to load an RFC2307 schema into pretty much any LDAP directory.

I’ll look into them, too.

Unfortunately, I have no clue if I can get the JRE 1.5 to work or not on FreeBSD 5.4 (and my VM is uncooperative).

Nonetheless, I’ll look into them. If everything works as I hope it will, I should be able to add the Java based LDAP services to the Java app server.

The question is: How well do these integrate into the *NIX infrastructure? I guess I’ll find out (ideally, there is only one point to add users and *all* the *NIX services access this one. Something I can’t quite imagine will be possible with the Java based LDAP.

I will investigate, though.

ApacheDS is easier (but beware: 1.0.2 does not support changing passwords without a restart!). It’s Java.

Sun’s OpenDS looks promising too. Again, Java.

Java apps don’t _have_ to hog the whole machine – Crowd runs very happily in 64MB, handling several thousand requests a minute. ApacheDS is also pretty lightweight in terms of resource usage. I haven’t played enough with OpenDS to have a decent picture of how it performs.