Are there any plans to add support for setting passwords via the SCIM API? #52957

Inperpetuammemoriam · 2026-09-18T16:33:41Z

Inperpetuammemoriam
Sep 18, 2026

As indicated by the endpoint /scim/v2/ServiceProviderConfig (Section 5 of [RFC 7643]), changePassword is not supported by the current implementation. Are there any plans to add support for this in the future? If there are none or if those plans are not covering the near future: Under what circumstances would a PR implementing this feature be accepted?

sguilhen · 2026-09-18T17:47:26Z

sguilhen
Sep 18, 2026
Collaborator

Hi @Inperpetuammemoriam , thanks for initiating this discussion!

Right now there isn't a dedicated tracker for changePassword specifically; general SCIM enhancements are collected under #50512, and none currently mention password support, so this hasn't been ruled in or out yet.

Here's why it's off today, and what we'd want a PR to address.

The changePassword flag is honest about the current state: the SCIM User representation has no password attribute at all, so there's nothing to wire up yet. That's a real gap, not an ignored field.

For a PR to be acceptable, we'd want it to:

Add the password attribute to the core User schema, per RFC 7643 §8.7.1 (writeOnly, returned: never), and support it on create (POST), full replace (PUT), and PATCH.
Map it to Keycloak's existing password credential path, the same one the Admin REST API's reset password endpoint already uses: an unconditional overwrite via UserCredentialModel.password(...), with no requirement to know the current password. That fits SCIM's model too: password there is meant for trusted provisioning clients, not end user self-service.
Only affect the password credential. SCIM's core schema has no concept of OTP, WebAuthn, or other credential types, so this should be scoped narrowly and not attempt to generalize to Keycloak's broader credential model.
Document one real gap up front: Keycloak's "force password change on next login" (the UPDATE_PASSWORD required action) has no SCIM equivalent. A SCIM initiated password set would just be a permanent set, never a temporary one. That seems like an acceptable limitation to call out rather than something to work around.
Map password policy violations to a proper SCIM error (400, invalidValue/invalidPassword), instead of letting Keycloak's internal policy exception surface as a generic failure.
Include proper test coverage: create, full replace, and PATCH paths setting the password, a policy violation case exercising the new error mapping, and confirmation that the value is never echoed back in a response (per returned: never).

Once that's in place, flipping changePassword.supported to true is just reflecting reality.

Happy to review a PR that follows this shape.

0 replies

Navigation Menu

Repository navigation

Are there any plans to add support for setting passwords via the SCIM API? #52957

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Are there any plans to add support for setting passwords via the SCIM API? #52957

Uh oh!

Inperpetuammemoriam Sep 18, 2026

Replies: 1 comment

Uh oh!

sguilhen Sep 18, 2026 Collaborator

Inperpetuammemoriam
Sep 18, 2026

sguilhen
Sep 18, 2026
Collaborator