Skip to content

chore: updated scim 409 conflict error details #2501

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.

Sign up for GitHub

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

Merged
deepakprabhakara merged 1 commit into from
Apr 8, 2026
Merged

chore: updated scim 409 conflict error details #2501

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/kratos/manage-identities/50_scim.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -192,6 +192,6 @@ systems in your organization.
- When querying groups with `GET /Groups`, the SCIM server only supports the `eq` operator for filtering, and only with the
`displayName` attribute. Other operators like `ne`, `co`, `sw`, and `ew` are not supported.
- For both user and group query endpoints, `startIndex` must be lower than 5000, and `count` must be lower than 1000.
- If the user already exists within the project or organization, the provisioning may fail with a 409 conflict error. This is
because the SCIM server cannot modify existing users that have not been provisioned via SCIM. In this case, you need to manually
delete the user first.
- If a user already exists within the same organization, SCIM provisioning will update the user using the configured data mapper.
Copy link
Copy Markdown
Contributor

@unatasha8 unatasha8 Apr 8, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

It sounds like the original limitation (above) no longer exists! That is, an existing user in now updated and there is no 409 error. So it makes sense to delete the limitation above.

However, if the user exists in a different organization, provisioning may fail with a 409 Conflict error. In this case, you must
Copy link
Copy Markdown
Contributor

@unatasha8 unatasha8 Apr 8, 2026

Choose a reason for hiding this comment

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

I don't understand how this is a limitation! A SCIM provisioning map is per organization. So why are we talking about the 'same' or a 'different' organization. Either the identity exists in the organization or it doesn't. If it doesn't exist, isn't it created? If it does exist, isn't it updated? That is the expected behavior. Why are we saying they should delete a user from one organization and add them to a different one? (That would mean there was an expectation that the mapping would know which organization the identity should be in and update it there.)

Copy link
Copy Markdown
Contributor Author

@deepakprabhakara deepakprabhakara Apr 8, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

@unatasha8 The mapping is per org, but identity resolution isn’t — the system checks for existing users globally. So if the same identity already exists in another org (or without an org), SCIM can’t create or reassign it automatically, which is why you get a 409.

either: manually delete the existing user, or move the user into the target organization before retrying provisioning.
Loading