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