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