Spike: Support SCIM provisioning for SSO

[adamvialpando]

Is your feature request related to a problem?

SSO user provisioning today is effectively one way. Users can be added to Flagsmith via SSO, but when a user is removed from the upstream IdP (or from whatever upstream access mechanism is being used), there is no reliable, automatic way to remove or deactivate that user in Flagsmith. This request is to support upstream driven deprovisioning.

Describe the solution you'd like.

Provide a supported way for Flagsmith to:
• Detect when a user should no longer have access based on upstream state, and
• Revoke that user’s access automatically.

“Revoke access” could mean one or more of:
• Remove the user from relevant groups/roles
• Remove their org/project membership
• Deactivate/disable the user account
• Optionally delete the user (likely not the default)

Describe alternatives you've considered

Current workaround is manual offboarding in Flagsmith. That being said the user simply won't be able to authenticate/login anymore (IdP rejects the login).

Additional context

• The mechanism should not be limited to “login-time sync” only.
•	Default behavior should be safe and non-destructive (deactivate or revoke permissions rather than delete).
•	Users may have access via multiple upstream assignments, so removal should not be overly aggressive.
•	Having an audit trail of deprovision actions is important. (currently missing Org level audit logs in general)

Additional Notes

• Solution should not be coupled with SAML, so that it's usable when we build OIDC support as well.

[adamvialpando]

Adding some context from a customer request. They're using Okta SSO with multiple Flagsmith groups and ran into both sides of this.

On the provisioning side (not covered in the original request) - users added to Okta groups don't show up in the corresponding Flagsmith groups until they sign in for the first time. So
admins can't pre-configure group permissions ahead of a user's first login.

On deprovisioning (the original ask here) - users removed from Okta groups stick around in Flagsmith groups, which throws off their license seat counts.

SCIM 2.0 would solve both of these. It's the standard way to handle automatic user and group lifecycle management from Okta, Azure AD, etc. without relying on login-time sync.

[azmeuk]

For the record, there are Python libs that helps with SCIM server and client implementation.
https://github.com/python-scim

[khvn26]

Spike outcome: #7149

Follow-up issues (standalone, not sub-issues of the epic):

• Flagsmith/flagsmith-private#112 — Audit logging for SCIM operations
• Enable OAuth client credentials grant #7153 — Enable OAuth client credentials grant
• Spike: OAuth Application management UI #7154 — Spike: OAuth Application management UI
• Flagsmith/flagsmith-private#113 — OAuth client credentials as SCIM auth method

Docs spec PR: #7139

Notes

• django-scim2's default filtering uses raw SQL which is unsuitable for multi-tenancy. The ORM-based filter parser replaces it using the Q object transpiler from scim2-filter-parser. This is a well-documented approach (django-scim2 issue feature/deploy fe to prod #116) and is ~30 lines of code.
• Azure AD sends non-standard SCIM PATCH Remove requests where value is at the operation level instead of embedded in the path filter. This removes all group members instead of the specified one if not handled. The Group adapter must handle both formats.
• The SCIM module is conditionally loaded, so open-source Flagsmith is unaffected. No feature flag is needed because Enterprise plan gating and the conditional module loading are sufficient.
• We chose django-scim2 over a from-scratch implementation because the hard parts of SCIM (PATCH semantics, filter parsing, schema negotiation, error formatting) are protocol plumbing that the library handles well. Our business logic (org-scoped provisioning, remove_organisation, group sync via external_id) lives in our adapter overrides.
• We chose to map SCIM fields to existing model fields (FFAdminUser.uuid, email, UserPermissionGroup.external_id) rather than adding django-scim2's abstract model mixins. This avoids adding unused fields to the open-source models.
• django-scim2 0.20.0 is not yet published to PyPI (issue Edge API - Implement 3rd Party integrations as Lambdas #202). Pin to a git ref or wait for the release at implementation time.

Future

• OIDC support: the SCIM integration is deliberately SSO-agnostic. When OIDC lands, SCIM will work with it without changes.
• Additional SCIM filter operators: the Q object transpiler already supports co, sw, ew, pr, gt, ge, lt, le. We start with eq only because that is what IdPs use, but expanding is trivial.
• SCIM Bulk endpoint: not implemented. No IdP requires it. Can be added if needed.
• Token scoping to specific SCIM operations (read-only tokens, write-only tokens): not in scope, but the ScimConfiguration model can be extended later.

cc @matthewelwell @asaphko