SCIM provisioning | Pathfinder
SCIM 2.0 provisioning lets Pathfinder automate user and group lifecycle management from an external identity provider. Instead of creating and maintaining users manually, administrators can connect Pathfinder to a SCIM-capable identity provider and let that provider create, update, deactivate, and manage assigned users.
SCIM provisioning complements, but does not replace, authentication methods such as SAML or AD/LDAP. In a typical deployment, the identity provider provisions the account with SCIM and the user authenticates with SSO.
Prerequisites
- Administrator access in Pathfinder
- Confirm your IdP supports SCIM 2.0 client provisioning
- Confirm if you will provision users only, or users and groups.
- If you plan to use SAML for sign-in, confirm your SAML configuration is complete or planned.
Supported IdPs
- Okta
- Microsoft Entra ID
- SailPoint IdentityNow
Generate a SCIM token
- Sign into app.beyondtrust.io.
The BeyondTrust Home page displays. - Select your site name to display a drop-down menu.
- Select Administration.
The BeyondTrust Platform Administration page displays. - Select ☰ > Administration > SCIM Tokens.
The SCIM Tokens page displays. - Enter a name.
- Select an expiration date from the list.
- Click Create Token.
Important
Treat the SCIM token like a secret. Store it securely and rotate it according to your organization's credential management standards.
Configure the SCIM connector
SailPoint IdentityNow
Step 1: Create a SCIM 2.0 source
In the SailPoint admin console: Admin → Connections → Sources → Create → SCIM 2.0
| Option | Value |
|---|---|
| Source Name | BeyondTrust Nomine (Test) |
| SCIM Base URL | https://<cloudfront-distribution>.cloudfront.net/scim/v2 |
| Authentication Type | Bearer Token |
| Token | SCIM_<token> |
| Unique Identifier Attribute | userName |
Click Test Connection. Expect HTTP 200.
Step 2: Configure provisioning policies
Under the source's Provisioning Policies tab, enable and configure:
| Policy | Purpose |
|---|---|
| Create Account | Triggers POST /scim/v2/Users |
| Update Account | Triggers PUT /scim/v2/Users/{id} |
| Delete Account | Triggers DELETE /scim/v2/Users/{id} |
| Disable Account | Triggers PATCH active=false |
| Enable Account | Triggers PATCH active=true |
Map the following attributes in each policy: userName (email), name.givenName, name.familyName, active, roles.
Step 3: Trigger each SCIM operation
| Operation | IDP Action |
|---|---|
POST /scim/v2/Users | Assign an identity to the source via Identity → Provisioning → Add Entitlement, or trigger a lifecycle state change that targets this source |
PUT /scim/v2/Users/{id} | Edit an identity's attributes (e.g. last name) in SailPoint → SailPoint detects the delta and sends a full replace |
PATCH active=false | Set the identity's lifecycle state to Terminated or Inactive (whichever is mapped to disable on this source), or manually click Disable Account on the account |
PATCH roles | Change the identity's role/entitlement assignment for this source in SailPoint |
DELETE /scim/v2/Users/{id} | Set lifecycle state to one that triggers deprovision + delete, or click Delete Account on the account under the source |
Use Admin → Identities → [identity] → Accounts → [this source] → Manage to manually trigger individual operations without changing lifecycle state.
Step 4: Force a sync
To trigger provisioning immediately rather than waiting for the scheduled cycle:
Admin → Connections → Sources → [source] → Accounts → Refresh
Or for a single identity: Identity → Provisioning → Refresh
Okta
Step 1: Create a SCIM app in Okta
In Okta Admin: Applications → Browse App Catalog → search "SCIM 2.0 Test App (Bearer Token)" → Add Integration
If the catalog app is not available, create a custom app:
Applications → Create App Integration → SWA → after creation, enable SCIM under the Provisioning tab.
Step 2: Configure the SCIM connector
Under the app's Provisioning → Integration tab:
| Option | Value |
|---|---|
| SCIM connector base URL | https://<cloudfront-distribution>.cloudfront.net/scim/v2 |
| Unique identifier field for users | userName |
| Authentication Mode | HTTP Header |
| Authorization | Bearer SCIM_<token> |
Click Test API Credentials — expect success.
Step 3: Enable provisioning operations
Under Provisioning → To App, enable:
| Setting | Triggers |
|---|---|
| Create Users | POST /scim/v2/Users |
| Update User Attributes | PUT /scim/v2/Users/{id} |
| Deactivate Users | PATCH active=false |
Step 4: Configure attribute mappings
Under Provisioning → To App → Attribute Mappings, ensure these are mapped:
| Okta attribute | SCIM attribute |
|---|---|
user.login | userName |
user.firstName | name.givenName |
user.lastName | name.familyName |
user.email | emails[primary eq true].value |
| App-level role or group | roles (map to a custom attribute or group push) |
Step 5: Trigger each SCIM operation
| Operation | IdP Action |
|---|---|
POST /scim/v2/Users | Assignments → Assign → Assign to People → select a user → Save. Okta provisions immediately if auto-provisioning is on, or click Push Now |
PUT /scim/v2/Users/{id} | Edit the assigned user's profile (e.g. last name) in Okta. Okta sends a full PUT on the next push cycle, or force with Push Now |
PATCH active=false (deactivation) | Assignments → [user] → Unassign, or go to the user's Okta profile and Suspend or Deactivate the user. Requires "Deactivate Users" enabled in Step 3 |
PATCH active=true (reactivation) | Re-assign the user to the app, or reactivate/unsuspend the user in Okta |
PATCH roles | Change the user's group membership or app-level role in Okta (if roles are mapped via group push) |
DELETE /scim/v2/Users/{id} | Okta sends DELETE only if the app is configured to delete (not just deactivate) on removal. Go to Provisioning → To App → Deactivate Users and set the option to Delete instead of deactivate, then unassign the user |
Note
Okta defaults to
PATCH active=falsefor deactivation, notDELETE. To get a hard delete, the app provisioning option must explicitly be set to delete.
Step 6: Force a sync
To trigger provisioning immediately:
- Per-user: Assignments → [user] → Push Now
- All users: Push Now button on the Assignments tab
Microsoft Entra ID
Step 1: Create an enterprise application
In Azure Portal: Entra ID → Enterprise Applications → New Application → Create your own application
- Name:
BeyondTrust Nomine SCIM (Test) - Select: "Integrate any other application you don't find in the gallery"
Step 2: Configure the SCIM provisioning connector
Under the app: Provisioning → Get started → Provisioning Mode: Automatic
Under Admin Credentials:
| Option | Value |
|---|---|
| Tenant URL | https://<cloudfront-distribution>.cloudfront.net/scim/v2 |
| Secret Token | SCIM_<token> |
Click Test Connection — expect success. Save.
Step 3: Configure attribute mappings
Under Provisioning → Mappings:
Provision Azure Active Directory Users — ensure these are active:
| Azure AD attribute | SCIM attribute |
|---|---|
userPrincipalName | userName |
givenName | name.givenName |
surname | name.familyName |
mail | emails[type eq "work"].value |
accountEnabled | active |
Provision Azure Active Directory Groups — ensure this mapping is active (required for group sync).
Step 4: Configure scope and settings
Under Provisioning → Settings:
| Setting | Recommended value |
|---|---|
| Provisioning Scope | Sync only assigned users and groups |
| Notification Email | your test email |
Step 5: Assign users and groups to the app
Under Users and Groups → Add user/group:
- Assign individual users to test user operations
- Assign groups to test group sync operations
Step 6: Trigger each SCIM operation
| Operation | IdP action |
|---|---|
POST /scim/v2/Users | Assign a user to the app under Users and Groups → use Provision on demand (see Step 7) to trigger immediately |
PUT or PATCH /scim/v2/Users/{id} | Edit the user's profile attributes in Azure AD (e.g. surname) → use Provision on demand to push the change immediately |
PATCH active=False (deactivation) | Block sign-in for the user in Azure AD (accountEnabled = false), or remove the user from the app assignment. Use Provision on demand to trigger immediately |
PATCH active=True (reactivation) | Re-enable the user in Azure AD or re-assign to the app |
DELETE /scim/v2/Users/{id} | Hard-delete the user from Azure AD, or configure the provisioning app to delete on removal under Provisioning → Settings → Action when out of scope |
POST /scim/v2/Groups | Assign a group (not just user) to the app under Users and Groups → Entra creates the group in the target via POST /scim/v2/Groups |
PATCH /scim/v2/Groups — add member | Add a user to the Entra group that is assigned to the app |
PATCH /scim/v2/Groups — remove member | Remove a user from the Entra group that is assigned to the app |
Note
Entra's default deprovisioning action is
PATCH active=False, notDELETE. To get a hard delete, go to Provisioning → Settings → Action when out of scope and set to Delete.
Step 7: Provision on demand (recommended for testing)
Rather than waiting for the 40-minute auto-sync cycle, use Provision on demand to test a specific user or group immediately:
Provisioning → Provision on demand → select user or group → Provision
Entra shows the full provisioning log including the exact SCIM request and response — useful for debugging.
Supported provisioning operations
| Action | Object type | Description |
|---|---|---|
| Create | User | Creates a new Pathfinder user when the user is assigned from the identity provider. |
| Update | User | Updates supported user attributes such as name or email address. |
| Deactivate | User | Disables a user in Pathfinder when the assignment is removed or the user is deprovisioned. |
| Create or update | Group | Creates or maintains groups and membership information where group provisioning is supported. |
| Remove | Group | Removes group relationships or group objects where supported by the implementation. |
User lifecycle behavior
SCIM-provisioned users are managed primarily from the external identity provider.
- When a user is assigned in the identity provider, Pathfinder creates the user record.
- When user attributes change in the identity provider, Pathfinder updates the corresponding attributes.
- When the user is unassigned or deprovisioned, Pathfinder deactivates the account based on supported behavior.
Existing users and identity conflicts
If a SCIM-provisioned user matches an existing Pathfinder account, Pathfinder may attempt to link the record or may require administrator review, depending on the implementation.
Review duplicate or conflicting accounts before broad rollout.
Group provisioning
If group provisioning is supported, the IdP can send group objects and membership changes to Pathfinder.
- Use groups to simplify assignment and access management.
- Review how Pathfinder maps provisioned groups to roles, permissions, or application access.
- Confirm whether nested groups are supported in your release and provider combination.
