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

[Nico Williams]

On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote:
> > On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> >>> There's a few reasons:
> >>> 
> >>> - NTLM doesn't have an OID, at least as I remember
> >>> 
> >>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/
> >>>   regards to the ServicePermission stuff
> >> 
> >> Yes, it needs to check a permission if the token is SPNEGO and
> >> internally it's Kerberos. I also believe the HTTP Negotiate code
> >> there is probably not good at dealing with a Negotiate dialog with
> >> 2 rounds. The first problem should be easy to fix, I'll see if the
> >> 2nd is complicated.

I expect lots of implementations of HTTP/Negotiate to not support more
than one round trip.  However, if a client and server lack credentials
for a common mechanism, authentication will fail or not even start, and
if they do have credentials for a common mechanism but one or both
cannot handle more than one round trip, they'll fail.  Either way they
fail, so what's the problem?  Ignoring for a moment NTLM's weakness,
adding support for it adds ways to win, not ways to fail.

> It works. Java's (old) HTTPConnection sends an NTLM token to IIS and
> after 4 messages I see 200 OK.
> 
> 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.

> 2) No more permission check.

I don't understand (2).

> Not going to do it this time. Later I might ask networking how
> transparent NTLM works and if they needs any permission checking or
> other settings I can probably follow.

Of course it needs permission checking, except that in a world without
applets that's a bit pointless.

Nico
--