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

Weijun Wang weijun.wang at oracle.com
Tue Apr 16 07:43:50 UTC 2019


Hi Michael,

Sorry about the late reply. I've just posted a new webrev at

   https://cr.openjdk.java.net/~weijun/6722928/webrev.06

Below are my replies to some of your questions.

> 
>>> * Why do you redefine SEC_SUCCESS macro from sspi.h?
>> 
>> Oops, I didn't realized it's a redefinition. I'll change the name. Or, do you know if my definition is too different from the original one?
> 
> Here is sample code from Microsoft:
> https://docs.microsoft.com/en-us/windows/desktop/secauthn/using-sspi-with-a-windows-sockets-server
> I would not even bother adding it myself. What is the reason for this?

My redefinition is almost the same, it also set the minor status to be the error number.

> 
>>> * Don't change the semantics of KRB5_TRACE. MIT Kerberos users are used to it, either write to the supplied file path or use a different name.
>> 
>> How about only support "set KRB5_TRACE=/dev/stdout" now and be silent otherwise?
> 
> Hmm, I'd still insist on somthing else, it just doesn't feel right.
> Maybe JGSS_KRB5_TRACE with fprintf(stderr,...)? And later one you can
> imrpove/replace it?

I'll implement it, using the fopen/fprintf functions I learnt 30 years ago.

> 
>>> * getTGTEndTime(): Wouldn't it be easier to call AcquireCredentialsHandle() and inspect ptsExpiry field?
>> 
>> The field has a strange value. See
>> 
>>    https://stackoverflow.com/questions/11028798/how-do-i-interpret-the-expiry-returned-by-acquirecredentialshandle-kerberos
> 
> 
> Please see the third comment, it is from me. I have exprienced the same.
> To be frank, I would accept it as-is because that is the way LSA works.
> the way you do it now is as if you would use the internal KRB5 functions
> from MIT Kerberos. It doesn't feel right.

I'll remove this function and finally it will be GSSCredential.INDEFINITE_LIFETIME.

> 
>>> ** What is the purpose of this function? It will not work reliably if you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN HTTP/travel.siemens.com
>> 
>> Java does not support realm-less service name so I'll have to add one to make ServicePermission check working. In your case, is this a stopper? Can windows find out the correct realm even if I provide a false one? Or maybe I can give Java back the (possibly wrong) full name and remove it when passing to the windows API.
> 
> Wait a second, don't you deduce the realm from the krb5.conf? I have
> been using JGSS for the past 10 years now and since referrals don't
> really work, I have used the domain_realm setion to solve that problem,
> e.g, blnn719x.ww004.siemens.net = AD001.SIEMENS.NET. If you are talking
> about domainbased services ldap at dc1.ad001.siemens.net@ad001.siemens.net
> Windows does support them, but there is no OID for, it uses UKNOWN or
> hostbased with three components.
> 
> Windows does *not* require the realm with the SPN, unless for the
> usecase about specified, it will apply proper routing by itself if the
> namespaces are properly configured. We moved two years ago from one
> forest to another with a bidirectional trust and everything just work
> with referrals with MIT Kerberos and MS Kerberos.
> 
> Maybe you need to provide an example to me to understand the JGSS
> shortcomings.

No, there will be no krb5.conf here. The new library is meant to work with no other additional settings.

This function is used by export(). In MIT krb5, WELLKNOWN:ORG.H5L.REFERALS-REALM is added, but Java does not like the ":" there.

Thanks,
Max




More information about the security-dev mailing list