Yes, cross-platform Single Sign-On for Java Webapps is possible.

Thu, 24 Jul 2008 17:25:00 GMT

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!

The extra dot in dot-com

Mon, 29 Oct 2007 13:44:39 GMT

Sun no longer claims they "put the dot in dot-com", but did you know there's actually more than one dot in dot-com?

According to RFC1034 "www.example.com" is a relative domain name. The complete domain name (also called absolute) is "www.example.com." (Notice the trailing ".")

Reading this RFC one should think that adding a trailing dot to a domain name should have no effect. All you're doing is to be explicit by using the absolute representation of the domain right?

Not quite so. It doesn't seem like web server vendors and administrators have read this RFC and neither have web browser vendors. This becomes a problem if you're using name based virtual hosting on your web server. When the server gets a request for "www.example.com." it won't have a clue that the user is actually looking for the content at "www.example.com".

So I did a little survey on the web servers I use. The Apache HTTP Server handles the trailing dot perfectly. Tomcat doesn't understand it and serves content from the default host instead. You can mediate this by always adding an alias with the trailing dot, but that's a hack and it's something the server should handle by itself.

I was a little disappointed to find that Jetty (my favorite web server) failed the trailing dot test. But then I remembered how nice the Jetty developers are so a couple of weeks ago I decided to fix the problem and submit a patch for it. Today Greg applied it. From the next release onwards, Jetty will normalize host names before comparing them. Try reporting something like that to IBM or BEA and you'll find out why Jetty rocks!

Now, just for the fun of it, let's take a look at how some big sites handle requests with trailing dots:

Microsoft: Bad request

Microsoft solves the problem the easy way. Just blame it on the user:

MSN: Page not found

MSN is a little more polite, they even say they're sorry:

Myspace: Redirect to google

I knew Myspace and Google made an advertising deal, but this is just weird:

Facebook: Redirect to www.facebook.facebook.com

Facebook is getting so big they seem to have started a facebook inside the facebook, but there's no response there:

NSA: Trust no one, say nothing

One can say a lot about the NSA, but don't give them a trailing dot because they will refuse to talk to you. Period.

Sun: Page not found

Sun may once have "put the dot in dot-com", but that's no longer the case. They're more sorry than MSN though. Sorry with an exclamation point. And what makes them think I own documents at sun.com?

simplericity - tomcat tag