RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found

[Weijun Wang]

There is still a kerberosTicketSetClientAlias() call in Krb5LoginModule.java. Otherwise looks fine.

I'll run some internal test now.

Thanks,
Max

> On Jul 17, 2019, at 2:58 PM, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Max,
> 
> Webrev.02 is ready:
> http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.02/
> 
> On 7/17/19 12:23 AM, Weijun Wang wrote:
>> Krb5Context.java and Krb5LoginModule.java:
>> 
>> There is no need to set the aliases, already done inside Krb5Util.credsToTicket(serviceCreds). The case in Krb5LoginModule.java is more complicated, due to your change in webrev.01. See below.
>> 
> 
> Duplicated alias set removed from Krb5Context.java. Thanks.
> 
> In regards to Krb5LoginModule.java, I made a mistake when generating
> Webrev.01 (my idea was to set a client alias equal to "principal").
> However, I decided to remove it for Webrev.02. When we retrieve the
> ticket from the cache, we use either "principal" or null (but then we
> assign "principal" to whatever cname the ticket has). As a result, the
> ticket cname will match "principal" and setting it as an alias adds
> nothing. Sorry for the noise here.
> 
>>> 
>>> * Fixed a bug in referral TGTs Credentials (no server alias should be
>>> there)
>>> * See this change in KrbTgsRep.java
>> 
>> But this is not harmful, right? The referral TGTs are not stored in a Subject and its alias is not used.
> 
> Right. Not harmful but not correct. Found it a bit confusing when
> debugging. As you said, referral TGTs are not stored.
> 
>> 
>>> * Fixed a bug in Krb5LoginModule
>>> * If we get a TGT from a ccache, that TGT will not have client alias
>>> and its cname may be different than the subject principal. If we commit
>>> this ticket in the subject private credentials, we will not find it.
>>>  * My proposal is to force the subject principal as an alias if: cname
>>> differs from the subject principal AND there is no client alias.
>>> * See this change in Krb5LoginModule.java
>> 
>> KerberosPrincipal kClient = new KerberosPrincipal(
>>        cred.getClient().getName());
>> if (!princSet.contains(kClient)) {
>>    kClientAlias = kClient;
>> }
>> 
>> Looks like this ticket's name and alias will be the same? Is this useful?
>> 
> 
> Removed. See above.
> 
>> 
>> Or, if CANONICALIZE is not set (who knows why), then there will be no alias and the alias is the name.
> 
> Yes, if we send no CANONICALIZE (i.e.: because of the fallback scheme),
> we will have no client alias but the ticket cname will then be equal to
> the subject (kerberos) principal.
> 
> Regression testing in jdk/sun/security/krb5 category passed.
> 
> Are we good to go with Webrev.02?
> 
> Thanks,
> Martin.-