SSO sign-in policy and JIT provisioning

Once your identity provider is connected, the owner decides who can get into the workspace through it. That's the Sign-in policy card under Admin → SSO & Provisioning; this page covers just-in-time (JIT) enrollment, default roles, the verified-domain checks and what domain capture does to password sign-in.

#Prerequisites

• Business or Enterprise, or a trial with the Business features preview switched on.
• Owner access. Only the owner sees SSO & Provisioning.
• A saved identity provider. Until one is saved the card says "Save your identity provider configuration first".
• At least one verified domain if you keep the default mode. See Domain verification (DNS TXT).

1. Open SSO & Provisioning. Open Admin → SSO & Provisioning and check your identity provider is saved.
2. Pick a JIT mode. Pick a Just-in-time (JIT) provisioning mode.
3. Set default roles. Set the Default workspace role for people who join this way, and a Default custom role if your workspace has custom roles.
4. Configure domain enforcement. Decide whether to turn on Require verified email domain on every SSO sign-in.
5. Save sign-in policy. Then test with one person who should get in and one who shouldn't.

#JIT provisioning modes

#Default roles

The Default workspace role is Member or Admin. It's "Applied when no SCIM group mapping matches", and Owner can't be a default.

If your IdP sends group IDs in the sign-in token and one matches a row on the Group-to-Role Mapping card, that mapping decides the role instead. Group mappings can assign Owner, so review them carefully. The role is recalculated each time someone signs in with SSO, so a change in your IdP groups shows up at the next sign-in.

#Require verified email domain on every SSO sign-in

This switch applies the verified-domain check to every SSO sign-in whatever the JIT mode is. It matters when the mode is Off or Any SSO user from the IdP. In the default Verified domain only mode, every sign-in is already checked.

#Domain capture: what SSO does to password sign-in

When a domain is verified and SSO is active and an identity provider is saved, anyone with an email on that domain has to sign in with SSO. Password sign-in, password sign-up and email sign-in links are refused for them with "This enterprise domain requires signing in with your organization's Single Sign-On."

Owners are the exception: they keep password sign-in as a break-glass route while SSO is active, so the way back in that SSO setup asks for still works if the IdP breaks. Each break-glass sign-in is recorded in the Audit Log. Email sign-in links are still refused for owners on the domain.

Before you turn SSO on:

• Download a recovery file from Settings → Backup & Recovery and keep it with its password.
• Make sure every owner has a password set and knows it. Addresses on other domains aren't affected.

#Audit and troubleshooting

Policy changes and SSO enrollments are recorded in the workspace Audit Log, with metadata only. If someone can't get in, check:

• The JIT mode against their email domain.
• Whether the domain they use is verified (subdomains need their own claim).
• Whether Require verified email domain on every SSO sign-in is on.
• Their IdP group assignment and your group-to-role mappings.
• The Audit Log for recent SSO entries.

#FAQ

#Related

• Single sign-on (SAML & OIDC)
• Domain verification (DNS TXT)
• SCIM directory sync
• Roles and permissions