JGSS Enhancements (contribution by Two Sigma Open Source)
Nico Williams
Nico.Williams at twosigma.com
Tue Oct 2 23:04:33 UTC 2018
Hello,
We at Two Sigma Open Source, LLC, would like to make a contribution, to
the OpenJDK, of various enhancements to the the OpenJDK's JGSS stack,
specifically for better interoperability with native C GSS-API
implementations. As I understand it, Two Sigma Open Source, LLC, has
signed the OCA already.
You can find our git clone of the OpenJDK, based on the AdoptOpenJDK
github clone of the OpenJDK, at:
https://github.com/twosigma/OpenJDK
The relevant branches are:
- ts-jgss-jdk12 -> our patches based on the JDK 12 master branch
- ts-jgss-jdk11 -> our patches based on the JDK 11 master branch
Summary of our changes:
1) Make GSSName extend Principal
This is necessary in order for JGSS applications to be able to use
JAAS when also using the native C GSS-API JNI wrapper.
A GSS-API name object really is a principal name, therefore it is
natural that GSSName must extend Principal.
2) Add a GssLoginModule to go with Krb5LoginModule.
Krb5LoginModule is for when using the native Java implementation of
Kerberos V5.
GssLoginModule is for when using JGSS with the native C GSS-API JNI
wrapper.
In principle we could have just one module for both, but we have not
done this work yet. In practice both modules can be used in any
given JAAS configuration by, e.g., specifying both as optional.
3) Add JGSS functionality required to have GssLoginModule on par with
Krb5LoginModule.
This means adding methods for acquiring a GSSCredentialElement with a
password.
4) Bug fixes.
We have fixes for a number of bugs, including ones where not
disposing early of JNI resources meant accumulating heap pressure
that the JVM / GC is not aware of. GSS-API native objects ("security
context", "credential handles", "names") can be sizeable, but as far
as the JVM is concerned they are icebergs: the JVM sees only the tiny
amount floating above the surface, but underneath is a much larger
object.
5) Commentary, including suggestions for how to generalize
ServicePermission to be applicable to non-Kerberos principals, such
as by either mapping names from ServicePermission grants to
non-Kerberos principal names, or by extending ServicePermission grant
syntax to allow other name forms than Kerberos.
We'd like to know how to proceed to get this contribution adopted
upstream. I am aware of
http://cr.openjdk.java.net/~chegar/docs/sandbox.html
and will be moving to create a sandbox and webrev for our contribution
soon.
Thanks,
Nico
--
More information about the security-dev
mailing list