Problem/Motivation

Every update of a user sends the required actions configured for updates as the account's complete list. With the default (no update required actions), Keycloak gets "requiredActions": [] and removes every required action the account has.

KeycloakService::getSafeUserData() sets $userData['requiredActions'] from <operation>_required_actions, and updateUser() PUTs that representation. Keycloak replaces the list, it does not merge it.

Consequences:

  • UPDATE_PASSWORD from insert_required_actions is gone after the first save that follows the creation. A profile saved in the same request is enough. The account-setup e-mail still works, because the action token carries the action. But Keycloak's update-password page then shows no warning message: the theme gets an empty summary, so a password hint placed there disappears.
  • Required actions an administrator sets in Keycloak (VERIFY_EMAIL, CONFIGURE_TOTP, UPDATE_PASSWORD after a suspected leak) vanish with the next save of the user or the profile in Drupal.

This is the same pattern as #3624171, where an update wiped the attributes this module does not map.

Steps to reproduce

  1. Configure insert_required_actions = UPDATE_PASSWORD and leave update_required_actions empty.
  2. Create a Drupal user. The Keycloak account has requiredActions ["UPDATE_PASSWORD"].
  3. Save the user (or its profile) once more in Drupal.
  4. The Keycloak account now has requiredActions [].

Proposed resolution

On update, keep the required actions the Keycloak account has and add the configured update_required_actions (union, without duplicates). When both lists are empty, leave requiredActions out of the request, so Keycloak does not touch them. updateUser() already reads the existing account for the attributes (#3624171), so no extra request is needed.

Remaining tasks

  • Merge request with the fix and a unit test.

User interface changes

None.

API changes

None. update_required_actions keeps its meaning ("add these on update"), but no longer removes other actions.

Data model changes

None.

Issue fork keycloak_user_sync-3630154

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

daniel.pernold created an issue. See original summary.

daniel.pernold opened merge request !10

daniel.pernold’s picture

daniel.pernold commented

Hi bundes and roromedia, thank you for merging #3624189 and #3624171.

The merge requests for this issue and its sibling (!9 for #3624231 and !10 for #3630154) are small, have unit tests, show no conflicts with 1.0.x, and their pipelines pass. Could you have a look and merge them if they look right to you?

If you then have the time, could you tag a 1.0.12 release? 1.0.x has a number of fixes since 1.0.11 (Drupal 11 compatibility of the settings form, the /auth path, the exact username lookup, keeping unmapped attributes, and these two). Sites that cannot run a dev branch could then drop their patches. If anything needs changing first, I am happy to update the MRs.

Thanks!

  • eacf82c2 committed on 1.0.x 
    Issue #3630154 by daniel.pernold, roromedia: Split the long test...

  • daniel.pernold authored 41407bee on 1.0.x 
    Issue #3630154 by daniel.pernold: Saving a user wipes the Keycloak user'...
roromedia’s picture

roromedia commented
Status: Active » Fixed

Merged into 1.0.x and released in 1.0.12, thank you! Both squashed in, plus a tiny follow-up for two over-long test lines. The other six MRs are next on my list.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.