8000 Always order required actions by priority (regardless of context) by danielFesenmeyer · Pull Request #28956 · keycloak/keycloak · GitHub
[go: up one dir, main page]

Skip to content

Always order required actions by priority (regardless of context) - #28956

Merged
mposolda merged 1 commit into
keycloak:mainfrom
bosch-io:fix/issue-16873
May 23, 2024
Merged

mposolda merged 1 commit into
keycloak:mainfrom
bosch-io:fix/issue-16873

Conversation

@danielFesenmeyer
@danielFesenmeyer danielFesenmeyer commented Apr 22, 2024 •
Copy link
Copy Markdown
Contributor
  • AuthenticationManager#actionRequired: make sure that the highest prioritized required action is performed first, possibly before the currently requested required action
  • AuthenticationManager#nextRequiredAction: make sure that the next action is requested via URL, also based on highest priority (-> requested URL will match actually performed action, unless required actions for the user are changed by a parallel operation)
  • add tests to RequiredActionPriorityTest, add helper method for priority setup to ApiUtil (for easier and more robust setup than up-to-now)

Closes #16873

@danielFesenmeyer
Copy link
Copy Markdown
Contributor Author

Draft PR for solving the linked issue. Currently draft only, because there are some (already) existing tests to be fixed - or maybe further existing code to be adjusted.

@mposolda
Copy link
Copy Markdown
Contributor

@thomasdarimont Could you please review this PR? Is it aligned with your prototype in the PR #28419 ?

@thomasdarimont thomasdarimont left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM Just one minor nitpick about naming that we could change.

I think the rest is pretty solid! Great work @danielFesenmeyer!

I haven't tried it, but I just want to confirm: What happens when a required action is explicitly targeted via the kc_action parameter? Will the other actions still be ignored as before? Same question for executing an action via E-Mail link.

@danielFesenmeyer
Copy link
Copy Markdown
Contributor Author

@thomasdarimont Thanks for your feedback. I'll have a deeper look at the kc_action handling. There are still a few tests failing, probably related to this topic.

This was referenced Apr 23, 2024
@danielFesenmeyer
danielFesenmeyer force-pushed the fix/issue-16873 branch 2 times, most recently from 19f0cf8 to ce338aa Compare April 23, 2024 17:16
@danielFesenmeyer
Copy link
Copy Markdown
Contributor Author

My code still had a bug regarding the "cancel-AIA" behavior: the latest draft now considers that an application initiated action (AIA) cannot be cancelled.

All tests - except one - are succeeding now without further adjustments. The only test to adjust was WebAuthnRegisterAndLoginTest#webAuthnPasswordlessAlternativeWithWebAuthnAndPassword:
The test uses a flow which sets required actions (WebAuthnPasswordlessRegisterFactory and WebAuthnRegisterFactory) into the session, in case there is no registration of credentials yet. Additionally, it explicitly sets the required action WebAuthnPasswordlessRegisterFactory on user level. With the old behavior, user context required actions were executed before session context required actions --> WebAuthnPasswordlessRegisterFactory before WebAuthnRegisterFactory. Now the execution is based on priority: WebAuthnRegisterFactory (prio 70) is now executed before WebAuthnPasswordlessRegisterFactory (prio 80).
Do you think this small behavioral change is ok?

@danielFesenmeyer
Copy link
Copy Markdown
Contributor Author

@thomasdarimont, cc @mposolda

I haven't tried it, but I just want to confirm: What happens when a required action is explicitly targeted via the kc_action parameter? Will the other actions still be ignored as before? Same question for executing an action via E-Mail link.

Afaik, the other actions were not ignored in case of the kc_action parameter. Actually, all applicable actions were executed, but it was made sure that the kc_action was executed last. Regarding order, my current implementation treats kc_action the same way as user-context and session-context actions. I thought this approach is better for consistent behavior - please let me know if you see disadvantages.

@thomasdarimont
Copy link
Copy Markdown
Contributor

Awesome thanks @danielFesenmeyer for the great work!

I'm unsure about the behavior change and I'd like to get the opinion of @mposolda for this.

@mposolda
mposolda marked this pull request as ready for review May 22, 2024 11:32
@mposolda
mposolda requested review from a team as code owners May 22, 2024 11:32
mposolda
mposolda previously approved these changes May 22, 2024
@mposolda mposolda left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@danielFesenmeyer @thomasdarimont Thanks for this PR and feedback! To me, the behaviour change is ok. The new behaviour is much better IMO.

@mposolda
Copy link
Copy Markdown
Contributor

@danielFesenmeyer The thing is, that this branch has conflicts. Can you please rebase and fix the conflicts? I hope to merge this PR afterwards.

@keycloak-github-bot keycloak-github-bot Bot left a comment
Copy link
Copy Markdown

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

@keycloak-github-bot
Copy link
Copy Markdown

Unreported flaky test detected

If the 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.model.session.UserSessionPersisterProviderTest#testMigrateSession

Keycloak CI - Store Model Tests

java.lang.AssertionError: expected:<3> but was:<1>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.junit.Assert.assertEquals(Assert.java:633)
...

Report flaky test

@danielFesenmeyer
Copy link
Copy Markdown
Contributor Author

@mposolda Rebased - new flaky test is unrelated to the changes from my POV.

- AuthenticationManager#actionRequired: make sure that the highest prioritized required action is performed first, possibly before the currently requested required action
- AuthenticationManager#nextRequiredAction: make sure that the next action is requested via URL, also based on highest priority (-> requested URL will match actually performed action, unless required actions for the user are changed by a parallel operation)
- add tests to RequiredActionPriorityTest, add helper method for priority setup to ApiUtil (for easier and more robust setup than up-to-now)
- fix test WebAuthnRegisterAndLoginTest - which failed because WebAuthnRegisterFactory (prio 70) is now executed before WebAuthnPasswordlessRegisterFactory (prio 80)

Closes #16873

Signed-off-by: Daniel Fesenmeyer <daniel.fesenmeyer@bosch.com>
@keycloak-github-bot keycloak-github-bot Bot left a comment
Copy link
Copy Markdown

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

@keycloak-github-bot
Copy link
Copy Markdown

Unreported flaky test detected

If the 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.model.session.UserSessionPersisterProviderTest#testMigrateSession

Keycloak CI - Store Model Tests

java.lang.AssertionError: expected:<3> but was:<1>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.junit.Assert.assertEquals(Assert.java:633)
...

Report flaky test

@mposolda mposolda left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mposolda
mposolda merged commit c08621f into keycloak:main May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Required actions execution order (session and user required actions)

4 participants

0