RFR 8005819: Support cross-realm MSSFU
Martin Balao
mbalao at redhat.com
Wed Dec 11 19:36:19 UTC 2019
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.-
More information about the security-dev
mailing list