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

[Martin Balao]

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