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?
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? -----Original Message----- From: Weijun Wang [mailto:weijun.w...@oracle.com] Sent: 10 April 2017 16:05 To: Chan, Sunny [Tech]; 'security-dev@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.c...@gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633
