A customer participating in the SVNSearch beta round asked me about Single Sign-On solutions for SVNSearch. SSO has become something of holy grail in the Enterprise. Everyone wants it but few seem to really achieve it. The Wikipedia article for Single Single-On even cites a Gartner report stating that "no one can achieve it without a homogeneous IT infrastructure".

What could be a better motivation than Gartner saying it's impossible? I decided I'd prove them wrong and took on the task to create a cross platform, Single Sign-On solution for SVNSearch.

The NTLM headache

As it turns out, there are only a couple of options available for Web SSO . The Java CIFS Client Library (JCIFS) implements Microsoft's NTLM technology. NTLM is a challenge-response authentication mechanism, and being a product of Microsoft it's not much of a surprise that it has a history of security weaknesses.

NTLM has caused me lots of headache on a past project because it doesn't play nice with the basic rules of HTTP. NTLM is a connection-oriented protocol, so both the server and the client needs to keep the same TCP connection open for at least the three request it takes to do the authentication. This is just fine when Internet Explorer is talking to Microsoft's IIS server, but when you introduce a web server like Tomcat, weird things start happening.  In our case Tomcat would start sending Connection: close headers under heavy load. This is a perfectly sensible thing to do – if you're running low on available threads, turing off keep-alive is  better than refusing requests. But in the NTLM case it made Internet Explorer fail with a non-decipherable error page.

Finally, NTLM isn't really cross platform. Both Firefox and Safari have adopted NTLM, but they'll pop up a username/password dialog on non Windows platforms.

Enter Kerberos

So you might not be surprised to hear I wanted something better than NTLM. I'd been reading about Kerberos for years, but my impression was that it required an army of sysadmins to set up and a Ph.D in cryptography to create software for it.  Then I realized Microsoft actually use Kerberos for their domain controllers so I already had the infrastructure set up. I started looking for open source projects implementing Kerberos authentication, but I couldn't really find anything. There were a lot of pointers to a an old patch providing Kerberos support for JCIFS, but it doesn't seem like it ever got applied.

So it seemed like I had no option but to roll my own. In doing so, I had to spend some time trying to understand how Kerberos works. And it's not really that hard. Every time you log on to your Windows Domain Controller, Windows acquires a Kerberos token from the Domain Controller. This token can be used to fetch another type of token that lets you log into network services like my Java based web server. The service also has to authenticate itself and that is taken care of by issuing KeyTab files containing secret keys for the service.

The implementation

Kerberos is implemented in Java through the GSS API. GSS is a just a wrapper API around token based security mechanisms like Kerberos and doesn't provide any security itself. The authentication of the service is done through a JAAS LoginModule, the Krb5LoginModule.  The module needs to be configured to use a KeyTab file and to store the credentials in the Subject. This way the credentials can be used in the next step when authenticating users. You only need to do the service login once, after that you can keep the Subject around as long as the service is running.

It's important to name the service principal correctly. The principal name needs to match the host name of the service  and the host name needs to have a DNS A record who's IP address resolves back to the host name. User authentication is done through the GSSAPI. I'm using the GSSManager to create a GSSContext. This context is then fed the Kerberos token in the acceptSecContext() method and  if isEstablished() returns true we can fetch the identity of the authenticated user with getSrcName().

Web-based Kerberos

Kerberos was invented before the web and doesn't specify how tokens should be transported in a web context. Microsoft implemented SPNEGO in Internet Explorer 5.01 as an HTTP authentication mechanism. When the server requires user authentication it sends a HTTP 401 status back to the user with a «WWW-Authenticate: Negotiate» header. The browser then resubmits the request, now with a «Authorization» header containing a security token. This ping-pong game continues until the underlying security mechanism is negotiated and the user is authenticated. SPNEGO is a pseudo mechanism used to negotiate the use of a real mechanism in the case that the server and client don't agree on a mechanism upfront. SPNEGO is implemented in Java 1.6 as a part of the Java GSS API. However, the SPNEGO token is DER encoded so it's pretty straight forward to extract the real  Kerberos token from a SPNEGO token if you're running on Java 5 or 1.4.

Cross-platform support

OS X supports Kerberos. You can set up OS X to acquire Kerberos tickets when logging in or you can use kinit command line tool or the graphical utility Kerberos.app for  ticket administration. Most Linux distributions also have Kerberos support. Kerberos is supported in  both Safari and Firefox, although Firefox doesn't send SPNEGO tokens but pure Kerberos tokens instead. So my code needed to take that into account.

The result

Although it did require a fair amount of research and development I must say I'm very happy with the end result. I now have a 100% pure Java Single Sing-On toolkit. Having complete control of the authentication process also gives some nice extras. I can present the user with a fallback login page if automatic login fails. I can also let the administrator test the Kerberos configuration and provide some useful feedback if something doesn't work.

If there's any interest in this  code please let me know. I might consider making a small open source project out of it or contribute it to an  existing project. And to the Gartner dudes: I now have Kerberos based SSO solution that works great in a cross-platform environment,  so go eat your socks!