Is there a way in Java or a command-line util to obtain a Kerberos ticket for a service using the native SSPI API?

Question

I want to implement Single Sign On with Kerberos in Java and have successfully managed to create a ticket for the Service using the ticket from the Windows logon. Unfortunately, I can only create that ticket when the Registry Key "allowtgtsessionkey" is enabled. I am receiving an exception with the message "Identifier doesn't match expected value (906)" as soon as I disable it. The registry key is documented on http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html and http://support.microsoft.com/kb/308339.

Unfortunately I do not have access to the registry on the computers where my application will be used, so I am looking for a way to do this without having to modify it. When I do Single Sign On over SPNEGO in Internet Explorer or Mozilla Firefox, they create a Service ticket in my ticket cache, so there definitely has to be a way to do this without setting the registry key. Does anyone have an idea how to do this in Java?

Thanks for your help, memminger

Update: I am giving up on this issue. The Windows registry key prevents the access to the Ticket (more exactly: the Subject) inside the Ticket cache. Java on Windows uses its own GSSAPI implementation, and I suppose that needs access to the Ticket to create a Service Ticket. The SSPI Windows API though has full access to the Ticket cache and can thus create Service tickets. This API is used by the web browsers, but it is not used by Java (according to http://java.sun.com/developer/technicalArticles/J2SE/security/#3). When I disable SSPI in Firefox after having accessed a web page once (so a service ticket has been created), I can still access the page, so maybe a command-line util would be sufficient that creates a service ticket using the SPPI API.

For us, this means now that we can either abandon Single Sign On (which is unacceptable for us) or that we do the authentification on the client side of our application (because we can only read out the username but not verify the ticket on the server), which is a major security risk. Another example of how stronger security constraints lead to bigger security holes because they become too complicated to use.

Arletha

Have you looked at OpenID as an alternative to Kerberos? – Glyptograph

I know OpenID and am using it for several web services. But in this case there is an existing infrastructure using Kerberos, and by the way I want to implement SSO for a non-web application, so I don't think OpenID would bring any benefit to the users. – Arletha

Answer 1

Forgive me if I am misunderstanding you problem, but...

The point of SSO type systems is that the client authenticates directly to the (separate) authentication server, and obtains a ticket from it. It then passes the ticket to the target server(s) it wants to use, each of which verify that the ticket is valid with the authentication server. If the ticket is validated, it can be assumed by the server that the client only obtained it by presenting the (trusted) Kerberos server with acceptable credentials.

Nowhere in the process, should any server authenticate on behalf of the client. In such a system, the only server that needs to know and validate the client's credentials is the authentication server - no other server need have access to this information. This way the client can authenticate for many servers with just one authentication exchange, and credentials are not put at risk by being stored on, or accessible to, multiple servers.

It sounds like your implementation is working just as it should - the authentication should occur on the client side of the application, and this is correct and not a security risk.

Glyptograph

That is true, the client gets a ticket from the Kerberos server by entering the credentials. In order to log on to a service, the client has to request a new ticket for that service from the Kerberos server, using the old ticket (what the kvno command from MIT Kerberos does). To create this new ticket, the client obviously needs access to the old ticket, and on Windows, only the native SSPI API has access to that old ticket, but the Java GSSAPI does not use that and thus hasn't (as long as you don't enable the registry key). So a solution would be a way to use the SSPI library in Java. – Arletha

Forgot to mention, the service obviously has to validate the ticket the client sent. This is not possible if the client cannot create a ticket to send to the server. The only thing we managed to do at the moment is to read out the Windows logon name on the client and send that to the server, but of course everyone can forge that. – Arletha

@Arletha disclaimer I don't know much about Kerberos, but you say: "So a solution would be a way to use the SSPI library in Java." Why don't you explore this further and create a native (JNA/JNI) wrapper on top of the windows api that your browser uses? – Antenatal

Answer 2

Have you tried setting sun.security.jgss.native in Java 6? Wouldn't SSPI be the "native" interface for windows?

Schapira

Windows wasn't a supported platform for this. I've opened #3467753 to find out if things have changed. – Salomon

I know this is a very old answer, but since Java 13 seting -Dsun.security.jgss.native=true is supported on Windows – Haerr

Answer 3

You can access the native SSPI API via JNA. See the WindowsAuthProviderImpl in WAFFLE or WindowsNegotiateScheme from the Apache HC library for an example.

Whyte

Answer 4

Native support for Windows SSPI was introduced into JDK 13 and later backported to JDK 11 too. You'll need to use at least Java 11.0.10. When the JDK's support for SSPI is used then there's no longer a need to fiddle with the allowtgtsessionkey registry key, nor any need to use JNA or Waffle.

You need to set

-Dsun.security.jgss.native=true

to make it work.

You can recognize if your JDK version for Windows has support for SSPI if it includes a file named sspi_bridge.dll in the bin directory.

Refs:

JDK-6722928

Penates