Identity

What it is#

Identity is where your IT team connects the two systems that decide who exists here. Single sign-on routes your people through your own identity provider. Directory lets that provider create, update and — the part an auditor tests — deactivate accounts here without anybody remembering to do it.

They are two tabs on one screen because they are one decision, and because a workspace that has connected Okta for sign-in but not for provisioning is exactly the half-finished state this page has to make visible.

How to get there#

Security → Identity in the admin console. Everything on both tabs, read and write, is gated on security.policy.

Each half is also gated twice per tenant, and both gates are re-checked on every request rather than once at setup:

Both flags are off everywhere until somebody has walked the configuration with you. That is deliberate: a misconfigured directory connector's first act is to remove everybody it cannot see.

How to use it#

Connect an identity provider#

1. Single sign-on → Connect a provider.
2. Name is what your people see on the sign-in button.
3. Issuer URL is the provider's OIDC issuer — its discovery document sits under it. Okta, Entra ID, Google Workspace, Auth0, Ping and Keycloak all work.
4. Paste the Client ID and Client secret. The secret is stored sealed and never shown again; leaving it blank on a later edit keeps the one on file.
5. List your Email domains, one per line.
6. Before saving, add the redirect URI the screen shows as a redirect URI in the provider.

Verify your domains#

1. Until every domain verifies, the configuration routes nobody and the status stays Pending. The verification card is shown first while that is true.
2. Publish the TXT record the card displays on each domain.
3. Press Check DNS. Each domain says Record found or *Record not found yet*. DNS can take up to an hour, so "not yet" is usually a wait rather than a mistake.

Decide whether a password is still accepted#

On the Enforcement card, once the status is Active:

1. Optional — people may use single sign-on or a password.
2. Required — passwords are refused for anyone on a verified domain.
3. Required, with exceptions — passwords are refused except for the break-glass addresses you list underneath. Use these when the provider itself is unreachable.

Set what happens to a new person#

1. Create members on first sign-in turns just-in-time provisioning on. Off means only people already invited can use single sign-on.
2. Role for new members is what the provider's users get when it creates them here.
3. Attribute mapping says which claim fills which field. Mapping role delegates the role to the provider; a group array is searched for a meaningful value rather than the first entry, because a real directory user is in eleven groups. Leave it unmapped and the provider never touches roles after the account is created.

Connect the directory#

1. Directory → New connector.
2. Name it after the provider — the name appears in the audit log.
3. Choose the role for people it creates. A connector cannot default to ADMIN; map a directory group to ADMIN instead, which is a deliberate act against a named group.
4. Mint token. It is shown once, in a dialog that says so; only a hash is stored. Paste it into your provider before closing.
5. Copy the Base URL from the same card into the provider's SCIM configuration.

Map a directory group to a role#

1. Groups appear on the Directory tab once your provider syncs them, each with its member count — because the decision is "what do these eleven people get", not "what does this opaque group id get".
2. Pick a role from the dropdown beside a group, or No role to remove the mapping.
3. The mapping applies immediately, and the confirmation says how many roles actually moved.

Revoke a connector#

Revoke refuses every future call from that connector immediately. It does not undo what the directory has already done — people it deactivated stay deactivated, and you restore them from Members.

What it affects#

• The login screen. A verified, active configuration adds the provider's button. Enforcement decides whether the password box still works for people on those domains.
• Membership. Just-in-time provisioning creates accounts on first sign-in; the SCIM connector creates and deactivates them without anybody signing in. Both land on Members.
• Roles. A mapped group changes roles the moment you map it. An unmapped group changes nothing.
• The Security screen. A member created by the provider who never set a password shows as SSO only there, and disconnecting the provider leaves them unable to sign in until they reset one.
• The audit log. Connector mints and revocations, and configuration changes, are recorded.
• Failed sign-ins. Every refusal is a stable SSO_* code that reaches both the login screen and the Sign-in log tab on Security, so the two always agree.

On mobile#

/admin/identity in the Expo app reads the status, re-checks DNS and performs the two revocations. It deliberately cannot compose a configuration or mint a connector token: an issuer URL, a client id and a secret are copied out of another console, and a SCIM token exists for one moment and has to be pasted into the provider — both are the laptop you did not bring.

Limits and gotchas#

• The join key is the provider's subject, never the email address. The email claim is consulted once, when a subject is first seen, and only when the provider marked it verified and its domain is one this workspace has proven it owns. Anything else provisions a new account rather than adopting an existing one.
• Enforcement cannot be changed until the domains verify. Requiring a provider that does not work yet would lock out everyone here including the person who required it, and they would then be the only one who could undo it.
• A group that maps to nothing does not reset anybody's role. Somebody no mapped group speaks to keeps whatever role they have — the alternative would silently demote every person outside the one group you bothered to map.
• The last administrator is protected twice. A connector cannot deprovision them, and no group edit can demote them.
• Deleting a directory group deprovisions nobody. A directory that deleted Engineering has reorganised, not made the department redundant.
• Suspension is local and the directory cannot overrule it. A suspended member still reads as provisioned to SCIM, because reporting otherwise would make the connector try to "correct" it forever.
• There is no reverse channel. Removing someone from the provider stops them signing in again; a member removed locally is re-admitted on their next SSO login if just-in-time provisioning is on and they are still in the directory.

Related#

• Security — the password policy, sessions and the sign-in log.
• Members — who is in the workspace, and restoring a deactivated person.
• Roles — what VIEWER, MEMBER and ADMIN mean here.
• Audit log — the record of every change made on this screen.
• Roles and permissions — how a role and a permission key differ.