About

Centralised application authentication with Kerberos

Details

Interested in pushing authentication down a layer, so it is managed more centrally, rather than separately by each different application you’re using? Interested in setting up sitewide single sign-on where you work, so that people don’t keep having to enter different (or the same) passwords everywhere? If so, you might be interested in setting up a kerberos server ( http://web.mit.edu/Kerberos ).

Or, does your workplace use microsoft’s active directory server to manage accounts? In this case, you already have a local kerberos server because that’s what active directory uses for authentication.

Once you’ve got that set up, it’d be nice to tie new or existing applications into it so they can use your central authentication service. Enter Rack::Auth::Kerberos. It is available on github:
hhttp://github.com/djberg96/rack-auth-kerberos

…and can be installed from gemcutter:
[sudo] gem install rack-auth-kerberos

Add this to the middleware stack of each of your applications (or near the root if they’re organized in a ‘rack graph’), and use your local realm name when configuring it. I’m assuming you’ve already got your site’s kerberos configuration set up correctly (see the kerberos documentation).

Currently only username/password params are supported. The more complete way to support kerberos is to pay attention to the “Negotiate:” header, which browsers can send if a user has current (ie unexpired) kerberos credentials (“tickets”). Once this is added, rack applications will have true single sign-on support for kerberos environments.

Rack::Auth::Kerberos fits into a set of authentication middlewares I’ve been working on with Dan Berger which are intended to be mixed and matched according to your tastes. For instance, you can combine it with Rack::Auth::Cookie to sign in a user who has just given valid kerberos credentials (especially useful with the current mode of taking username/password — for users presenting kerberos tickets, cookies and sessions may not be necessary at all!). The thing they all have in common is that they use, and set, a common group of environment variables for applications to use:

env[‘AUTH_USER’] = the username behind the current request, if authentication was successful
env[‘AUTH_FAIL’] = the reason the current request failed authentication, if in fact it did fail

If AUTH_USER is set, the request was successfully authenticated. If AUTH_FAIL is set, the request failed to authenticate and applications should show that failure message to the user. If one is already set when #call is invoked, no action will be taken (this is what makes this middleware stackable). If neither is set by the time a request reaches a leaf application, the application should consider the request anonymous.

There are other environment variables this collection of authenitcation middleware uses, but AUTH_USER and AUTH_FAIL are the most important ones for applications and other middleware to pay attention to.

To extend this set of middleware to do a new kind of authentication (say, facebook, openid etc) simply write another separate middleware class that treats these environment variables the same way. That is, passing through requests when AUTH_USER and AUTH_FAIL are set, ignoring requests that don’t apply to their particular method, or setting the appropriate values if they do. Applications can then decide the order in which to try different methods by simply ordering those methods accordingly in the middleware stack.

Usage

Configure Rack::Auth::Kerberos like this:

config.middleware.use “Rack::Auth::Kerberos”, “username”, “password”, “foo.com”

Here I am telling it to watch for requests that include a param called “username”, another param called “password” (it will ignore requests that don’t include these two parameters), and to use the kerberos realm “foo.com”.

Note that it is a common convention to use uppercase realm names (eg “FOO.COM”) but it’s also perfectly legitimate to match your domain name and use lowercase. Stanford does this, as described here: http://www.stanford.edu/services/kerberos/userguide/faq.html