We have a problem, and that problem is authentication. In a not uncommon pattern, we have a central set of core services, run by a core group; email, fileservers, the login servers, and so on. Then we have a bunch of other people who want to build various web applications, ranging from departmental things all the way down to graduate students putting together projects.

Many of these web applications need accounts and authentication. The natural and best logins and passwords to use are people's existing departmental accounts, because who wants to force people to remember another password? However, for obvious reasons we're in no position to give our Unix password file out to people in general; we use shadow files for a reason, after all. Ideally we would like to not even give them out for departmental web applications.

At a conceptual level, what we need is some sort of authentication service. It's easy to build something that takes a plaintext password and login and gives you a yes or no answer (in fact, given IMAP people can build one themselves), but this has two drawbacks. First, we'd like the service not to be a mass password guessing service too, and second, we'd ideally like web applications to never even deal with those departmental passwords, so that we don't have to worry about people's applications mis-handling them.

For a while I have been thinking that OpenID could be the solution to this problem. It should be simple to create an OpenID provider that authenticates users against our Unix password file, and expose it as, say, 'openid.cs/~<user>/'. Authors of local web apps would then have a simple way of authenticating people; essentially they would get access to our departmental logins for free, in a way that means we don't have to worry about their application and system security, or try to get approval for sharing selected encrypted shadow passwords with them.

(And who knows, a departmental OpenID identity might turn out to be more generally useful; people might want to use it when dealing with outside websites that use OpenID, if there are very many.)

I suspect that it's simpler to integrate (restricted) OpenID into modern web applications than to try to hook them into a Unix or Unix-ish password authentication system. And even if it's just as complicated, the upstream developers are more likely to accept patches to add OpenID support than to add support for authenticating against a Unix password file; it's simply more general, these days.