How to set up SSO and control workspace access
Connect the organisation to your identity provider, set the authentication policy, and scope access to architecture by workspace membership and role.
When this is useful
- A security review is asking how access is enforced, and "the interface hides it" is not going to be an acceptable answer.
- People are joining and leaving and you would rather that were handled by the identity provider than by a list somebody maintains here.
- Different parts of the estate should not be visible to each other.
Before you start
- Administrator access to the organisation. These are organisation-level settings, not per-diagram ones.
- From your identity provider: the OIDC discovery URL and a client id. Configure the provider side first — a half-configured provider produces a login loop rather than a clear error.
Step 1: Connect single sign-on
In the administration area, configure OIDC single sign-on with the discovery URL and client id from your identity provider. Once it is connected, joining and leaving are handled where they should be — in the directory, not here.
Step 2: Set the authentication policy
Multi-factor authentication and session timeout are organisation-level policy. Set them to what your security standard requires rather than to what is convenient — a long session on a tool holding architecture documentation is exactly the kind of thing a review picks up.
Step 3: Scope work to workspaces
Work is scoped to a workspace, and membership of that workspace is what grants access to what is in it. Put each part of the estate in the workspace whose members should be able to see it — this is the primary access boundary, not a filing convenience.
Step 4: Separate the roles
Roles separate viewing, editing, approving and administering. Keep them separate in practice as well as in configuration — approval means very little as a control if the people approving are the people who made the change.
On individual diagrams, collaborator access is the finer-grained layer on top of workspace membership.
Diagram ▸ Team & collaboratorsDiagram ▸ Approval workflow
Step 5: Know what the answer to the security review is
Access is enforced by row-level security on every table, keyed on workspace membership, rather than by filtering in the application. A request that should not return a row does not return it regardless of what the client asks for — the interface is not the thing standing between a user and someone else’s data.
That is the answer worth giving a reviewer, because it is the one that holds when the client is not your interface.
What happens next
Access follows the directory. Someone who leaves the organisation loses access when their directory account is disabled, without anyone remembering to do anything here.
The audit log records what happened, which is the other half of what a security review asks for — enforcement and evidence.
Example
An organisation with a regulated business unit whose architecture the rest of the company should not see. A separate workspace, membership through the identity provider, MFA required, and row-level security doing the enforcement — rather than a naming convention and a request that people not look.
Tips
- Configure the identity provider before touching the settings here. Almost every SSO problem is a mismatched redirect URI on the provider side.
- Set MFA and session policy at the same time as SSO. Coming back to them later means a period where the standard is not actually met, and that period tends to be long.
- Give approval rights to people who did not write the design. It is the only thing that makes the approval a control rather than a formality.
Limitations
- These are organisation-level settings and require administrator access. Individual users cannot change authentication or session policy.
- Single sign-on requires an OIDC-capable identity provider.