-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Made adapters compatible with KC23 "iss" parameter change #23583
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Passing run #9194 ↗︎Details:
Review all test suite changes for PR #23583 ↗︎ |
|||||||||||||||
ghost
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unreported flaky test detected, please review
Unreported flaky test detectedIf the below flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.admin.concurrency.ConcurrencyTest#createRemoveClientorg.keycloak.testsuite.admin.concurrency.ConcurrencyTest#createClientorg.keycloak.testsuite.forms.VerifyProfileTest#testAttributeRequiredForDefaultScopeKeycloak CI - Forms IT (chrome) |
|
Could you please add a link to the issue/PR we are backporting from upstream? I'm also not following these changes because the change you are referring to is actually adding the What we actually need to implement is https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-23#section-4.4.2.1. I'm also not sure about changes in Java adapters as they are deprecated and they should work fine with the latest Keycloak releases. For this particular case, there is a compatibility mode setting at the client settings that allows you to remove this parameter from responses if you have issues with it. |
|
Hi @pedroigor, I'll update the description with the Issue and a better description of what I'm trying to do. I'm only wanting to backport the ability for the adapters to handle receiving the "iss" parameter to allow for an easier transition to this change in KC23. |
|
@pedroigor - To add more background here - we're looking to make the KC22 adapters "forward compatible" with the change coming in KC23, we're not looking to backport entire functionality of RFC 9027 to KC22. This is to solve some logistical issues with making a shift from prior Keycloak versions to something that will work with KC23 without significant problems. If one were to use even the KC22 versions of KeycloakJS or the Java based Keycloak adapters (which I do understand they're deprecated) with nightly / KC23, those clients will not function correctly. The adapter code for KC22 and prior appends the 'iss' param back to the redirect URI used in the code to token exchange, hence it will not match the original value supplied during the initial auth request. The KeycloakJS change is a little more nuance and only breaks in some instances, but still has an impact. So that means every Keycloak administrator must ensure their clients are either
This is certainly no small chore in a largely integrated system with hundreds of OIDC clients. I think additionally, we are uniquely building against nightly, so we don't actually have a new, compatible version of the adapters to point folks to for now, until KC23 is released, and that places time constraints on us. Backporting this "forward compatible" change would eliminate the time constraint we have and could ease transition for folks from KC22 -> KC23 as they could plan to make any necessary updates sooner, prior to KC23 being released. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I understand that. But the changes you are referring to are actually a server-side thing whereas Keycloak will actually include the iss in responses. Not the opposite.
At least in Java Adapters, the changes you are introducing are basically about the parameters the client is sending to the server. What I'm a bit confused.
Yeah I think its a little weird because the adapters seem to rely on the authorization server to tell it what redirect URI was used based on the auth response, instead of maintaining that state itself. It then uses that same redirect URI from the auth server to use in code to token. This is where the trouble is with the new So its a little something like
|
mposolda
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. Looks good to me and agree that "forward compatibility" of adapters with server changes in Keycloak 23 is beneficial.
@pedroigor Do you have more comments to this or can we merge?
ghost
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unreported flaky test detected, please review
Unreported flaky test detectedIf the below flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.forms.ResetCredentialsAlternativeFlowsTest#testResetCredentialsFlowWithUsernameProvidedFromBrowserFlowKeycloak CI - Forms IT (chrome) |
ghost
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unreported flaky test detected, please review
Unreported flaky test detectedIf the below flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.forms.ResetCredentialsAlternativeFlowsTest#testResetCredentialsFlowWithUsernameProvidedFromBrowserFlowKeycloak CI - Forms IT (chrome) |
pedroigor
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see now. Sorry for the noise.
|
@ssilvert Could you please review the changes to JS adapter? |
|
LGTM, but @jonkoops knows the adapter better than I. I'll let him weigh in. |
jonkoops
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes to the client look fine to me.
1 flaky test on run #9270 ↗︎Details:
|
|||||||||||||||||||||
| Test | Artifacts | |
|---|---|---|
| Realm settings events tab tests > Should remove event from event listener |
Output
Screenshots
|
|
Closes #23794