Simple Kerberos client in Java?

Applications such a Google's Chrome and IE can transparently handle Kerberos authentication; however I can not find a "simple" Java solution to match this transparency. All of the solutions I have found require the presence of a krb5.conf file and a login.conf file which nether of the above apps seem to require.

What is the best way to build a Java application with Kerberos SSO capabilities that just work?

[update]: to be clear I need a CLIENT side solution for creating tickets not validating them. Also, it seems that SPNEGO is the default "wrapper" protocol that will eventually delegate to Kerberos but I need to be able to handle the SPNEGO protocol as well.


Solution 1:

There is now a simple solution for this using the Apache HTTP Components Client 4.5 or greater. This is still marked as experimental in 4.5 so your milage may vary, but this is working fine for me in an enterprise context.

In addition to the HC 4.5 client jars you will need to have the httpclient-win, jna and jna-platform jars on your classpath, as provided with http-component-client. You then construct a Kerberos enabled HC-client as follows:

CloseableHttpClient httpclient = WinHttpClients.createDefault();

Or using the builder:

HttpClientBuilder clientBuilder = WinHttpClients.custom();

Which can then be customised as required before building the client:

CloseableHttpClient client = clientBuilder.build();

This solution works without any external configuration, and most importantly solves the issue where the in-built JRE mechanism breaks for users with local Admin rights on Windows 7+. This is possible because the Kerberos ticket is being retrieved directly from the SSPI API via JNA, rather than going through the GSSAPI provided by the JRE.

Example code from the http-components team

This was all made possible by the good work of Daniel Doubrovkine Timothy Wall and Ryan McKinley

Solution 2:

Adding to David Roussels answer on url specific http based kerberos authentication:-

The reason why your code works is because your target SPN(server side principal) is configured to with HTTP/[email protected]. In that case it will work because you are not explicitly setting the token. URLConnection internally sets a token with that SPN

1 Perform steps(from my previous answer) to get a subject

2 Use gss api init sec context to generate a context token. There are numerous tutorials out there for this step

3 Base 64 encode the token

4 Attach the token to urlconnection:-

URL url = new URL("http://myhost/myapp")
HttpURLConnection urlConn = (HttpURLConnection)url.openConnection(); = 
urlConn.setRequestProperty("Authorization", "Negotiate " + encodedToken);

5 Implement a priviledged action:-

//this internally calls the getInputStream
public class PrivilegedGetInputStream implements PrivilegedExceptionAction<InputStream>

6 Wrap the whole thing in Subject.doAs

//use prev answer instructions to get subject
Subject.doAs(subject, new PrivilegedGetInputStream(urlConnection)

Solution 3:

Oracle has an example using Java's SaslClient. I'm not a Java programmer, but when I pointed this out once to someone who is, they were able to make it work pretty quickly. It may still require a "conf" file somewhere (n.b. Kerberos uses environment variables, often starting with KRB5_, to know where to look for such files). Also note that Kerberos itself does not include a transport of any kind--your app needs to know how to send and receive the Kerberos payloads the way the server expects (and this is different depending on the server you are trying to authenticate with).

Edit: you edited your question, so here's a link related to SPNEGO in Java which might be of some use: http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/lab/part5.html

Solution 4:

You don't actually need to do anything. In Java 6, on a Windows client machine you can do this:

new URL("http://myhost/myapp").openStream();

And negotiate authentication just works. At least it does for me. And the server I tested on only supports Negotiate, not NTLM auth.