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

Weijun Wang weijun.wang at oracle.com
Mon Mar 25 03:17:17 UTC 2019



> On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> 
> Am 2019-03-23 um 00:21 schrieb Weijun Wang:
>> 
>> 
>>> On Mar 22, 2019, at 11:28 PM, Nico Williams <Nico.Williams at twosigma.com> wrote:
>>> 
>>> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
>>>> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
>>>> it is intended to work. Means less code you have to maintain
>>> 
>>> 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.

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. 2) No more permission check.

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.

I'll work on other comments from you.

--Max

> 
> Reminds me of https://issues.apache.org/jira/browse/HTTPCLIENT-1625...






More information about the security-dev mailing list