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