Can the 'default native GSS-API on Windows' in Java 12 support SSO with JAAS by using the Krb5 principal of the user executing the JVM?

Question

Vanilla Krb5LoginModule is working, prompting for creds

In my modest usage of JAAS -> JGSS -> Kerberos -> Windows thus far, I have set up a Krb5LoginModule When I do:

Subject.doAs(
    new LoginContext(...)).login(),  // subject
    new MyPrivilegedAction()         // action
)

... I am prompted for credentials, and the action is successful.

Using TGT Session Key hack, can avoid prompt for creds

If I also add useTicketCache=true to the login module, and if I put up with the security hazards of setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\AllowTgtSessionKey=1 and don't use Windows 10 Credential Guard, then the action is successful without a prompt for credentials.

Java 12 gives us a default native GSS-API lib even on Windows

Java 11.0.10 introduced the possibility of using a native GSS-API implementation on Windows but did not provide a default implementation. Java 12 added a native implementation of GSS-API which bridged to the Windows SSPI. This avoids the need for the risky AllowTGTSessionKey.

Using native GSS-API works too, prompting for creds

On Java 15.0.2 (both Oracle and OpenJDK) on Windows, despite the docs) still (now incorrectly) claiming, "There is no well-known native GSS-API library on Windows", I can:

• Omit java.security.krb5.realm and java.security.krb5.kd system properties (which I use in lieu of a full-blown kr5.conf, since my AD environment is simple); and
• merely specify sun.security.jgss.native=true.

... and the action prompts for credentials, but is successful.

But native always prompts for credentials

Can I expect when using sun.security.jgss.native=true (on JDK 15.0.2 on Windows) that JAAS -> JGSS -> Kerberos -> Windows will attempt to use the Windows LSASS via the SSPI to obtain the credentials of the user executing the JVM? Or is this not something that the native GSS-API -> SSPI library facilitates? Information is thin on the ground!

Elayneelazaro

When the JAAS CallbackHandler is invoked using native, it does correctly suggest my username ... it just isn't fetching my password from Windows the way it does when using pure-Java with the AllowTGTSessionKey hack. – Elayneelazaro

I feel like there are probably 4 people in the world who could answer this, and they're all really busy. – Elayneelazaro

Out of curiosity: did you tweak the default JAAS configuration in your tests? and did you check what JAAS makes of its config via -Djava.security.debug=gssloginconfig,configfile,configparser,logincontext or sthg similar? – Ditter

Thanks @SamsonScharfrichter I can confirm the intended file is being parsed. I think I will chug along with the tutorials and try to make a minimal repro with just GSS-API and leave JAAS out of it. Will update the Qn when I have more info. – Elayneelazaro

Any news on this topic? – Charo

@Charo I did not chase it to the end of the line yet. For me, the bigger picture was to allow my Java app-server to transparently propagate the identity of the user-agent all the way to the DBMS. But the whole attention of the industry is on OAuth now, and not on this scenario. I will take another look at things when JDK17 ships (not too long now!) – Elayneelazaro