A while back I talked about Apache authentication, with the hope that people would suggest some alternatives. And they did, and for the last week or two I've been trying to figure out what to do. To recap, my goals:

• Centralize all identification at the Apache level, not at the level of individual applications.
• Not use HTTP Basic authentication, which I hate.
• Not use any specific authentication/identification backend; we authenticate different users for different clients in different ways.
• Hopefully make it possible to use across servers/domains, even if it takes a bit of fiddling. IIS support is nice, just in case, but integrating with other people's systems (and we don't use IIS internally) is always a messy situation, so even with IIS support we can't expect too much.

Anyway, a couple things were suggested. The first I looked at was Pubcookie, out of the University of Washington. Supports Apache 1.3 and 2, and IIS. Very focused on secure single-signon across a large network. Universities typically have lots of systems administered by very different groups, and often don't have a high degree of shared trust. And every year there's a new batch of students who learn about network sniffing. But this isn't exactly my situation, but it seemed like sufficient overlap.

But I got Pubcookie installed, which was a little confusing at times but not too bad. It has an undocumented verify_fork method which calls an external process, and this makes username/password authentication easily pluggable (but not IP authentication, for instance). It uses cookies, not HTTP Basic, and a series of redirects and a CGI script for the authentication process.

But I've been hitting a number of walls, and I don't know how well it will work out. HTTPS is required for everything -- essentially programming policy into the tool. I'm not super concerned about someone sniffing an authentication cookie that is going to time out anyway, so this restriction is a little annoying. Logout is really difficult to understand or implement -- I think something is possible there, but I can't figure out quite what that is. Also, there's a fair amount of Apache configuration to change permissions around -- again, I may be able to get around that using conventions, but that's considerable added complexity (and I don't ultimately want to reconfigure Apache very often). And finally the installation is rather complicated; considering we're going to have a distinct installation for every client, and that installation includes an extra keyserver (who's purpose I don't quite understand) and a set of configuration files and several SSL keys, this makes me uncomfortable.

CoSign looked almost identical, but with nicer graphical design and poorer documentation. It also comes out of a university.

mod_auth_tkt was also suggested, but it took me a while to get around to looking at it. This looks much more promising to me -- it's fairly simple, and consists only of the identification portion. It documents the cookies you have to set for authentication (and provides a sample implementation, I think, but the documents are more than enough for me). It doesn't have multi-server single-signon out of the box, but it's not hard to figure out how that would be set up (basically a set of redirects to get the browser to visit all appropriate domains). It even has room for extra data, like user roles. It's all based on a shared secret (with signed cookies, I believe), but that's 100% okay for our situation (but probably wouldn't be for Pubcookie).

The real bummer for me is that it's for Apache 1.3 only. I see evidence of Apache 2 ports (mod_auth_tkt/2.0.0b1 in Apache identification strings), but none that are publically available. That's really frustrating. It's another one of those projects that isn't developed openly (public repository, mailing list, etc), which has been frustrating me often lately -- open source without open development is a terrible waste. Personally I don't have the C or Apache module skills to resolve this, but if we go forward with this we'd probably be willing to pay someone who does.

I also looked at mod_auth_script, which is kind of interesting (though also largely abandoned). It's got even less policy than mod_auth_tkt. I haven't tried it, but I think you just configure an authentication URL (probably internal), like /auth_script.cgi -- on every request that gets run, and it outputs special headers that indicate who, if anyone, is logged in. You could implement a signed cookie authentication, or IP-based authentication, or anything on top of this. My only desire would be the ability to add other environmental variables (e.g., REMOTE_USER_GROUPS). Essentially it would become a generic hook which didn't involve mod_*. There's an Apache 2 patch, but unfortunately I'm not sure how much I trust any of it in its unmaintained state.

I'm still shocked at how hard this is. 60% of the web servers out there use Apache. This is a really, really useful feature, and something I see people struggling with everywhere. And yet I mostly see the remnants of work to solve this, not a single robust solution or community of developers. We don't need another mod_auth_another_stupid_backend. I feel like I must be missing something?!? Sigh. Any other feedback is very welcome (and I'll report back on this yet again, no doubt).