WRNexus
Back to the blog
enterprise 7 min read

SCIM 2.0 provisioning, end to end

A walkthrough of the WRNexus SCIM 2.0 endpoint — how to wire it to Okta, Azure AD or Google Workspace, and what we did to keep the integration boring.

Daniel Park

#enterprise · #scim · #identity

For most teams, SCIM is the boundary between “self-serve SaaS” and “we actually use this for serious work.” When IT can deactivate an account on the IdP side and have the user lose access in WRNexus within a minute, the audit story writes itself.

Here is the full picture of how WRNexus implements SCIM 2.0 — and how to wire it up against Okta, Microsoft Entra ID (formerly Azure AD) and Google Workspace.

What we support

The Enterprise WRNexus SCIM endpoint implements:

  • /Users — create, replace, patch, search and delete.
  • /Groups — create, replace, patch, search and delete.
  • Filter expressions: userName eq "…", emails.value eq "…", displayName co "…".
  • Pagination via startIndex and count with deterministic ordering.
  • Sub-resource patching with add, replace and remove operations.

We deliberately scope the endpoint to user and group lifecycle. We do not expose roles or permissions over SCIM — those live in WRNexus RBAC and are managed by workspace owners. Mapping IdP groups to WRNexus roles happens once, on the integration’s settings page.

Provisioning, in three steps

  1. Generate a SCIM token in Account → Workspace → SCIM. It is a long-lived bearer token scoped exclusively to /scim/v2/* — never re-use a regular API key.
  2. Paste it into your IdP. The base URL is https://api.wrnexus.com/scim/v2/<workspace-slug>.
  3. Map attributes. WRNexus expects userName, emails[primary], name.givenName, name.familyName and active. Anything else is stored on the user profile but not used for sign-in.

Deprovisioning behaviour

When your IdP sets active: false (or DELETEs the user), WRNexus does the following within ~60 seconds:

  • Marks the user account as suspended — they cannot sign in.
  • Revokes every active session across every region.
  • Disables their API keys but keeps them around for audit history.
  • Records a user.suspended_by_scim audit event with the IdP request id.

Workspace memberships are not deleted — the user re-activates cleanly if the IdP flips them back. This matches the principle of least surprise: deprovisioning is a sign-in block, not a data deletion.

A note on eventually consistent

SCIM is asynchronous in spirit and we treat it that way. Bulk syncs run on a background worker so a 5,000-user push never blocks your IdP’s UI. The admin console surfaces sync progress and any partial failures, with retry buttons per row.

If you would like an early peek at the integration before you sign an Enterprise contract, drop us a line at hello@wrnexus.com — we have a sandbox tenant ready.