SCIM Integration - DQLabs PRIZM

SCIM (System for Cross-domain Identity Management) is an open standard for automating user provisioning. When SCIM is configured, your Identity Provider (IdP) automatically creates, updates, deactivates, and deletes Prizm user accounts whenever changes are made in your directory — no manual user management required.

How it works

Prizm exposes a SCIM URL visible under Organization → Security.
You configure your IdP to send provisioning requests to that URL using a bearer token for authentication.
Whenever a user is added, changed, or removed in your IdP, it pushes a SCIM request to Prizm.
Prizm applies the change — creating the account, updating the profile, or deactivating access.

Supported providers

Provider	User Provisioning	Group Sync
Okta	✅	✅
Azure Active Directory / Entra ID	✅	✅
Ping Identity	✅	✅
IBM Security Verify	✅	❌ Users only

IBM Security Verify supports user provisioning only. Group synchronization is not available for IBM. Use Okta, Azure AD, or Ping Identity if group-based access management is required.

What SCIM manages

Entity	Operations	Providers
Users	Create, Update, Deactivate, Delete	All
Groups	Create, Update, Delete	Okta, Azure AD, Ping Identity
Group membership	Add / Remove user	Okta, Azure AD, Ping Identity

Prerequisites

SAML SSO must already be configured in Prizm for your IdP before enabling SCIM.
You need admin access to both Prizm (Organization → Security) and your IdP.
A static bearer token is required for the IdP to authenticate to Prizm’s SCIM endpoint.

If your organization uses Override unique identifier (under Organization → Security) to match SAML logins by a permanent attribute instead of email, configure the matching SCIM field below with that same attribute, so SCIM-provisioned accounts resolve to the same identity as SAML logins. See SSO Integration Overview for details, and Unique identifier and externalId below for the SCIM field to use.

Finding the SCIM URL

In Prizm, navigate to Organization → Security.
Locate the SCIM URL field (read-only).
Copy this URL — paste it into your IdP’s SCIM provisioning configuration as the SCIM Base URL or Tenant URL.

SSO Provider Configuration form with the SCIM URL field — Organization → Security: SSO Provider Configuration, including the SCIM URL

Setup by provider

Okta
Azure AD / Entra ID
Ping Identity
IBM Security Verify

Prerequisites

Okta SAML SSO is already configured for Prizm.
You have Okta Administrator access.
You have the Prizm SCIM URL.

Step 1 — Open SCIM provisioning in Okta

In the Okta Admin Console, navigate to Applications and open the Prizm SAML application.
Go to the Provisioning tab → Integration section.
Click Configure API Integration and enable API Integration.

Step 2 — Configure the SCIM endpoint

Field	Value
SCIM connector base URL	Prizm SCIM URL
Unique identifier field for users	`email` by default — or the attribute set under Override unique identifier in Prizm, if enabled
Supported provisioning actions	Import Users, Push Users, Push Groups
Authentication Mode	HTTP Header
Authorization	`Bearer <your-static-token>`

Click Test API Credentials to verify the connection, then Save.

Step 3 — Enable provisioning to app

Under Provisioning → To App, enable:

Setting	Effect
Create Users	Automatically creates Prizm accounts for Okta users assigned to the app
Update User Attributes	Syncs profile changes from Okta to Prizm
Deactivate Users	Deactivates Prizm accounts when a user is unassigned or deactivated in Okta

Step 4 — Map attributes

Okta attribute	SCIM attribute
`userPrincipalName`	`userName`
`givenName` / `user.firstName`	`name.givenName`
`surname` / `user.lastName`	`name.familyName`
`email` / `user.email`	`emails[type eq "work"].value`

Step 5 — Push groups (optional)

Go to the Push Groups tab in the Provisioning section.
Click Push Groups and search for the Okta groups to sync.
Select the groups and click Save.

Prizm creates matching groups and keeps membership in sync with Okta.

Prerequisites

Azure AD SAML SSO is already configured for Prizm.
You have Microsoft Entra ID Administrator access.
You have the Prizm SCIM URL.

Step 1 — Open provisioning in Entra ID

In the Azure Portal, navigate to Azure Active Directory → Enterprise Applications.
Open the Prizm enterprise application.
Go to Provisioning → click Get Started.

Step 2 — Configure the SCIM endpoint

Set Provisioning Mode to Automatic, then under Admin Credentials:

Field	Value
Tenant URL	Prizm SCIM URL (must end with `/scim/v2/`)
Secret Token	Static bearer token generated in Prizm

Click Test Connection — Azure sends a GET to /scim/v2/ServiceProviderConfig. Proceed when successful.

Step 3 — Configure attribute mappings

Go to Mappings and verify user attribute mappings:

Azure AD attribute	SCIM attribute
`userPrincipalName`	`userName`
`givenName`	`name.givenName`
`surname`	`name.familyName`
`mail`	`emails[type eq "work"].value`
`department`	`urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department`

For group sync, configure Provision Azure Active Directory Groups mappings similarly.

Step 4 — Set provisioning scope

Under Settings, choose:

Sync only assigned users and groups (recommended) — provisions only users/groups assigned to the Prizm application
Sync all users and groups — provisions everyone in the directory

Step 5 — Start provisioning

Click Save, then set Provisioning Status to On and click Save again.Azure AD runs an initial sync cycle. Subsequent cycles run automatically every ~40 minutes.

Prerequisites

Ping Identity SAML SSO is already configured for Prizm.
You have Ping Identity Administrator access.
You have the Prizm SCIM URL.

Step 1 — Open SCIM provisioning in Ping Identity

Log in to the PingOne or PingFederate admin console.
Navigate to Applications and open the Prizm SAML application.
Go to the Provisioning tab and enable Outbound Provisioning.

Step 2 — Configure the SCIM endpoint

Field	Value
SCIM Base URL	Prizm SCIM URL
Authentication Method	Bearer Token
Bearer Token	Static token generated in Prizm

Click Test Connection to verify Ping can reach the Prizm SCIM endpoint, then Save.

Step 3 — Enable provisioning actions

Action	Description
Create Users	Automatically creates Prizm accounts for users assigned to the app
Update User Attributes	Syncs profile changes from Ping to Prizm
Deactivate Users	Deactivates Prizm accounts when users are deprovisioned in Ping
Push Groups	Syncs Ping groups to Prizm

Step 4 — Map attributes

Ping attribute	SCIM attribute
`username`	`userName`
`given_name` / Given Name	`name.givenName`
`family_name` / Surname	`name.familyName`
`email` / Email Address	`emails[type eq "work"].value`
`active`	`active`

Step 5 — Configure group provisioning and activate

Navigate to Group Provisioning in the Provisioning tab.
Select the groups to sync to Prizm and save.
Run a Test Provisioning cycle to confirm at least one user and group sync correctly.
Enable automatic provisioning.

IBM Security Verify supports user provisioning only. Group synchronization is not supported. Users can be assigned to Prizm groups manually after provisioning, or through role mappings configured in Prizm.

Prerequisites

IBM Security Verify SAML SSO is already configured for Prizm.
You have IBM Security Verify Administrator access.
You have the Prizm SCIM URL.

Step 1 — Open provisioning in IBM Security Verify

Sign in to the IBM Security Verify Admin Console.
Navigate to Applications and open the Prizm application.
Go to the Provisioning or Automated User Management section.

Step 2 — Configure the SCIM endpoint

Field	Value
SCIM Base URL	Prizm SCIM URL
Authentication Method	Bearer Token
Authentication Token	Static token generated in Prizm

Click Test Connection to verify IBM can reach the Prizm SCIM endpoint.

Step 3 — Enable provisioning actions

Action	Supported	Description
Create Users	✅	Creates Prizm accounts for provisioned users
Update User Attributes	✅	Syncs first name, last name, and email from IBM to Prizm
Deactivate Users	✅	Deactivates Prizm accounts when users are deprovisioned in IBM
Push Groups	❌	Not supported by IBM Security Verify

Step 4 — Map attributes

IBM attribute	SCIM attribute
`email`	`userName` and `emails[type eq "work"].value`
`given_name`	`name.givenName`
`family_name`	`name.familyName`
`active`	`active`

Step 5 — Test and activate

Run a test provisioning cycle to confirm at least one user syncs and appears in Profile → Organization → Users in Prizm.
Enable automatic provisioning.

SCIM endpoints

All IdPs use the same Prizm SCIM endpoints:

Operation	Method	Endpoint
List users	GET	`/scim/v2/Users`
Get user	GET	`/scim/v2/Users/{id}`
Create user	POST	`/scim/v2/Users`
Update user	PUT / PATCH	`/scim/v2/Users/{id}`
Filter users by external identifier	GET	`/scim/v2/Users?filter=externalId eq "{value}"`
Deactivate / delete user	DELETE / PATCH	`/scim/v2/Users/{id}`
List groups	GET	`/scim/v2/Groups`
Create group	POST	`/scim/v2/Groups`
Update group	PUT / PATCH	`/scim/v2/Groups/{id}`
Delete group	DELETE	`/scim/v2/Groups/{id}`
Service discovery	GET	`/scim/v2/ServiceProviderConfig`

IBM Security Verify does not call the Groups endpoints. Group endpoints are used by Okta, Azure AD, and Ping Identity only.

Unique identifier and externalId

By default, Prizm matches users by email address. If your organization uses Override unique identifier to match users by a permanent attribute instead, SCIM must also supply that attribute’s value for every user. SCIM stores it in the user’s externalId field. When the value in externalId matches the value your identity provider (IdP) sends at login, SCIM-provisioned accounts and SSO logins resolve to the same Prizm user. This section walks through the setup from start to finish, using Microsoft Entra ID (Azure AD) as the example. The same approach applies to other IdPs.

How the pieces fit together

Three settings work together, and each holds a different thing:

Where	What it holds	Example
Prizm → Unique identifier	The attribute or claim name Prizm reads from the SAML assertion	`objectidentifier`
SAML assertion (sent by your IdP at login)	The claim, with the user’s identifier value	`d3f4a1b2-2025-4601-b9d1-58b039d0e789`
SCIM → `externalId`	The same identifier value, stored on the user at provisioning	`d3f4a1b2-2025-4601-b9d1-58b039d0e789`

The claim name lives in the Prizm UI only. The SCIM PATCH path is always externalId, whichever claim you choose.

Use externalId to set a user’s unique identifier. Prizm SCIM does not support externalAttribute1 for this. A request that uses it can return a success response, yet the value is not saved.

Before you begin

SAML SSO is configured for your IdP, and SCIM provisioning is set up as described above.
You have administrator access to Prizm and to your IdP.
You have the SCIM URL and bearer token. Examples below use the full /api/v1/auth/scim/v2 path, and the base is the SCIM URL under Organization → Security.

Choose the identifier

Pick an attribute that is unique to each user and never changes. Prizm accepts the name of any claim your IdP sends. These are the common Azure claims:

Claim name	Azure source	Suitability
`objectidentifier`	`user.objectid`	Recommended — stable GUID
`emailaddress`	`user.mail`	Possible, but the email address can change
`name`	`user.userprincipalname`	Possible, but the UPN can change
`givenname`	`user.givenname`	Not suitable — not unique
`surname`	`user.surname`	Not suitable — not unique

Set up the unique identifier

Send the claim from your IdP

Done by the IdP administrator.In Microsoft Entra ID, open the Prizm enterprise application and go to Manage → Single Sign-On → SAML. Add the claim you chose, for example objectidentifier with source attribute user.objectid, and save. The claim must be part of the SAML assertion, because Prizm reads it at login.

Configure Prizm

Done by the Prizm administrator.

Navigate to Organization → Security.
Turn on Override unique identifier and confirm the prompt.
In the Unique identifier field, enter the claim name, for example objectidentifier.
Click Update Configuration.

See Overriding the Unique Identifier for details.

Prizm uses externalId to look up users only while Override unique identifier is on. If it is off, Prizm does not use externalId for lookup, so turn it on before relying on externalId.

Send the identifier value through SCIM

Done by whoever manages provisioning.Send each user’s identifier value in externalId. Include it when you create a user, or update it on an existing one.

Existing user (PATCH)
New user (POST)

PATCH /api/v1/auth/scim/v2/Users/jane.doe@example.com

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "replace",
      "path": "externalId",
      "value": "d3f4a1b2-2025-4601-b9d1-58b039d0e789"
    }
  ]
}

POST /api/v1/auth/scim/v2/Users

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User"
  ],
  "externalId": "d3f4a1b2-2025-4601-b9d1-58b039d0e789",
  "userName": "jane.doe@example.com",
  "active": true,
  "name": {
    "givenName": "Jane",
    "familyName": "Doe"
  }
}

The value must be the same one your IdP sends in the selected claim for that user. For objectidentifier, that is the user’s Azure Object ID.

Verify the stored value

Retrieve the user and confirm externalId holds the expected value:

GET /api/v1/auth/scim/v2/Users/jane.doe@example.com

{
  "externalId": "d3f4a1b2-2025-4601-b9d1-58b039d0e789",
  "userName": "jane.doe@example.com"
}

If externalId is still null, see Troubleshooting below.

Test SSO login

Have the user sign in with SSO. Confirm they land on the same Prizm account that SCIM provisioned, which shows that the claim from the assertion and the SCIM identifier resolve to the same user.

Keep the identifier consistent

Use the same external identifier for every later SCIM create, update, and filter operation for that user.

Reference

SCIM fields

SCIM field	Purpose	Example
`userName`	Username or email that identifies the user in a request	`jane.doe@example.com`
`externalId`	The external unique identifier value	`d3f4a1b2-2025-4601-b9d1-58b039d0e789`
`id`	Prizm’s internal user identifier	System-generated UUID

Find a user by external identifier

GET /api/v1/auth/scim/v2/Users?filter=externalId%20eq%20%22d3f4a1b2-2025-4601-b9d1-58b039d0e789%22

Recommended configuration

Component	Recommended value
Prizm – Override unique identifier	On
Prizm – Unique identifier	`objectidentifier`
Azure source attribute	`user.objectid`
SCIM field	`externalId`
SCIM value	The user’s Azure Object ID (GUID)

Troubleshooting the unique identifier

Symptom	Likely cause	Fix
PATCH returns success, but `externalId` is still `null` on GET	The request used `externalAttribute1`, which Prizm SCIM does not support for this	Change the PATCH `path` to `externalId`
Prizm does not match users by `externalId`	Override unique identifier is off, so Prizm does not use `externalId` for lookup	Turn it on under Organization → Security and click Update Configuration
User is not found, or a second account appears after SSO login	The claim is missing from the SAML assertion, the claim name in Prizm does not match exactly, or the `externalId` differs from the claim’s value	Check the claim in the IdP, match the name under Organization → Security, and make both values identical
Identifier changes over time	A mutable claim such as email or UPN was chosen	Use a stable claim such as `objectidentifier`

Example of an incorrect request

This PATCH uses an unsupported field. Replace externalAttribute1 with externalId.

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "replace",
      "path": "externalAttribute1",
      "value": "d3f4a1b2-2025-4601-b9d1-58b039d0e789"
    }
  ]
}

​How it works

​Supported providers

​What SCIM manages

​Prerequisites

​Finding the SCIM URL

​Setup by provider

​Prerequisites

​Step 1 — Open SCIM provisioning in Okta

​Step 2 — Configure the SCIM endpoint

​Step 3 — Enable provisioning to app

​Step 4 — Map attributes

​Step 5 — Push groups (optional)

​Prerequisites

​Step 1 — Open provisioning in Entra ID

​Step 2 — Configure the SCIM endpoint

​Step 3 — Configure attribute mappings

​Step 4 — Set provisioning scope

​Step 5 — Start provisioning

​Prerequisites

​Step 1 — Open SCIM provisioning in Ping Identity

​Step 2 — Configure the SCIM endpoint

​Step 3 — Enable provisioning actions

​Step 4 — Map attributes

​Step 5 — Configure group provisioning and activate

​Prerequisites

​Step 1 — Open provisioning in IBM Security Verify

​Step 2 — Configure the SCIM endpoint

​Step 3 — Enable provisioning actions

​Step 4 — Map attributes

​Step 5 — Test and activate

​SCIM endpoints

​Unique identifier and externalId

​How the pieces fit together

​Before you begin

​Choose the identifier

​Set up the unique identifier

​Reference

​SCIM fields

​Find a user by external identifier

​Recommended configuration

​Troubleshooting the unique identifier

How it works

Supported providers

What SCIM manages

Prerequisites

Finding the SCIM URL

Setup by provider

Prerequisites

Step 1 — Open SCIM provisioning in Okta

Step 2 — Configure the SCIM endpoint

Step 3 — Enable provisioning to app

Step 4 — Map attributes

Step 5 — Push groups (optional)

Prerequisites

Step 1 — Open provisioning in Entra ID

Step 2 — Configure the SCIM endpoint

Step 3 — Configure attribute mappings

Step 4 — Set provisioning scope

Step 5 — Start provisioning

Prerequisites

Step 1 — Open SCIM provisioning in Ping Identity

Step 2 — Configure the SCIM endpoint

Step 3 — Enable provisioning actions

Step 4 — Map attributes

Step 5 — Configure group provisioning and activate

Prerequisites

Step 1 — Open provisioning in IBM Security Verify

Step 2 — Configure the SCIM endpoint

Step 3 — Enable provisioning actions

Step 4 — Map attributes

Step 5 — Test and activate

SCIM endpoints

Unique identifier and externalId

How the pieces fit together

Before you begin

Choose the identifier

Set up the unique identifier

Reference

SCIM fields

Find a user by external identifier

Recommended configuration

Troubleshooting the unique identifier