Identity & Provisioning (SCIM)

Scrydon supports SCIM 2.0 (System for Cross-domain Identity Management) so your identity provider can automatically create, update, and deactivate users in Scrydon — and keep group membership in sync — without any manual admin work on the Scrydon side.

What SCIM does

Nested groups

SCIM groups in Scrydon can contain other groups as members, not just users. Scrydon flattens the effective membership when syncing to a Scrydon team:

• A team always shows the effective user list — direct users plus transitive users from any nested sub-groups.
• Nesting is supported up to 3 levels deep (parent → child → grandchild).
• Cycles (group A contains group B, which contains group A) are rejected.
• When you update a nested group's membership, all parent groups that contain it are re-synced on the next operation.

What SCIM does not do

• Does not change usernames or emails. If an identity's email needs to change, deprovision and reprovision the user instead. (Same policy as Databricks, Snowflake, and most enterprise targets.)
• Does not rename existing teams. If you rename a group in your IdP, the linked Scrydon Team keeps its original name. Rename the team directly in Scrydon if you want to change it.
• Does not sync service principals / machine accounts. Only human identities. Create service accounts directly in Scrydon.
• Does not delete user records on deprovisioning. Users are deactivated (banned + sessions revoked + org membership removed) but the underlying user row is preserved so audit history and owned resources stay intact. If the same user is re-provisioned later (a rehire, for instance), Scrydon automatically reactivates the existing record rather than creating a duplicate.

Prerequisites

1. Org admin role — only org admins can generate or revoke SCIM tokens.
2. SSO already configured — SCIM and SSO are complementary, not replacements. Users provisioned via SCIM still sign in via your SSO flow.
3. One of the supported IdPs — this release covers Microsoft Entra ID (Azure AD), Okta, and OneLogin. Any RFC 7644-compliant SCIM 2.0 IdP should work, but those three are the ones we test against.

Choose your identity provider

Scale limits

Scrydon enforces per-organization caps to protect shared infrastructure from runaway provisioning. If your organization needs higher limits, contact support — these are guardrails, not architectural ceilings.

How deprovisioning works

When a user is removed from the Scrydon app in your IdP (or the IdP marks them as inactive), Scrydon performs a soft delete:

1. The user account is banned — they cannot sign in again via any method (SSO, magic link, passkey).
2. All active sessions are revoked immediately. Any open Scrydon tabs become unauthenticated on next action.
3. The user is removed from the organization, which terminates their access to all workspaces, integrations, and data in that org.
4. The underlying user record is preserved, so audit history, owned resources, and compliance trails remain intact.

If the user is re-added in the IdP later, SCIM re-provisioning will reactivate the same record — the same userId is used, so audit history is continuous.

Token security

SCIM tokens are sensitive credentials and must be handled like passwords or API keys. The raw token is shown to you exactly once at generation time — copy it immediately into your IdP's SCIM configuration or a secret manager. If you lose a token, generate a new one and revoke the old one.

Tokens are stored in the Scrydon database hashed (SHA-256) for verification, alongside the raw value which is currently kept so that tokens can be displayed again in the admin UI after creation. Encryption at rest via the Scrydon secrets vault is on the roadmap but not yet enabled in this release — treat token access in the database with the same care as any credential store.

We recommend creating separate named tokens per IdP environment — for example entra-prod and entra-staging — so you can rotate or revoke independently.

Audit logging

Every SCIM action is recorded in Scrydon's audit log:

• Token generation and revocation (with the org admin who performed the action)
• User provisioning, linking, updates, and deprovisioning
• Group creation, member additions, member removals, and deletion
• Any rejected SCIM calls (invalid token, email conflict, scale cap hit)

View the audit log in Settings → Platform → Audit Logs. Filter on the event prefix scim.* to see only SCIM-related entries. The full list of events lives in the audit events catalogue.

Related

• Hard fencing — restrict system credentials to the workspace's members via an IdP security group.
• SCIM operations — runbooks for scale caps, throttling, drift, and rotation.
• Audit events catalogue — every event the platform emits.