Correctly moves to the next required action #31060

graziang · 2024-07-04T15:28:11Z

If a required action was successful or ignored in RequiredActionProvider.requiredActionChallenge() (like the VERIFY_EMAIL action on an already verified email), the following actions were skipped.

I just have a doubt if the current behavior of ignoring the action in case of a null email in the VERIFY_EMAIL action is correct, or if the user should be stopped with a message indicating that the email is not present and therefore not verified.

Closes #31014

rmartinc

@graziang There are failures in FIPS that (I think) are related as the stacktrace seems to show the modified method. My feeling is that you need to separate the ignore in a different else if. But not tested. 😄

rmartinc · 2024-07-05T11:21:37Z

services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java

            return context.getChallenge();
        }
-        else if (context.getStatus() == RequiredActionContext.Status.SUCCESS) {
+        else if (context.getStatus() == RequiredActionContext.Status.SUCCESS || context.getStatus() == RequiredActionContext.Status.IGNORE) {


Wouldn't be move the ignore in a different if and do the next only in that situation? Something like:

diff --git a/services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java b/services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java index 10fd0e7523..847341149f 100755 --- a/services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java +++ b/services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java @@ -1279,6 +1279,10 @@ public class AuthenticationManager { authSession.setAuthNote(AuthenticationProcessor.CURRENT_AUTHENTICATION_EXECUTION, model.getProviderId()); return context.getChallenge(); } + else if (context.getStatus() == RequiredActionContext.Status.IGNORE) { + authSession.getAuthenticatedUser().removeRequiredAction(factory.getId()); + authSession.removeRequiredAction(factory.getId()); + return nextActionAfterAuthentication(session, authSession, session.getContext().getConnection(), request, session.getContext().getUri(), event); + } else if (context.getStatus() == RequiredActionContext.Status.SUCCESS) { event.clone().event(EventType.CUSTOM_REQUIRED_ACTION).detail(Details.CUSTOM_REQUIRED_ACTION, factory.getId()).success(); // don't have to perform the same action twice, so remove it from both the user and session required actions

In the case where a user has already verified their email, and for some reason you add the VERIFY_EMAIL and webauthn-register (or any other action with low priority) action to the user, the webauthn-register action would be skipped because of context.success() here.

Ah! Ok, the failure in fips was that the verify email was re-added all the time. OK. Thanks!

Maybe then if ignored the event should not be added. I don't think we shoukd report an event if verify_email is ignored. The next line. WDYT?

Thanks, ok about not reporting the event.

I was thinking if it would be better to let it fail in any case if the email is null instead of ignoring it, because otherwise if you manually add the required action to the user the behavior between the the two flows would still be different

It looks that is general fix for all required which call context.success(); from requiredActionChallenge(final RequiredActionContext context)

context.success(); from requiredActionChallenge(final RequiredActionContext context)

@rmartinc Is it ok for you, are you going to approve this PR?

I would do the same in both situations. The condition for evaluateTriggers is context.getRealm().isVerifyEmail() && !context.getUser().isEmailVerified() so I would do the same for requiredActionChallenge. The action should not pass if the email is blank but the realm is configured to verify email. I think it's the less disruptive decision. But, as you say, we can also decide to always fail if the action is assigned and the email is blank (but maybe you need to change tests).

@radoslawsyga We need to take a decision about what to do with the verify email action. There is a test that is failing right now. It will be approved and merged when ready.

Updated the PR to always fail if the action is assigned and the email is blank. Tests look OK

Closes keycloak#31014 Signed-off-by: Giuseppe Graziano <[email protected]>

rmartinc

Thanks @graziang! LGTM! It's a bit of a change but it makes sense in IMHO. Besides actions update profile and verify email can be added to a user to force the email update and the verify.

mposolda

@graziang @rmartinc Thanks for the PR and the review.

I have some doubts as this is quite backwards incompatible change. I've tried to test the scenario like this:

New realm test is created
Admin switches Verify Email to ON for that realm
Admin creates user john with some password and without email (This is possible as email is not required user-profile attribute for administrators by default. It is required just for the regular users)
Attempt to login as john . Now I see the error message that email is not set. Moreover user does not have any chance to set his email, so he would be completely stuck at this moment.

I would expect the behaviour for that scenario that after login with username/password user is first required to update his profile (because of Verify profile required action, which was triggered due the email attribute missing) and then email verification required as next step. I've checked that was the behaviour in Keycloak 24.

Do we need to keep the changes in the behaviour in the VerifyEmail class? If we need (which I am not sure), how to make sure that behaviour would be correct (ideally same as in Keycloak 24)?

Maybe one option is that we can make sure that Verify Profile action is before Verify Email action. This will require changing the behaviour for new realms, but also migration as it will need to be updated for existing realms migrated from previous versions (which can be complicated as I am not sure if Verify Profile action is set and enabled by default for the deployments like Keycloak 22 where user-profile was not yet enabled by default). Do we have any better option then tricky migration changes?

rmartinc · 2024-07-16T11:06:08Z

The change in verify email was needed, because if not there was a loop (the evaluate triggers added the action but it was ignored later). My feeling is that the different order in the verify profile and verify email is triggered by the other PR, now the order is exactly specified by the priority in the actions.

I have done some tests with 24.0.5 (I had not done this before):

If verify email and profile are set in the realm but the user has no email, the order is the one @mposolda commented (first verify profile and then verify email).
If verify email is set in the realm but no verify profile, no action is presented to the user, it logs in directly. So verify email is not executed.

So maybe we should do the following to emulate better the previous behavior (which it's not perfect either):

Ignore the verify email if the email is not set. So not modifying the requiredActionChallenge and just ignore if Validation.isBlank(email).
Also add this in the evaluateTriggers, do not add the action if the user has no email. This way, the two previous uses are the same. Don't know if some test will fail this way (IIRC there were test errors when login via direct access grants or client credentials, probably because now it's accepted and previously was not accepted).

WDYT? If you don't like that the only way (I have seen) is modifying priorities in the upgrade for the actions.

mposolda · 2024-07-16T11:42:16Z

@rmartinc +1 to make sure that behaviour is the same as in Keycloak 24.0.5 for both cases when Verify Email option is enabled and:

If Verify Profile required action is enabled, then ask user to fill his email first and then require to verify the email
If Verify Profile required action is disabled (or not present), then ignore Verifying Email and let the user to login

Can be also good to make automated tests for those scenarios IMO (if not already present).

From the options you proposed, any of them is OK IMO as long as we have the behaviour as in Keycloak 24. Both are better than changing the order of required actions IMO (due the migration and the possible issues related to that...).

Maybe another option is to not do any changes in the VerifyEmail, but instead do something to make sure that context.ignore() is handled better by the framework and there is no infinite loop? But maybe that is more tricky than the options you proposed, not sure...

Closes keycloak#31014 Signed-off-by: Giuseppe Graziano <[email protected]>

rmartinc · 2024-07-16T15:48:57Z

@graziang I'm working on this, forget about it for noe! 😄

graziang · 2024-07-16T15:57:43Z

@rmartin @mposolda thanks for the review and all the suggestions! IMO the Verify Email action should not be ignored if the email is not set and also not verified when Verify Email is enabled on the realm. Probably the best solution would be that after login with username/password, the user is first required to update their profile (because of the Verify Profile required action, which was triggered due to the missing email attribute) and then verify email required as the next step. This is the behavior with Keycloak 24.0.5.

On the other hand, I agree with Ricardo's proposed solution that it is better than changing the order of required actions because of the migration and the possible issues. @rmartinc feel free to continue the work

rmartinc · 2024-07-17T06:19:33Z

Superseded by #31358.

graziang requested review from a team as code owners July 4, 2024 15:28

keycloak-github-bot bot added team/cloud-native team/core-clients team/core-iam labels Jul 4, 2024

rmartinc suggested changes Jul 5, 2024

View reviewed changes

graziang force-pushed the issue-31014 branch 2 times, most recently from a5e6911 to 261ae28 Compare July 5, 2024 13:48

keycloak-github-bot bot added the flaky-test label Jul 5, 2024

keycloak-github-bot bot mentioned this pull request Jul 5, 2024

Flaky test: org.keycloak.testsuite.broker.KcOidcBrokerTest#testPostBrokerLoginFlowWithOTP_bruteForceEnabled #30188

Closed

radoslawsyga mentioned this pull request Jul 10, 2024

"Verify Email" may cause other Required Actions to be ignored #31014

Closed

2 tasks

mposolda self-assigned this Jul 11, 2024

graziang force-pushed the issue-31014 branch from 261ae28 to 14a0003 Compare July 15, 2024 10:25

graziang requested a review from a team as a code owner July 15, 2024 10:25

keycloak-github-bot bot added the team/ui label Jul 15, 2024

Correctly moves to the next required action

6ba4186

Closes keycloak#31014 Signed-off-by: Giuseppe Graziano <[email protected]>

graziang force-pushed the issue-31014 branch from 14a0003 to 6ba4186 Compare July 15, 2024 11:16

keycloak-github-bot bot mentioned this pull request Jul 15, 2024

Flaky test: org.keycloak.testsuite.admin.concurrency.ConcurrencyTest#testAllConcurrently #31091

Closed

rmartinc approved these changes Jul 15, 2024

View reviewed changes

mposolda requested changes Jul 16, 2024

View reviewed changes

Follow-up correctly moves to the next required action

d910e02

Closes keycloak#31014 Signed-off-by: Giuseppe Graziano <[email protected]>

rmartinc mentioned this pull request Jul 17, 2024

Correctly moves to the next required action #31358

Merged

rmartinc closed this Jul 17, 2024

Correctly moves to the next required action #31060

Correctly moves to the next required action #31060

Uh oh!

Conversation

graziang commented Jul 4, 2024

Uh oh!

rmartinc left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rmartinc Jul 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rmartinc left a comment

Choose a reason for hiding this comment

Uh oh!

mposolda left a comment

Choose a reason for hiding this comment

Uh oh!

rmartinc commented Jul 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mposolda commented Jul 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rmartinc commented Jul 16, 2024

Uh oh!

graziang commented Jul 16, 2024

Uh oh!

rmartinc commented Jul 17, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

rmartinc left a comment •

edited

Loading

rmartinc Jul 5, 2024 •

edited

Loading

rmartinc commented Jul 16, 2024 •

edited

Loading

mposolda commented Jul 16, 2024 •

edited

Loading