You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The PR avoids creating a real client session for TE when it is possible. If the client session is missing a new transient session is created and used (same notes than realm online session). The difference is that the sid claim in this case is set to the token (the session exists but the token is transient, there is no real client session for this client). This is only done if the TE requested type is not the refresh token which needs a persistent session.
When I tested the PR and added setTimeOffset(1) to the StandardTokenExchangeV2Test line 251 (right before calling introspection endpoint), then the test failed. The introspection-endpoint fails due the userSession is created before token. Is it maybe that when creating "transient user session", it would also receive the startup time from the original session? Or startup time would be checked against the original persistent session?
Is it possible to also add the test check, which will logout the original session (or remove the session by admin REST API) and then checks that it is not possible to introspect the exhcnaged token anymore? IMO it will work with the current PR, but testing could be good.
Will this work when the exchanged token is used to call account/admin REST API? Or when newly exchanged token is used as subject_token for the further token exchange? Some automated test might be also good. I have some doubts as AFAIK those unfortunately use different methods to lookup/verify user sessions ( AuthenticationManager.verifyIdentityToken ). If you prefer, this can be addressed as a follow-up to this PR. BTW. I was thinking about some consolidation of this and make sure that various Keycloak endpoints use same code when lookup/validate user session, offline session etc, but refactoring is rather out of scope of this PR...
@mposolda Good catch! I didn't realize the started was set to current time when creating the transient session. I have worked in the three points:
Done and modified the test to run the test with offset.
Modified the test to delete the session and check it fails as expected.
Added two more tests for admin/account API. I have not done with a token obtained by a first TE request (I have just seen it now) but I can add if you think it is important. I have just modified the AuthenticationManager to make it work with teh new transient tokens. Maybe we need to re-think this and use the same code in both parts. But I would do that in a follow-up.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #37117
The PR avoids creating a real client session for TE when it is possible. If the client session is missing a new transient session is created and used (same notes than realm online session). The difference is that the
sidclaim in this case is set to the token (the session exists but the token is transient, there is no real client session for this client). This is only done if the TE requested type is not the refresh token which needs a persistent session.