Skip to content

Products

Compliance Officer Service Expert-led compliance, end to end Compliance Portal Share security documents securely Open-source platform Deploy Probo on your own infrastructure

Resources

Probo stories How teams get compliant with Probo Blog Ideas and guidance from the Probo team Guides & tools Practical compliance guides and free tools Love from Customers What customers say about working with Probo Changelog Latest product updates Download Get the Probo Agent

Company

About The people and vision powering Probo Careers Join the team building Probo Brand assets Official logos and visual resources Security Review our security and compliance posture
Overview Understand Probo and its core concepts Product Explore Probo's GRC capabilities Developers Explore GraphQL, CLI, MCP, n8n, and webhooks Deployment Probo Cloud, self-hosting, and configuration

Explore

GitHub Explore our open-source compliance tools

SCIM provisioning

Learn how Probo's SCIM provisioning works, comparing Native (push) with Bridge (pull) synchronization, tokens, and events.

View as Markdown

Probo supports SCIM 2.0 for automating user lifecycle changes. SCIM provisioning manages user records and organization access; SAML SSO handles authentication. New people usually receive the Employee membership role — set a different role in People. For attribute-driven roles at sign-in without SCIM managing the profile, use the SAML Role Attribute.

Probo offers two ways to keep organization people in sync with your directory. Both end at the same SCIM Users resource; they differ in who initiates the change.

Aspect Native SCIM Bridge
When to use Provider has solid SCIM push support Provider does not support SCIM, or supports it poorly
Direction Push — the identity provider calls Probo Pull — Probo reads the directory
Timing Near real time on assignment changes Periodic reconciliation on a schedule
Typical providers Okta Google Workspace, Microsoft 365 / Entra ID
Who is synced Whoever you assign to the Probo app in the IdP Directory users, minus Bridge exclusions (for example service accounts or shared mailboxes)

The provider pushes changes directly to Probo. This is the standard IdP → app pattern when the provider can push SCIM reliably: when someone is assigned to the Probo application (or removed), the provider sends SCIM create, update, or deactivate requests to Probo’s endpoint. Okta is the primary Native path.

For Microsoft Entra ID, prefer SCIM Bridge over Native push — both paths are documented on that page.

sequenceDiagram
  participant IdP as Identity provider
  participant SCIM as Probo SCIM endpoint
  participant People as Organization people

  Note over IdP: Assignment changes
  IdP->>+SCIM: SCIM create / update / deactivate
  SCIM->>People: Apply change
  SCIM-->>-IdP: Result
  Note over IdP,People: The provider pushes each change as it happens
The identity provider pushes each SCIM operation to Probo as assignments change.

The Bridge covers providers that do not support SCIM or support it poorly — including Microsoft Entra ID, where Bridge is recommended (Native remains available). Instead of waiting for the IdP to push, Probo connects to a supported directory, reads users on a schedule, and reconciles them with organization people through the same SCIM path. Use exclusions to keep identities you do not want in Probo out of the sync.

sequenceDiagram
  participant Dir as Directory
  participant Bridge as Probo Bridge
  participant SCIM as Probo SCIM endpoint
  participant People as Organization people

  Note over Bridge: Runs on a schedule
  Bridge->>+Dir: Read users
  Dir-->>-Bridge: Directory snapshot
  Bridge->>Bridge: Drop excluded identities
  Bridge->>Bridge: Diff against current people
  Bridge->>+SCIM: SCIM create / update / deactivate
  SCIM->>People: Apply changes
  SCIM-->>-Bridge: Result
  Note over Bridge,People: Probo pulls and reconciles each cycle
Each Bridge cycle reads the directory, applies exclusions, diffs against Probo people, and writes create, update, or deactivate through SCIM.

Choose one authoritative mode for a population. Running overlapping push and pull automation without a clear owner can cause repeated or conflicting changes.

SCIM requests use the /api/connect/v1/scim/2.0 endpoint and a bearer token created for a SCIM configuration. The Users resource supports standard create, read, list, replace, patch, and delete operations implemented by the deployment.

The token is a provisioning credential, not a personal API key. Store it in the identity provider’s secret storage, do not log it, and regenerate it when access changes or disclosure is suspected.

SCIM events preserve request outcomes for operational review and export. Monitor failed events and bridge status rather than assuming directory changes were applied. Before removing a large assignment group, confirm how the provider represents deactivation and deletion and test with a limited population.

Provider-specific setup pages for Google Workspace, Microsoft 365, and Okta remain available separately.