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

[Martin Balao]

Hi Max,

Thanks for your feedback.

Here we have webrev.01:
http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.01/

I've done the following changes:

 * Extended ReferralsTest to test credentials delegation (through
CredentialsUtil::acquireS4U2proxyCreds)
  * See this change in ReferralsTest.java

 * KDC enhanced to allow referrals when CNAME_IN_ADDL_TKT flag is set
  * ReferralsTest uses this new feature
  * See this change in KDC.java

 * Fixed a bug in referral TGTs Credentials (no server alias should be
there)
  * See this change in KrbTgsRep.java

 * Fixed a bug in ReferralsCache
  * cache was not per client principal (we were returning referral
tickets issued for different clients)
   * See this change in CredentialsUtil.java and ReferralsCache.java

 * 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

--

In regards to SubjectComber::findAux, I understand your concerns but
cannot figure out how that situation would be possible. I'll try to
explain my reasoning as detailed as possible and why I believe the
client alias (if there is one) is a better choice there.

Let's say we have a Subject called "client1", whose principal is
"client1 at REALM-1.COM". This Subject has 2 KerberosTicket private
credentials:

 1) TGT cname: client1-canonical at REALM-1.COM, clientAlias:
client1 at REALM-1.COM

 2) TGT cname: client1 at REALM-1.COM, clientAlias: null

We want to retrieve all tickets for this Subject so we call
SubjectComber::find with clientPrincipal == null.

As you said, ticket #1 is retrieved after check in line 198
(clientPrincipal == null). Now, clientPrincipal will be equal to
"client1 at REALM-1.COM" because of the assignment in line 214
(clientPrincipal = clientAlias.getName();).

In the second iteration, we will get the ticket #2 because
clientPrincipal (client1 at REALM-1.COM) matches the ticket cname
(client1 at REALM-1.COM).

If we do "clientPrincipal = ticket.getClient().getName()" in line 214,
clientPrincipal would be client1-canonical at REALM-1.COM and we will not
get ticket #2 (whose cname is client1 at REALM-1.COM).

Why did I assume that ticket #2 has a "client1 at REALM-1.COM" cname and
not something different? cname may be anything BUT if it were different
than the subject principal (client1 at REALM-1.COM), then it must have an
alias and we will get it through the alias.

My reasoning is that we should track all the tickets to the subject
principal (either because their cname matches the subject principal or
because we set an alias).

If someone forces a ticket without an alias and without a cname that
matches the subject principal, we will not retrieve it... but that's
because the invariant is broken. We may also broke the invariant in the
same way by adding a ticket with a cname different than
ticket.getClient().getName().

Thanks,
Martin.-