--- title: "Identity" slug: admin/identity url: https://projectri.com/docs/admin/identity section: admin audience: admin app_route: "/[slug]/admin/identity" permissions: [security.policy] plan: enterprise.sso mobile: "/admin/identity" updated: 2026-09-08 source: Projectri documentation --- # Identity Connect an OIDC identity provider so people sign in with their work account, and a SCIM connector so your directory creates and deactivates them. ![Identity](https://projectri.com/docs-shots/admin-identity.png) ## 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: | Half | Entitlement | Flag | |---|---|---| | Single sign-on | `enterprise.sso` (ENTERPRISE) | `enterprise.sso`, off by default | | Directory | `enterprise.scim` (ENTERPRISE) | `enterprise.scim`, off by default | 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](/docs/admin/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](/docs/admin/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](/docs/admin/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 > [!WARNING] > There is no SAML. Only OIDC is supported, and posting a SAML configuration > returns a refusal that explains itself. Verifying a SAML assertion means > implementing exclusive XML canonicalisation, and nearly every well-known SAML > bypass of the last decade has been a canonicalisation bug. - **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](/docs/admin/security) — the password policy, sessions and the sign-in log. - [Members](/docs/admin/members) — who is in the workspace, and restoring a deactivated person. - [Roles](/docs/admin/roles) — what VIEWER, MEMBER and ADMIN mean here. - [Audit log](/docs/admin/audit-log) — the record of every change made on this screen. - [Roles and permissions](/docs/start/roles-and-permissions) — how a role and a permission key differ. ## Related - [Security](https://projectri.com/docs/admin/security.md): The sign-in rules this workspace enforces, who is signed in, what machine credentials and outside applications can reach it, and the sign-in history. - [Members](https://projectri.com/docs/admin/members.md): The workspace roster and the pending invite list — invite people, change roles, suspend, remove, and do any of those to many people at once. - [Roles](https://projectri.com/docs/admin/roles.md): The four company roles, how many people hold each, how far this workspace has moved from the platform default, and how to put a role back. - [Audit log](https://projectri.com/docs/admin/audit-log.md): Every recorded action in this workspace, who did it and from where, with a bulk export and streaming to your own SIEM. - [Roles and permissions](https://projectri.com/docs/start/roles-and-permissions.md): The four workspace roles, the permission keys behind them, and why two people in the same workspace see different screens.