Skip to main content

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):

MethodEndpointPurpose
GET/scim/v2/ServiceProviderConfigReturns SCIM capability metadata
GET/scim/v2/SchemasLists all supported SCIM schemas
GET/scim/v2/Schemas/{id}Returns a specific schema definition
GET/scim/v2/ResourceTypesLists supported resource types
GET/scim/v2/ResourceTypes/{name}Returns a specific resource type

User endpoints (tenant-scoped, auth required):

MethodEndpointPurpose
GET/scim/v2/UsersList users with filter, sort, and pagination
POST/scim/v2/UsersCreate 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):

MethodEndpointPurpose
GET/scim/v2/GroupsList groups with filter, sort, and pagination
POST/scim/v2/GroupsCreate 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

All tenant-scoped endpoints require the OAuth2 Basic auth or an authenticated session context. Responses use the application/scim+json content type and include ETag headers for concurrency control.

Supported Identity Providers

AxonFlow has dedicated provider adapters for:

  • Okta -- the most common enterprise IdP for SCIM provisioning
  • Azure AD (Entra ID) -- for Microsoft-centric organizations
  • Auth0 -- for teams using Auth0 as their identity platform

Any identity provider that implements the SCIM 2.0 protocol (including OneLogin, Ping Identity, and others) can provision users through the standard SCIM endpoints. Dedicated adapters handle metadata and configuration differences for the providers listed above.

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.

Implementation status

Group-to-role mapping handlers exist in the codebase but may not be wired into all deployment configurations. Verify endpoint availability in your specific enterprise deployment via the protected enterprise docs.

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.

Public vs Protected Documentation

This public page is intentionally focused on fit and value. The protected enterprise docs cover the operational setup details, provider-specific guides, token management, endpoint configuration, and troubleshooting steps.