Skip to main content

SCIM provisioning

Sync user and group changes from your identity provider to TridentStack Control automatically. Disable a user in your IdP, they lose Control access immediately. No more manual offboarding. Group memberships sync, which keeps role assignments aligned with your IdP.

Before you begin​

You will need:

  • SAML SSO configured first (see Single sign-on (SAML)). SCIM and SSO work together: SSO authenticates users, SCIM keeps the user list in sync.
  • A TridentStack Control admin account.
  • Permission in your IdP to configure SCIM provisioning.

Setup overview​

  1. Generate a SCIM token in TridentStack Control (shown once, save it).
  2. Configure SCIM in your IdP using the SCIM base URL and the token.
  3. Map IdP attributes to TridentStack Control fields.
  4. Push your IdP groups (use the same group names you mapped in the SSO setup).
  5. Test by deactivating a test user in the IdP and confirming they appear inactive in Control.

Step 1: Generate a SCIM token​

In TridentStack Control, go to Settings -> Authentication -> SCIM Provisioning. Click Generate token, give it a descriptive name (e.g. "Okta SCIM"), and click Generate.

The token is shown once. Copy it now and save it somewhere safe (your IdP's secret manager or a password manager). For security, TridentStack Control never displays the full token again. If you lose it, revoke the token and generate a new one.

The same panel shows the SCIM Base URL you will need. Use the value shown in Settings. The base URL itself is not a SCIM resource. To test the connection directly, send a request to <SCIM Base URL>/ServiceProviderConfig with the SCIM bearer token.

Step 2: Configure SCIM in your IdP​

Okta​

  1. Open your TridentStack Control app in Okta admin.
  2. Provisioning -> Configure API Integration. Check "Enable API integration".
  3. Paste the SCIM Base URL into "Base URL".
  4. Paste the SCIM token into "API Token".
  5. Click Test API Credentials then Save.
  6. Provisioning -> To App. Enable "Create Users", "Update User Attributes", and "Deactivate Users".
  7. Under Push Groups, add the groups you want synced (typically the same ones you map to roles in TridentStack Control).

Microsoft Entra ID​

  1. In your TridentStack Control enterprise application, Provisioning -> Get started.
  2. Set Provisioning Mode to Automatic.
  3. Tenant URL: paste the SCIM Base URL.
  4. Secret Token: paste the SCIM token.
  5. Click Test Connection, then Save.
  6. Under Mappings, configure the User and Group attribute mappings (the defaults work for most setups).
  7. Set provisioning scope to "Sync only assigned users and groups" (recommended) and turn provisioning On.

JumpCloud​

  1. Open your TridentStack Control SSO app in JumpCloud admin.
  2. Identity Management -> Set up Identity Management, choose SCIM Version 2.0.
  3. Paste the SCIM Base URL as the API URL.
  4. Paste the SCIM token as the bearer token.
  5. Save and enable user/group provisioning.

Step 3: Map attributes​

The default attribute mappings work for most setups:

  • userName identifies the user for matching and is kept separate from the work email.
  • emails[type eq "work"].value maps to the user's work email, which becomes their TridentStack Control sign-in email.
  • externalId maps to your IdP's stable user ID (used to detect renames).
  • active maps to your IdP's user-status flag.
  • displayName maps to the user's full name.
  • groups maps to group memberships.

The most important mapping is groups: the group names your IdP pushes must match the IdP group names you configured in the SSO group-to-role mapping.

TridentStack Control matches an incoming user by userName. For accounts created before SCIM provisioning was set up, it can fall back to matching the user's email. If a user's email changes in your IdP, provisioning updates their TridentStack Control sign-in email while keeping userName separate.

For Microsoft Entra ID, a user who already signs in with SSO may have a user principal name that differs from their email. Set the matching attribute to the work email, emails[type eq "work"].value, so provisioning matches the existing account.

Provisioning creates new users only for domains that belong to your organization: your primary domain or a verified sign-in domain. An administrator must create an account first for someone using another domain.

Step 4: Push groups​

Push the groups your team uses in TridentStack Control. When a user joins or leaves an IdP group:

  • Their TridentStack Control role updates automatically (per the SSO group-to-role mapping).
  • Manual role assignments (granted directly in TridentStack Control, not via the mapping) are preserved.

Group roles from provisioning and groups sent during SSO sign-in are tracked separately, and a user keeps a role while either source grants it. Removing a user from a group in your IdP takes effect at once, even if the user's last SSO sign-in also listed that group. If your IdP still sends the group at the user's next sign-in, the role returns.

Step 5: Test deactivation​

The most important sync to verify is offboarding:

  1. In your IdP, mark a test user as inactive (or unassign them from the TridentStack Control app).
  2. Wait up to 60 seconds for your IdP to push the change.
  3. In TridentStack Control, go to Settings -> User Management and confirm the test user shows inactive.
  4. The user's existing browser sessions are invalidated; their next request returns to the sign-in page.
  5. Reactivate them in your IdP and confirm they reactivate in TridentStack Control.

What gets synced​

  • Users: created, updated, deactivated, reactivated.
  • Group memberships: drive role assignments via the SSO group-to-role mapping.
  • Display name and email: kept in sync from your IdP.

What does NOT sync:

  • Passwords: TridentStack Control does not store passwords. Authentication is via SAML SSO.
  • Tenant settings, agent configurations, policies, deployment rings: managed in TridentStack Control.

What happens during deactivation​

When your IdP marks a user inactive (via SCIM active=false or by removing them from the app):

  • The user is marked inactive in TridentStack Control.
  • Their active browser sessions end immediately.
  • IdP-mapped roles are removed.
  • Manual role assignments are preserved in case you reactivate them later.
  • The user's audit history is preserved.

Break-glass admins cannot be deactivated or deleted through provisioning, and their email cannot be changed through provisioning. Remove an admin from the break-glass admin list in TridentStack Control before making those changes. A user deleted in your IdP can be provisioned again later and returns as the same TridentStack Control account.

Token rotation and revocation​

To rotate a token:

  1. Generate a new token in TridentStack Control.
  2. Paste the new token into your IdP's SCIM configuration. Save and test.
  3. Once your IdP is using the new token, revoke the old one in TridentStack Control.

To revoke without rotation:

  • Click Revoke next to the token. The token stops working immediately. Any IdP using it will need a new token to resume sync.

Limits and troubleshooting​

Rate limit: 60 requests per minute per token (with a small burst allowance). This is well above what any standard IdP needs for normal sync.

Common errors:

  • 401 Invalid or revoked token: your IdP is using a stale or revoked token. Generate a new one and update the IdP.
  • 400 invalidFilter: your IdP sent a SCIM filter that uses an unsupported attribute. Most IdPs work fine; if you hit this with a specific provider, contact support with the filter string.
  • Sync stops working without errors: check the Last Used column in the SCIM Provisioning panel; if it has not updated recently, your IdP is not pushing. Re-test the connection in your IdP's admin console.

For anything not covered here, contact TridentStack support at tridentstack.com/dashboard/support.