RFR 8005819: Support cross-realm MSSFU

[Weijun Wang]

This looks good to me.

There is one confusion. I understand that handleS4U2ProxyReferral needs an in/out creds argument, but for serviceCredsReferrals the additionalTickets argument should only be in, right? However in this method you've modified the content of it after calling handleS4U2ProxyReferral. This is not fatal because it won't have any effect higher than acquireS4U2proxyCreds, but it does introduce an in/out argument to the serviceCreds/serviceCredsReferrals methods.

Anyway, even if this is worth amending we can fix it after RDP1 with a different issue.

Thanks,
Max

> On Dec 12, 2019, at 3:36 AM, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Max,
> 
> Thanks for reviewing this proposal.
> 
> On 12/6/19 5:27 AM, Weijun Wang wrote:
> 
>> 1. Can we change the signature of handleS4U2ProxyReferral so that there is only one credsInOut?
>> 
>>   String handleS4U2ProxyReferral(Credentials asCreds,
>>        Credentials[] credsInOut, PrincipalName sname)
>> 
>> and call it with "new Credentials[] {creds, null}"?
>> 
>> Then you can clearly specify
>> 
>>  input: first referral TGT for S4U2proxy, null
>>  output: service's final referral TGT, client's final referral TGT
>> 
> 
> Yes, sure.
> 
>> 2. Can we add a S4U2Type argument in serviceCreds(options,...)? Then its callers can specify it directly and there is no need for this method to guess it out.
>> 
> 
> Yes, sure.
> 
> Webrev.04 has all of the above and better error handling when
> Config.DISABLE_REFERRALS is true:
> 
> * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.04/
> 
> Note: Webrev.03 was never publicly proposed. Contained "better error
> handling when Config.DISABLE_REFERRALS is true" part only.
> 
> Testing: no regressions found in jdk/sun/security/krb5. Did some
> additional regression testing in my internal environment.
> 
> Are we good to go?
> 
>> p.s. Something related but not for this enhancement. The getTGTforRealm method should not call Realm.getRealmsList() (i.e. use [capaths] in krb5.conf) when using referral. It should just follow the referral.
>> 
> 
> We can discuss this in the context of a different enhancement/fix. My
> understanding is that even though Realm.getRealmsList is called
> (potentially returning a path with different realms based on capath or
> the domains hierarchy), RFC 6806 referrals may be just followed up at
> any point of the path queries if available. This means that there is a
> chance that one or more realms in the path returned by getRealmsList are
> ignored.
> 
> Regards,
> Martin.-
>