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

[Nico Williams]

On Tue, Mar 26, 2019 at 07:12:21AM +0800, Weijun Wang wrote:
> > On Mar 25, 2019, at 11:37 PM, Nico Williams <Nico.Williams at twosigma.com> wrote:
> >> But 1) Java GSS acceptor does not accept it and I don't want to break
> >> interop inside Java.
> > 
> > That's not breaking interop.  A Windows initiator and non-Windows
> > acceptor (and vice-versa) will still interop provided both have Kerberos
> > credentials.
> 
> But there needs another round of negotiation and you know Java might not be good at it.

As long as it doesn't crash it's good enough.  There's two ways to fail,
and that's OK.

> >> 2) No more permission check.
> > 
> > I don't understand (2).
> 
> Now that the ServicePermission check is skipped, some sort of
> NTLMPermission check will be needed.

IIRC that's too difficult.  It would be easier to map generic GSS names
to Kerberos names for use with ServicePermission.  The design of
ServicePermission was all wrong, it should always have dealt with GSS
names only, and Krb5Principal should never have been a thing because
GSSName should have been a (extend) Principal.

By making GSSName extend Principal we can begin to fix these issues.