Skip to main content

SCIM Provisioning

SCIM 2.0 lets an identity provider (such as Okta, Microsoft Entra, or JumpCloud) provision and deprovision platform users and push group memberships into Ascent automatically. This is the recommended way to manage platform operators at scale instead of creating each account by hand.

Overview​

SCIM provisioning lets you:

  • Create platform users automatically when your IdP adds them.
  • Update names, emails, and active status when they change in the IdP.
  • Deactivate (soft-delete) users when they leave the IdP.
  • Push groups from the IdP and map each group to an Ascent platform role.
  • Issue, rotate, and revoke per-IdP bearer tokens, each scoped to the users and groups that token provisioned.

SCIM provisions the account; it does not handle login. SCIM-provisioned users are created with single sign-on (SSO/OIDC) as their authentication method and cannot log in with a password — they sign in through a provider you configure on the Platform SSO page. SCIM only manages platform users (Ascent operators), not organization or portal users.

Go to Platform Admin → SCIM. This page is available only to users with the Platform Admin (PLATFORM_ADMIN) role; other platform roles see an Access Denied message.

The page has three sections:

  • SCIM base URL — the URL you paste into your IdP.
  • SCIM clients — the bearer tokens that authenticate each IdP integration.
  • Group role mappings — maps groups your IdP has pushed to Ascent platform roles.

SCIM base URL​

The base URL shown on the page is your Ascent host followed by the SCIM path:

https://<your-ascent-host>/api/scim/v2/platform

Paste this exact value into your IdP's SCIM 2.0 connector configuration. The base URL is the same for every IdP — each integration is distinguished by its own bearer token, not by a different URL.

Under this base URL, Ascent exposes the standard SCIM 2.0 discovery, user, and group endpoints (for example /ServiceProviderConfig, /Schemas, /ResourceTypes, /Users, and /Groups). The service config advertises support for PATCH and filtering; it does not support bulk operations, sorting, change-password, or ETags.

Creating a SCIM client (bearer token)​

Each IdP integration needs its own SCIM client. The client's bearer token is what your IdP sends in the Authorization: Bearer <token> header.

  1. Click New client.
  2. Enter a Name that identifies the integration (for example, Okta Production).
  3. Click Create.
  4. Copy the token from the SCIM bearer token dialog and store it in your IdP and a password manager.

The token is shown exactly once. It is stored only as a hash, so Ascent cannot show it again. If you lose it, rotate the client to generate a new one. Tokens begin with the prefix scim_.

In the SCIM clients table, each client shows:

ColumnDescription
NameThe label you gave the client.
TokenThe first 8 characters of the token, followed by …. Use this to confirm which token your IdP is using.
StatusActive or Revoked.
Last usedWhen a request last authenticated with this token (or never).
CreatedWhen the client was created.
ActionsRotate or revoke the client.

Rotate a token​

Click the Rotate token action on a client to issue a new token. The previous token stops working immediately, so you must update your IdP with the new value. The new token is shown once, in the same dialog as on creation. Rotating a revoked client also reactivates it.

Revoke a client​

Click the Revoke client action to deactivate a client. Its token stops working immediately, but the users and groups it provisioned stay in place — you can rotate the client later to issue a new token and re-enable it.

Connecting your identity provider​

The exact configuration screens differ by IdP, but the two values you always need are the same:

  • Base URL / Tenant URL / SCIM connector base URL: the SCIM base URL above.
  • Bearer token / Secret token: the token from the client you created.

After you save these in your IdP and run a provisioning test or sync, the IdP starts pushing users and groups to Ascent. Provisioned users appear under Platform Admin → Users, and pushed groups appear in the Group role mappings section of this page.

What gets synced​

Users​

When your IdP creates a user, Ascent creates a platform user with:

  • Email taken from userName (or the primary email if userName is absent).
  • Name taken from name.formatted, displayName, or the combined given/family name.
  • Authentication method set to SSO/OIDC — SCIM users cannot sign in with a password. Any password attribute the IdP sends is ignored. Configure the SSO provider these users sign in with on the Platform SSO page.
  • Platform role set to Platform Billing (the least-privileged role) initially. Group mappings can raise this — see below.
  • Active status from the IdP's active flag.

Subsequent updates from the IdP (via PUT or PATCH) keep the email, name, and active status in sync. When the IdP deactivates or deletes a user, Ascent soft-deletes them by setting them inactive rather than removing the record, which preserves audit history and lets the user be reactivated if they are re-added later.

If an IdP pushes a userName that matches an existing unowned account (such as the bootstrap admin seeded on first boot), the first SCIM client to push it adopts that record so SCIM can manage it going forward. If the email already belongs to a different SCIM client, the request is rejected as a conflict — Ascent never merges identities automatically.

Groups​

Groups pushed by your IdP are stored so you can map them to platform roles. A group carries its display name, external ID, and its member list. Membership changes (adding or removing members) are applied as the IdP sends them.

Groups do not carry a role over SCIM — you assign the role inside Ascent (next section), which keeps the SCIM integration standard with no custom schema extension required.

Group role mappings​

In the Group role mappings section, each group your IdP has pushed appears with its display name, external ID, the SCIM client that pushed it, and its member count. For each group, choose a Platform role from the dropdown:

OptionEffect
— No role —The group confers no role.
Platform AdminMembers gain the PLATFORM_ADMIN role.
Platform SupportMembers gain the PLATFORM_SUPPORT role.
Platform BillingMembers gain the PLATFORM_BILLING role.

A user's effective platform role is the highest-privilege role among all of their mapped groups. Changing a mapping immediately recomputes the role for every current member of that group. If none of a user's groups has a mapped role, their existing role is left unchanged rather than being downgraded.

Until your IdP syncs at least one group, this section shows a message that no groups have been pushed yet.

Tips​

  • Store the token immediately. It is shown only once and cannot be recovered — rotation is the only path if you lose it.
  • Use one client per IdP. Each token is scoped to the users and groups it provisioned, so one IdP's token cannot see or modify another's data. The token prefix in the SCIM clients table helps you confirm which token an IdP is using.
  • Map your admin group before relying on SCIM for access. A freshly provisioned user starts as Platform Billing; map the appropriate group to Platform Admin so your operators keep the access they need.
  • Review changes in the audit log. SCIM client creation, rotation, and revocation — plus every user and group change made over SCIM — are recorded in the Platform Audit log.