Hi Martin,
There is only one place I don't quite understand.
In SubjectComber::findAux, you have
151 while (iterator.hasNext()) {
152 Object obj = iterator.next();
153 if (obj instanceof KerberosTicket) {
155 KerberosTicket ticket = (KerberosTicket)obj;
164 if (!ticket.isCurrent()) {
...
186 } else {
...
195 KerberosPrincipal clientAlias =
KerberosSecrets
196
.getJavaxSecurityAuthKerberosAccess()
197
.kerberosTicketGetClientAlias(ticket);
198 if (clientPrincipal == null ||
199 clientPrincipal.equals(
200 ticket.getClient().getName())
||
201 (clientAlias != null &&
202 clientPrincipal.equals(
203
clientAlias.getName()))) {
...
207 // Record names so that
tickets will
208 // all belong to same
principals
209 if (clientPrincipal == null) {
210 if (clientAlias == null) {
211 clientPrincipal =
212
ticket.getClient().getName();
213 } else {
214 clientPrincipal =
215
clientAlias.getName();
216 }
217 }
...
227
answer.add(credClass.cast(ticket));
228 }
229 }
230 }
231 }
232 }
233 }
Suppose we have 2 tickets:
client1(clientAlias1) -> ...
client1 -> ... // I don't know why this one has no alias
and clientPrincipal is null at the beginning.
Now, when the 1st ticket is checked, the if check on lines 198-203 will
succeed, and clientPrincipal is assigned clientAlias1 on line 214. Next, when
the 2nd ticket is checked, because it has no alias and client1 !=
clientPrincipal (now clientAlias1), it will not be added. Is this intended?
Why not simply assign ticket.getClient().getName() to clientPrincipal?
Thanks,
Max
> On Jul 16, 2019, at 8:47 AM, Martin Balao <mba...@redhat.com> wrote:
>
> Hi,
>
> I'd like to propose the following fix for JDK-8227437 [1] (*):
>
> * http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.00/
>
> JDK-8227437 bug appeared after the OpenJDK Kerberos client supported
> RFC-6806 [2].
>
> When requesting a TGT (ticket-granting-ticket), there may be client name
> canonicalization and/or realm referrals. When requesting a TGS
> (ticket-granting-service), there may be realm referrals. As a result,
> the client or service names we use to request a ticket may be different
> than those we get in the returned ticket. I.e.: we may use the subject
> principal "subj...@realm-1.com" as a client name to request a TGT and
> get a ticket whose client name is "subject-canoni...@realm-2.com".
>
> Even though the ticket credentials belong to the subject, we are unable
> to locate them based on the client or service names when there is a
> change. In the previous example, we will use "subj...@realm-1.com"
> subject principal as a client name to find the ticket but the actual
> ticket has a "subject-canoni...@realm-2.com" client name.
>
> To fix this problem, we now save the original client and service names
> as "alias" fields in Credentials and KerberosTicket objects (if there is
> a change). This allows to find subject credentials properly.
>
> Note: client and service alias information is not populated (saved or
> retrieved) across credentials caches: file-based-caches [3][4], Windows
> native cache or macOS native cache. As a result, the client name must
> match the subject principal for the credential to be found (see
> Credentials::acquireTGTFromCache). If the credential is not found, a
> request to the KDC may be issued.
>
> Testing:
>
> * ReferralsTest extended to cover this bug
>
> * Regression testing on jdk/sun/security/krb5 passed
>
> * Tested in my local Windows 2016 referrals environment
>
> Look forward to your comments.
>
> Thanks,
> Martin.-
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8227437
> [2] - https://bugs.openjdk.java.net/browse/JDK-8215032
> [3] - https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html
> [4] -
> https://web.mit.edu/kerberos/krb5-devel/doc/formats/ccache_file_format.html
>
> (*) - we have worked together with Max (@weijun) during the last week to
> come up with this version.
