SCIM 2.0 Provisioning
SCIM is the enterprise answer to a simple operational problem: once AxonFlow is used across a real organization, manual user management does not scale.
What SCIM Solves
SCIM helps enterprise teams automate:
- user provisioning
- user deprovisioning
- identity sync
- group-driven access patterns
This is especially important for organizations that need AxonFlow access to reflect the same joiner, mover, and leaver processes already enforced in their central identity platform.
Why It Matters
Without SCIM, a company has to manage users in multiple places, which creates:
- slower onboarding
- slower revocation
- inconsistent access hygiene
- harder audit and access-review processes
With enterprise SCIM, AxonFlow can participate in the same identity lifecycle model used for other internal platforms.
When Teams Usually Need It
SCIM typically becomes important when:
- portal usage expands beyond a small engineering group
- security teams require automated deprovisioning
- access reviews become formal
- identity governance must align with corporate standards
SCIM Endpoints
AxonFlow implements the SCIM 2.0 protocol per RFC 7643 (Schema) and RFC 7644 (Protocol). The SCIM base URL is mounted at /scim/v2/ on the customer portal.
Discovery endpoints (no auth required per RFC 7644):
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /scim/v2/ServiceProviderConfig | Returns SCIM capability metadata |
| GET | /scim/v2/Schemas | Lists all supported SCIM schemas |
| GET | /scim/v2/Schemas/{id} | Returns a specific schema definition |
| GET | /scim/v2/ResourceTypes | Lists supported resource types |
| GET | /scim/v2/ResourceTypes/{name} | Returns a specific resource type |
User endpoints (tenant-scoped, auth required):
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /scim/v2/Users | List users with filter, sort, and pagination |
| POST | /scim/v2/Users | Create a new user |
| GET | /scim/v2/Users/{id} | Retrieve a user by ID |
| PUT | /scim/v2/Users/{id} | Full user replacement |
| PATCH | /scim/v2/Users/{id} | Partial user update (add, remove, replace operations) |
| DELETE | /scim/v2/Users/{id} | Delete a user |
Group endpoints (tenant-scoped, auth required):
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /scim/v2/Groups | List groups with filter, sort, and pagination |
| POST | /scim/v2/Groups | Create a new group |
| GET | /scim/v2/Groups/{id} | Retrieve a group by ID |
| PUT | /scim/v2/Groups/{id} | Full group replacement |
| PATCH | /scim/v2/Groups/{id} | Partial group update |
| DELETE | /scim/v2/Groups/{id} | Delete a group |
User and group provisioning endpoints require a SCIM bearer token created from the customer portal. Portal-side SCIM token management and group-to-role mapping use the authenticated portal session. Responses use the application/scim+json content type and include ETag headers for concurrency control.
Supported Identity Providers
AxonFlow provides setup guidance for common enterprise identity providers:
- Okta -- common enterprise SCIM provisioning through the SCIM 2.0 header-auth app
- Microsoft Entra ID -- for Microsoft-centric organizations using automatic provisioning
- OneLogin -- for teams using OneLogin as the identity lifecycle source
Other identity providers that implement the SCIM 2.0 protocol can often provision users through the standard SCIM endpoints when they support bearer-token authentication, user lifecycle sync, and optional group provisioning.
Group-to-Role Mapping
AxonFlow extends standard SCIM with group-to-role synchronization. When users are provisioned through SCIM, their IdP group memberships can automatically map to AxonFlow roles. Adding a user to an IdP group assigns the corresponding AxonFlow role. Removing the user from the group revokes it.
As of platform v8.7.0, the group-to-role mapping endpoints are mounted and available on the customer portal:
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /api/v1/scim/groups/role-mappings | List the organization's group-to-role mappings |
| PUT | /api/v1/scim/groups/{id}/role-mapping | Set or clear a mapping for one synced SCIM group. Use {"role_id": null} to clear the mapping. |
| GET | /api/v1/scim/roles | List assignable roles for group-to-role mapping |
Because assigning a role is a privilege grant, these endpoints are served on the session-authenticated portal router and gated by the sso:configure permission, the same gate as SCIM token management, rather than the bearer-token /scim/v2 provisioning router. The organization is resolved from the authenticated session, so a spoofed X-Tenant-ID header cannot steer a mapping write to another org. Every change is recorded to the SCIM audit log.
Use the group-to-role mapping guide for rollout order, group naming guidance, and role-alignment patterns.
How SCIM Fits the Enterprise Identity Model
SCIM is one part of the enterprise identity stack. SSO handles authentication (proving who a user is). SCIM handles provisioning (ensuring the right users exist with the right group memberships). Together with SAML for the protocol layer, they give organizations a complete identity lifecycle that matches how they manage access to every other internal platform.
Implementation Guides
These enterprise setup guides are public so IAM teams, platform engineers, and coding agents can evaluate the implementation path without needing protected-docs access:
- SCIM Getting Started
- SCIM API Reference
- Okta SCIM Integration
- Microsoft Entra ID SCIM Integration
- OneLogin SCIM Integration
- Group to Role Mapping
- SCIM Troubleshooting
