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...@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 --
