Just to add another aspect to the discussion, there are at least 3 DLLs out there which implement this functionality (Microsoft’s JDBC driver, jTDS driver and Waffle) + commercial solutions as we have heared. All of them are used to allow authenticating the current user against services (mostly TDS (SQL Server), SMB and http.
So having a GSS provider, even when it is not used by default would hugely benefit a lot of projects (especially if it does not require JAAS wrapping and will support Windows 10 with Credential Guard for NTLM and Kerberos) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev <security-dev-boun...@openjdk.java.net> im Auftrag von Nico Williams <nico.willi...@twosigma.com> Gesendet: Montag, März 25, 2019 6:38 PM An: Weijun Wang Cc: security-dev@openjdk.java.net Betreff: Re: RFR 6722928: Support SSPI as a native GSS-API provider 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 --
