JGSS-API supporting SSPI on Windows

[Weijun Wang]

On 04/10/2017 05:03 PM, Chan, Sunny wrote:
> So just to clarify my understanding, this situation is similar to how
> Swing and AWT related to each other - Traditional Delegation for
> GSS-API is that most processing is done in Java code, so it will need
> access to Session Key in order to decrypt the ticket directly and
> communicate with the Kerberos server. While Microsoft's Constrained
> delegation is like AWT where all the authentication operations are
> delegated to Windows and JGSS is merely a wrapper to those API?

Swing and AWT are all Java SE APIs.

Java SE has only GSS-API. SSPI is a Windows native Win32 API. What I 
said implementing SSPI is not precise, it's actually creating another 
GSS-API provider that calls SSPI functions on Windows. You can imagine 
this as a bridge or a wrapper.

>
> Let's assume if we implement a Constrained Delegation client just for
> Windows and only turned on via a security property, would that be
> acceptable solution?

It's implementing a SSPI wrapper just for Windows, and yes it can be 
turned on via a system property.

But as I said, the 2 APIs do not have an exact 1-1 mapping (on 
delegation). One might say the new provider and the old one support 
different feature sets.

--Weijun


>
> -----Original Message----- From: Weijun Wang
> [mailto:weijun.wang at oracle.com] Sent: 10 April 2017 16:05 To: Chan,
> Sunny [Tech]; 'security-dev at openjdk.java.net' Subject: Re: JGSS-API
> supporting SSPI on Windows
>
> Hi Sunny
>
> If I understand correctly, the major difference between SSPI and
> GSS-API is delegation. In GSS-API, the client initiates the
> delegation by forwarding a credential to the intermediate server so
> the latter can use this delegated credential to access a backend
> server on behalf of the client. In SSPI, the intermediate server
> itself asks the KDC (Active Directory Domain Server) whether it can
> impersonate a client to access the backend server. Microsoft calls it
> constrained delegation.
>
> Java supports both traditional delegation and constrained delegation,
> but if we add SSPI as a JGSS-API provider, it can only support
> constrained delegation.
>
> Implementing SSPI requires quite a lot of coding, including both Java
> and C codes. There will also be quite some testing work.
>
> A partial solution is to only support Windows' native service ticket
> retrieval. This means we can bypass the TGT (where AllowTGTSessionKey
> is needed) and acquire a service ticket directly. After this ticket
> is available, we still use the current Java codes to access the
> service. This solution also won't support traditional delegation.
>
> There is no decision yet.
>
> Any contribution is welcomed.
>
> Thanks Weijun
>
> On 04/10/2017 12:46 PM, Chan, Sunny wrote:
>> Hello,
>>
>> Windows has changed the default such that the session key is not
>> included in TGT, and for Windows SSO to work with Java
>> implementation out of the box it will required AllowTGTSessionKey
>> options to be added to the registry. However, this options has
>> associated security risk as it expose the session key to all apps,
>> and it also means that right now Kerberos SSO in Windows does not
>> work out of the box
>>
>> Looking at the Java bug database, there has been suggestion that
>> Java could support SSPI as a JGSS-API provided which would allow
>> Java to work out of the box without the AllowTGTSessionKey
>> options.
>> (https://urldefense.proofpoint.com/v2/url?u=http-3A__bugs.java.com_bug
>>
>>
database_view-5Fbug.do-3Fbug-5Fid-3D6722928&d=DgID-g&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E&m=tVm1uVTgadiBY_OTgDIvULQDi4i4YBQTTE8cwwJhW9M&s=U0di20MO97JRZDulQs-1MtqrEE4yo9nygL-WvEBkZjM&e= 
). However, in the evaluation it says:
>>
>> Might support it, although I hope most of the functions of Windows
>>  SSPI can also be supported by pure Java. Interop is important
>> between different platforms
>>
>> I would like to understand what is the "Interop" concern here? Have
>> we evaluated how much work need to do to support it (so that we can
>>  consider contributing the implementation)?
>>
>> *Sunny Chan* Executive Director Technology
>>
>> *Goldman Sachs (Asia) L.L.C.*| 39th Floor | The Center | 99 Queens
>>  Road Central | Hong Kong
>>
>> Email:  sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978
>> 0633