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.
>
> * 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.
> * 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?
>
> --
>
> 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
> "clie...@realm-1.com". This Subject has 2 KerberosTicket private
> credentials:
>
> 1) TGT cname: client1-canoni...@realm-1.com, clientAlias:
> clie...@realm-1.com
>
> 2) TGT cname: clie...@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
> "clie...@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 (clie...@realm-1.com) matches the ticket cname
> (clie...@realm-1.com).
>
> If we do "clientPrincipal = ticket.getClient().getName()" in line 214,
> clientPrincipal would be client1-canoni...@realm-1.com and we will not
> get ticket #2 (whose cname is clie...@realm-1.com).
>
> Why did I assume that ticket #2 has a "clie...@realm-1.com" cname and
> not something different? cname may be anything BUT if it were different
> than the subject principal (clie...@realm-1.com), then it must have an
> alias and we will get it through the alias.
OK, this is how I understand it.
With the current implementation, yes it always has an alias.
Or, if CANONICALIZE is not set (who knows why), then there will be no alias and
the alias is the name.
If so, then you are correct.
Thanks,
Max
>
> 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.-
