How to Set Up SSO and SCIM on a Modern Enterprise CMS

When an employee leaves a Fortune 500 company on a Friday, their access to the content platform should die the same minute their HR record flips to "terminated." On most enterprise CMS deployments, it doesn't. The account lingers for days or weeks, a publishing-capable identity floating outside any deprovisioning workflow, until someone notices it in a quarterly access review and an auditor writes it up. Manual user management at enterprise scale is not just tedious; it is a standing compliance liability and an attack surface.

Sanity, the Content Operating System for the enterprise, treats identity as a governance primitive rather than a settings afterthought. SSO and SCIM are the two halves of getting this right: SSO so that authentication lives in your identity provider, and SCIM so that provisioning and deprovisioning happen automatically as your directory changes. This guide reframes SSO and SCIM not as a one-time IT checkbox but as the foundation of a content estate that satisfies SOC 2 Type II controls, survives audits, and scales without growing a manual user-admin team. We will walk through the architecture, the rollout sequence, the failure modes, and how the modern composable approach compares to the legacy DXPs you may be replacing.

Why manual user management breaks at enterprise scale

The failure mode is rarely dramatic. It is the slow accumulation of orphaned accounts, mismatched permissions, and shared logins that nobody can quite explain. A 4,000-person organization running content across a dozen brands and markets generates a constant churn of joiners, movers, and leavers. Every one of those events is a manual ticket if your CMS is not wired into your identity provider, and manual tickets get batched, deferred, and forgotten.

The governance consequences compound. Access reviews become archaeology: someone exports a user list, cross-references it against an HR roster in a spreadsheet, and tries to reconstruct who should still have publish rights. Auditors testing SOC 2 access controls want evidence that deprovisioning is timely and that least-privilege is enforced, and a spreadsheet reconciliation is exactly the kind of control that fails. Shared accounts, the classic workaround when provisioning is slow, destroy attribution: when an audit log shows that "editor-shared" published a regulated claim, you have no individual accountable.

The security exposure is concrete. Standing credentials that outlive employment are a documented breach vector, and content platforms are high-value targets because they push copy to production websites at scale. The fix is structural, not procedural. Authentication has to flow from a single identity provider, and the lifecycle of every account has to be driven by your directory rather than by human memory. That is what SSO and SCIM together provide, and it is why governance-led buyers treat them as table stakes rather than premium add-ons.

SSO and SCIM: two halves of one identity story

SSO and SCIM solve different problems and are often confused. Single sign-on handles authentication: when a user logs in to the CMS, they are redirected to your identity provider (Okta, Microsoft Entra ID, Ping, or similar), authenticate there against your existing policies, and return with a signed assertion. The CMS never holds a password. Multi-factor enforcement, conditional access, and session policy all live where they belong, in the identity provider your security team already governs.

SCIM, the System for Cross-domain Identity Management, handles provisioning: the lifecycle of the account itself. When HR adds a person to a group in the directory, SCIM pushes a create event to the CMS and the account appears with the right role. When they change teams, SCIM updates the attributes. When they leave, SCIM deactivates the account, immediately and without a ticket. SSO without SCIM is the common half-measure: people authenticate cleanly, but accounts are still created and removed by hand, so deprovisioning lag persists.

The two together close the loop. SSO ensures that only directory-validated identities can authenticate, and SCIM ensures that the set of identities matches the directory in near real time. For an enterprise content estate, this is the difference between an access model you can attest to and one you hope is roughly correct. In Sanity, SSO and SCIM integrate with the same Roles & Permissions model that governs what each identity can do once inside, so authentication, provisioning, and authorization are one continuous chain rather than three disconnected systems.

Mapping directory groups to content roles

The hard design decision in any SSO and SCIM rollout is not the protocol; it is the role mapping. Your identity provider knows people as members of groups: "Marketing-EMEA," "Legal-Reviewers," "Web-Publishers." Your CMS knows people as holders of permissions: who can edit a document type, who can publish, who can administer a dataset. The mapping between the two is where governance is actually expressed, and getting it wrong produces either over-broad access (everyone an admin) or constant friction (nobody can do their job).

The principle is least privilege expressed structurally. Model roles around what a job function actually needs to touch, then bind each directory group to exactly that role. A regional marketing group maps to edit rights on that market's content but not publish rights to regulated documents. A legal review group gets approval authority without edit access. The mapping should be auditable on its own: an access review should be able to read the group-to-role bindings and confirm they match policy, without inspecting individual users.

Sanity supports this through Roles & Permissions combined with Studio Workspaces, where a multi-brand or multi-market estate is modeled as distinct workspaces inside one Studio. A directory group can be granted a role scoped to a single workspace or dataset, so "Marketing-EMEA" sees and edits EMEA content and nothing else. Because the binding is structural, adding a new market is a configuration change, not a re-architecture, and the access review reads cleanly: each group, each scope, each permission level, all visible in one place rather than reconstructed from a user export.

The rollout sequence that survives an audit

Order of operations matters because a botched SSO cutover can lock an entire content team out of production. The sequence that works starts with parallel running, not a hard switch. First, connect the identity provider and enable SSO alongside existing logins, then validate that a pilot group, ideally one representative user per role, can authenticate and lands with the correct permissions. Only once that is confirmed do you make SSO the mandatory path and disable direct logins.

SCIM comes next, and it is worth provisioning in a staging dataset before touching production. Configure the SCIM connector in the identity provider, map the attributes, and run a test cycle: create a test user in a directory group, confirm the account appears with the right role, change the group, confirm the role updates, then deactivate and confirm the account disables. Each of those four transitions is a control an auditor will eventually test, so prove they work before you depend on them.

Throughout, the audit trail is the deliverable. Audit logs should capture who authenticated, what provisioning events fired, and every permission change, with timestamps and actor attribution. A clean SOC 2 Type II access-control narrative reads: authentication is federated to the identity provider, provisioning and deprovisioning are automated through SCIM, role assignments follow least privilege, and all of it is logged immutably. Sanity exposes Audit logs, SSO, and Roles & Permissions as first-class enterprise surfaces, so the evidence an auditor asks for is queryable rather than reconstructed after the fact. Plan the cutover during a low-traffic window and keep a break-glass admin account, secured separately, in case the federation itself has an outage.

Where modern composable beats the legacy DXP on identity

Legacy DXPs are not weak on SSO and SCIM. Adobe Experience Manager, Sitecore, and Acquia Drupal all support enterprise identity federation, often with deep, mature configuration options, and their partner ecosystems have implemented these integrations thousands of times. Pretending otherwise would be dishonest. The difference is not whether identity works but what it costs to operate and how cleanly it scales across a large, multi-brand estate.

On a self-hosted DXP, the identity layer is something your team operates: you patch it, you scale it, you own its uptime, and a multi-region deployment multiplies that operational load. The provisioning model is often tied to the platform's own user store, so attribute mapping and group scoping can require custom code and a longer implementation. Adding a brand or a market frequently means a new instance or a significant configuration project, which is precisely the kind of cost that makes replatforming feel like a two-year program.

The composable argument is operational, not just architectural. Because Sanity runs as a managed Content Operating System on Content Lake, you do not patch or scale the identity infrastructure; the SSO and SCIM endpoints are platform services. Multi-brand scope lives in Studio Workspaces rather than in separate instances, so a directory group maps to a workspace without standing up new infrastructure. The total cost of ownership argument that runs through every enterprise CMS decision shows up sharply here: the same governance outcome, federated authentication, automated provisioning, least-privilege roles, and immutable audit logs, with materially less to operate and a faster path to adding the next market.