RSS feed
<< Previous | Home | Next >>

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

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!

Implementing decorator templates with Apache Velocity

A couple of years ago I started replacing JSPs with Apache Velocity for generating  HTML in my web applications. The simplicity and speed of Velocity was very appealing to me compared to the complex beast that JSP is.

Compiling JSP to Java, then to byte code and then loading and running it as class obviously must have seemed like a good idea to those who came up with it. For me, it's always been crazy talk.

When designing HTML templates reusability is always an important goal. You want to define your header, menu and footer once and then reuse them for both your front page, article page or about page.

The no-brainer solution to this is to use tags or directives to include common snippets of HTML into the final page. JSP supports this with the @include syntax  or the <jsp:include/> tag:



Like any no-brainer solution this one is not very smart. You end up with brittle and inflexible templates where you need to touch all your templates to do any kind of structural changes to your main design.

A much better solution is to apply the decorator pattern. Instead of pulling in common pieces of HTML everywhere you need them you just specify what's special with this particular page and then apply a decorator template to it. This template will take care of creating the actual design.

There's no built in support for creating decorator templates in JSP, so what used to do was to create a small taglib that would let me define a snippet of HTML as a section and then output that snippet in the design template. I know a lot of people use Sitemesh for this, but I found the taglib solution worked very well for my purpose.



Like JSP, Velocity has no built in support for creating decorator templates. At first I just accepted this situation as a trade-off. With Velocity being so simple, I'd just have to learn to live with all the #incude directives right?

That was until I discovered that Velocity actually has support for custom directives. So now all I had to do was to create a directive that rendered it's body into a string and stored that in the context for later use. This turned out to be very easy:

public class Section extends Directive {
    public String getName() {
        return "section";
    }

    public int getType() {
        return BLOCK;
    }

    public boolean render(InternalContextAdapter context, Writer writer, Node node) throws IOException, ResourceNotFoundException, ParseErrorException, MethodInvocationException {
        ASTReference nameNode = (ASTReference) node.jjtGetChild(0);
        String name = nameNode.getRootString();
        StringWriter sw = new StringWriter();
        node.jjtGetChild(1).render(context, sw);
        context.put(name, sw.toString());
        return true;
    }
}

Now I can create templates like this:

#section($content)
<h1>Content here</h1>
<p>Hello World</p>
#end

#parse("design.vm")  

Registering my #section directive with Velocity was easy. Adding a userDirective property with the name of the directive class did the trick.

Seeing how easy this is and how much better it made my template system I'm amazed that Velocity doesn't already have something like this in its core.

Lucene gets a performance boost

Following the release of Lucene 2.3.0 on January 24th, I decided to upgrade an application I'm developing. The change log promised several improvements in indexing performance.

My application uses Lucene to index moderately complex information about events. Testing the application with Lucene 2.2.0 I found that a full reindex of 80.000 events stabilized on 164 seconds after a few rounds to make sure the JVM and caches were warmed up.

After upgrading to 2.3.0 and switching IndexWriter.setMaxBufferedDocs() to the new IndexWriter.setRAMBufferSizeMB() I started a reindex again to measure the difference.

So how long did it take to reindex 80.000 events in Lucene 2.3.0?

35 seconds

That's 470 percent faster!

So thanks to the Lucene team for the great work with this release. These guys continue to impress me.