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 in to 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://api.beyondtrust.io/api/{organization-id}/platform/auth/scim/v2
Authentication Type	Bearer Token
Token	`SCIM_<token>`

Click Test Connection. Expect HTTP 200.

Step 2: Enable HTTP PATCH

Under the source's Additional Settings, select Use HTTP PATCH, then click Save.

BeyondTrust Pathfinder updates user and group information through SCIM PATCH requests ("patch":{"supported": true} in its /ServiceProviderConfig).
If you leave this option cleared, SailPoint Identity Security Cloud (ISC) replaces the whole record on every update instead. This can cause updates to fail for attributes that hold more than one value, such as email addresses or group memberships.

Step 3: Test the connection

Click Test Connection. Expect success.

Step 4: Discover and map the account schema

Run schema discovery on the source, then:

Change the type of both roles and entitlements to string.
Under Entitlement Types, delete both roles and entitlements.
Confirm Entitlement Types now lists only group.

Why: Pathfinder's own /Schemas document declares roles and entitlements on the User resource as mutability: writeOnly / returned: never.
They are accepted on write and forwarded downstream, but Pathfinder never persists or returns them, so there's nothing for ISC to aggregate back. Treating them as plain strings (rather than managed entitlement types) avoids failed aggregation attempts. Group membership is the only entitlement type Pathfinder currently exposes with a real backing endpoint (/Groups).

Step 5: Configure account correlation

Under Account Correlation, use email to correlate identities to accounts.

Step 6: Configure the Create Account form

Under the source's account creation mapping:

Map both userName and emails.work.primary.value to Work Email.
Map name.givenName and name.familyName to the identity's first/last name.
Set active to true by default for new accounts.

Test the integration

Rather than triggering individual SCIM calls directly, validate the integration through ISC's normal access-request lifecycle. This exercises account creation, entitlement aggregation, and group-membership provisioning together.

Aggregate. Run Accounts and Entitlements aggregation on the source. Both should complete successfully; SCIM groups display as entitlements.
Mark an entitlement requestable. Under the source's Entitlements list, mark at least one SCIM group as Requestable.
Create an Access Profile and add the SCIM group entitlement to it under Manage Entitlements.
Under the Access Profile's Access Requests settings, set requests to Allow, then enable the Access Profile.
Create an Application, add the Access Profile to it, and enable the application for users.
In Request Center, use Request for Others (must be enabled under Settings) to select the Pathfinder application and Access Profile for a test identity, then review and submit the request.
Confirm the access request completes successfully.
Verify the result:
- In ISC, the test identity's Access tab shows the new entitlement.
- In Pathfinder, under Administration, the user now exists.

Approving the access request is what drives the actual group-membership write: ISC issues a PATCH /Groups/{group_id} request adding the user to the group's members list. Pathfinder's Group.members attribute is read-write, while the groups attribute on the User resource is read-only. Group membership can only be changed from the Group side, which is exactly the flow this Access Profile/Application/Access Request path drives.

After provisioning: configure downstream module

Creating the user and SCIM group in Pathfinder doesn't automatically grant access in each product. Configure module-level permissions separately:

Pathfinder role: Adjust the identity's Pathfinder platform role and module permissions under Administration. This is distinct from the SCIM roles that individual modules populate later.
EPM for Windows & Mac: EPM roles can be assigned directly to SCIM groups.
PRA / Remote Support: Edit the Pathfinder Security Provider to manually add the SCIM group by name; it then becomes available as a policy member.
Password Safe: SCIM account and group support is planned but not yet available as of this writing — check current release notes before assuming parity with the other modules.

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://api.beyondtrust.io/api/{organization-id}/platform/auth/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

ℹ️
Okta defaults to PATCH active=false for deactivation, not DELETE. 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://api.beyondtrust.io/api/{organization-id}/platform/auth/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

ℹ️
Entra ID's default deprovisioning action is PATCH active=False, not DELETE. 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 ID 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.
SCIM-provisioned users are treated as federated only when their email domain matches a configured SAML provider in the org. Otherwise, they authenticate as local users even though SCIM manages their lifecycle.

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.