Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup [v3]

2021-08-10 Thread Martin Balao
On Tue, 10 Aug 2021 16:16:39 GMT, Weijun Wang  wrote:

>> The TGS in "the TGS is the one" is clientSvcTicketEnc indeed. I admit that 
>> all these names are a bit confusing -but so it is the underlying protocol-. 
>> I'll take the 'user" suggestion and rename it to userSvcTicketEnc -in the 
>> hopes of suggesting some similarity between S4U2Proxy and S4U2Self and make 
>> it more clear-. Agree?
>
> Good! No more comment.

Great, thanks. I'll mark this as 'Resolved conversation' and proceed with the 
push (unless there is any other formality that blocks me)

-

PR: https://git.openjdk.java.net/jdk/pull/5036


Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup [v3]

2021-08-10 Thread Weijun Wang
On Tue, 10 Aug 2021 14:48:08 GMT, Martin Balao  wrote:

>> Not adding the type is OK, I said it's just to be a little clearer. I think 
>> you're right about the cname. It's always the one that actually sends the 
>> request.
>> 
>> What is "the TGS" (in "the TGS is the one")? `clientSvcTicketEnc`? BTW, is 
>> "client service ticket" a well known name? or we can name it 
>> "user"-something?
>
> The TGS in "the TGS is the one" is clientSvcTicketEnc indeed. I admit that 
> all these names are a bit confusing -but so it is the underlying protocol-. 
> I'll take the 'user" suggestion and rename it to userSvcTicketEnc -in the 
> hopes of suggesting some similarity between S4U2Proxy and S4U2Self and make 
> it more clear-. Agree?

Good! No more comment.

-

PR: https://git.openjdk.java.net/jdk/pull/5036


Re: RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup [v3]

2021-08-10 Thread Martin Balao
> I'd like to propose a fix for JDK-8270137 [1].
> 
> This bug is triggered when using a previously stored referral ticket (in the 
> Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral. 
> The mistakenly-used referral ticket matched the client and service names but 
> it was obtained as a result of a non-S4U2Proxy request. In fact, it was the 
> middle service that got it while trying to determine the backend service 
> realm in a previous S4U2Proxy communication. The mistakenly-used referral 
> ticket was not bind to the impersonated user (in other words, it was not 
> obtained attaching the user's TGS as part of a S4U2Proxy request) and, thus, 
> must not be used.
> 
> Even when one possible approach to fix this issue could be to be more 
> selective at the moment of getting referral tickets from the Cache (that is: 
> do not get anything from the Cache if it's for a S4U2Proxy request), I 
> decided to go one step further and enhance the Referrals Cache. With this 
> enhancement, we add more information to the stored referral tickets such as a 
> footprint of the TGS (in the case of S4U2Proxy requests) or the user 
> principal (in the case of S4U2Self requests). We now allow to store S4U2Proxy 
> and S4U2Self referrals tickets but those will be re-used only if there is a 
> perfect match of the TGS or user principal. As an example, if a middle 
> service tries to replicate the exact S4U2Self communication for exactly the 
> same user, cached referral tickets should be okay. With this enhancement, we 
> increase the use of the Cache and the performance (time, network resources, 
> etc.).
> 
> The ReferralsTest is enhanced to reflect these new scenarios and now uses 
> cached S4U2Proxy/S4U2Self referral tickets.
> 
> No regressions observed in jdk/sun/security/krb5.
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8270137

Martin Balao has updated the pull request incrementally with one additional 
commit since the last revision:

  clientSvcTicket* variables/parameters renamed to userSvcTicket* for clarity.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5036/files
  - new: https://git.openjdk.java.net/jdk/pull/5036/files/4cb4b3e0..3e6f2db7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5036&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5036&range=01-02

  Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5036.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5036/head:pull/5036

PR: https://git.openjdk.java.net/jdk/pull/5036