RFR 6722928: Support SSPI as a native GSS-API provider

Nico Williams Nico.Williams at twosigma.com
Wed Nov 28 17:55:51 UTC 2018


On Tue, Nov 20, 2018 at 09:56:36AM +0800, Weijun Wang wrote:
> Please take a review at
> 
>    https://cr.openjdk.java.net/~weijun/6722928/webrev.01/
> 
> We ported [1] the native GSS bridge to Windows in JDK 11, but user still have
> to download and install a native GSS-API library. This code change provides a
> native GSS-API library inside JDK that can be used without setting the
> "sun.security.jgss.lib" system property. It is based on Windows SSPI and now
> only supports the client side using the default credentials.
> 
> No regression tests included. A Windows Active Directory server is needed.

This is my initial round of comments, and it's mostly high-level:

 - Right now this looks very basic, and you won't get support for any
   mechanism other than Kerberos.  That's fine though, as NTLM is dead,
   you're willing to implement SPNEGO yourself, and there are no other
   GSS mechs on Windows at this time (so far as I know).

 - You're constructing SPNEGO tokens yourself.  I'll have to review that
   very carefully.

   It would be better to let Windows provide SPNEGO though...

 - I've checked the DER-encoded OID constants.  They are correct.

 - The name type OID for GSS_KRB5_NT_PRINCIPAL_NAME is not implemented but is
   used elsewhere (e.g., in one GSSNameElement constructor).  Look for
   GSSUtil.NT_GSS_KRB5_PRINCIPAL.

 - gss_canonicalize_name() is not fully implemented.  This will be noticeable
   to callers of GSSNameElement's getKrbName().  In particular, permissions
   checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly
   in NativeGSSContext).

   At minimum you absolutely must parse generic GSS name type names into
   Kerberos-style names (e.g., service at hostname -> service/hostname@).

   When an MN is displayed, you need to output the Kerberos-style name.

   (For those following along, "MN" means "mechanism name", which means
   a GSSName / gss_name_t instance which is "canonical" and whose
   display form will be mechanism-specific.  gss_canonicalize_name() is
   supposed to output a "canonical" version of its input.)

   You'll also have to determine a realm for the parsed principal names.

   You won't need a realm for services.  Use an empty realm name for
   services -- that's the Heimdal/MIT (and Solaris) convention for when
   you're willing to rely on KDC referrals.

   (I would also urge you to NOT attempt any DNS canonicalization of
   hostnames.  Let's not further spread that mistake.)

   For user principals it's trickier, and I think you might need some notion of
   default realm, but a) maybe you can get away with an empty realm here on
   Windows, b) I'm not sure where you'd a default realm on Windows.

   What we do to determine the default realm for user names in our
   patched version of Martin Rex's GSS->SSPI bridge is call
   AcquireCredentialsHandle() or QueryCredentialsAttributesW() to
   get/query the default credential and get its name, and from that the
   realm, and we use that as the default realm.

   I'll have to look and see how we handle host-based service names
   (Martin's original code has a domain_realm table in the registry, but
   we removed all of that and rely on referrals instead.)

 - If you can get Legal approval for including / distributing a fork of
   Martin Rex's bridge, you'll get all of the above functionality and
   also acceptor functionality.

Nico
-- 



More information about the security-dev mailing list