Support for using the credential from platform GSS integration for Kerberos

Driver version or jar name

Tested with 6.3.6.jre8-preview

SQL Server version

Tested with 12.0.5207

Client operating system

Tested with RHEL (3.10.0-693.5.2.el7.x86_64)

Java/JVM version

>java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Table schema

N/A

Problem description

I was trying to use the platform GSS integration (as described in “Native platform GSS integration” at https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/jgss-features.html), and noticed that the code in com.microsoft.sqlserver.jdbc.KerbAuthentication#intAuthInit assumes the use of only JAAS. It also has support for impersonated credentials, but not for the use of the default initiator principal as defined in org.ietf.jgss.GSSManager#createContext(org.ietf.jgss.GSSName, org.ietf.jgss.Oid, org.ietf.jgss.GSSCredential, int)

If we define a means for allowing the use of this default principal (from the platform GSS), we can let the GSSManager create the appropriate GSSCredential for us.

Expected behavior and actual behavior

Expected behavior

When the sun.security.jgss.native system property is set to true, the platform GSS implementation should be used for GSSCredential creation and JAAS configuration files are not necessary.

Actual behavior

When the sun.security.jgss.native system property is set to true, mssql-jdbc doesn’t use the platform GSS implementation, but rather still goes down the JAAS path and expects credentials to be provided.

Repro code

Try with any MS-SQL server that uses Kerberos for authentication and whose client attempts to use the platform GSS integration by setting -Dsun.security.jgss.native=true. I have added a sample project in https://github.com/kilokahn/mssql-jdbc/blob/default-principal-usage-java-kerberos/src/samples/platform-gss/src/main/java/PlatformGSS.java

Possible fix and contributing code

IMO, there are 2 options:

1. We can try to model the platform GSS authentication as a new AuthenticationScheme and introduce an implementation of com.microsoft.sqlserver.jdbc.SSPIAuthentication that specifically addresses this scheme where the GSSManager delegates the creation of the GSSCredential to the platform (host)
2. Introduce an additional flag with the JavaKerberos AuthenticationScheme (say useDefaultPrincipal) that will be used to have the GSSManager delegates the creation of the GSSCredential to the platform (host). EDIT: in hindsight the flag is better named as usePlatformGssCredential?

I took a shot at approach 2 here. Can you please see if this makes sense? Thanks!

[cheenamalhotra]

Hi @kilokahn

We appreciate your contribution for introducing platform gss for Kerberos authentication. We are currently reviewing the PR and will come back to you soon!

Thanks!

[kilokahn]

Thanks for your patience (and apologies for misinterpreting your directions in creating the kerberos ticket) @ulvii 🙂

As per the steps above, when we don’t set the sun.security.jgss.native to true, the JDK Kerberos implementation (in package sun.security.jgss.krb5) will be used, which is not what I am looking for. Rather I am looking for the JGSS API (in package sun.security.jgss) to delegate the credential fetch implementation to the platform kerberos implementation (like MIT Kerberos, etc. which might be installed on the RHEL box, and hence native). There are subtle differences between the two implementations (like referrals mechanism for multiple realms, support for different ciphers, etc.) which cause the ccaches to not be trivially interoperable.

The point was to be able to set the sun.security.jgss.native to true, and have no use of the JDK Kerberos implementation whatsoever. I will try to convert the changes on https://github.com/kilokahn/mssql-jdbc/tree/default-principal-usage-java-kerberos into a PR.

Again, I appreciate the help you are providing here 👍