SSO enforcement

Requiring single sign-on for a domain makes your identity provider the only way its people sign in. Only an owner, signed in to the dashboard, can turn it on or off, or choose break-glass owners. This is dashboard only by design. Secret keys, the CLI and Terraform can’t change enforcement or break-glass owners, so a leaked key can never turn enforcement off.

​

How people sign in

Sign-in asks for the email address first, then checks the address’s domain:

• SSO is offered. The person sees Sign in with SSO and chooses Continue with SSO, or signs in with an email code instead.
• SSO is required. The person goes straight from the email step to your IdP.
• No SSO. Sign-in continues as usual.

Sazabi starts every SSO sign-in itself. IdP-initiated SAML, where your IdP sends a sign-in response Sazabi didn’t ask for, stays off, and Sazabi refuses such a response. A tile in your IdP’s app dashboard opens Sazabi’s Initiate login URL instead; see Configure SSO. The organization that verified a domain governs every account on that domain, in every organization the person belongs to. If ben@example.com also belongs to another organization, he signs in to it through your IdP too, and it lists him as signing in through your SSO. That organization can still remove him. sazabi auth sign-in opens the CLI device page, /sign-in/cli, which uses the same email-first sign-in. A CLI session lasts only as long as the dashboard session that approved it is allowed.

​

Order matters

Turning enforcement on can’t lock anyone out if you go in this order: Until a step is done, the domain’s switch is disabled, and hovering it names the missing step, such as “Choose a break-glass owner before requiring single sign-on.”

​

What enforcement refuses

While a domain requires SSO, its addresses can sign in only through your connection. Email codes, passwords, magic links and social sign-in (such as Google or GitHub) are refused for them, except for break-glass owners. This holds in every organization those people belong to. Secret keys carry no person, so enforcement doesn’t affect them.

​

Turning it on and off

Each verified domain has its own switch in the Require single sign-on section. Turning one on asks Require single sign-on for domain? first; choose Require single sign-on to confirm. The row then shows how many accounts on the domain were signed out. Turning a switch off takes effect right away, with no confirmation. A domain that lapses while it requires SSO stays in the list, so you can still turn it off.

​

What turning it on ends

Turning enforcement on signs out every account whose email address is on the domain, including sessions that came through SSO. If your own address is on the domain, that includes you. Everyone signs in again through SSO:

• Dashboard sessions end.
• CLI sessions and CLI sign-ins still waiting for approval end. People run sazabi auth sign-in again and sign in through SSO.
• MCP access granted to AI tools ends in every organization those people belong to. People reconnect their tools. An MCP access token already issued keeps working until it expires, up to 15 minutes.

While a domain requires SSO, the connection can’t be deleted, its Allow sign-in can’t be turned off, and the domain can’t be removed. Turn enforcement off for every domain first.

​

Break-glass owners

Break-glass owners can still sign in if your identity provider is down or misconfigured. In the Break-glass owners row, choose Choose owners, select up to two owners and choose Save. Each must be an owner with an authenticator app set up for two-factor authentication. The row lists the current break-glass owners and when each was chosen. A break-glass sign-in uses an email code, then a code from the authenticator app or a backup code. It:

• lasts one hour, and is never extended;
• can’t approve a CLI sign-in or connect an MCP tool;
• emails every owner, and is recorded.

A person stops being a break-glass owner if they stop being an owner or remove two-factor authentication. Someone who is no longer an owner still appears in Choose owners, marked no longer an owner; clear them and save to remove them.

​

If no one can sign in

If your IdP is unavailable and no break-glass owner can sign in, contact support. After confirming the request, support can turn enforcement off for a domain. Support can’t turn it on, change your connection or choose break-glass owners. Every support action is recorded with its reason, and every owner gets an email. An owner turns enforcement back on afterward.

​

Owner emails

Sazabi records security-relevant SSO changes as access events, and emails every owner when: Enforcement changes and break-glass sign-ins are recorded with the change itself: if the record can’t be written, the change doesn’t happen. If an email can’t be sent at first, Sazabi keeps retrying it.

​

Plan changes

Losing single sign-on never locks anyone out. When your plan stops including it:

1. Right away, the Single sign-on page becomes read only, except that an owner can still turn enforcement off and choose break-glass owners. Sign-in through your connection and enforcement keep working.
2. For 30 days, nothing else changes. Move to a plan that includes single sign-on to keep it.
3. After 30 days, enforcement turns off for every domain, so people can sign in with an email code again.
4. Then the connection stops allowing sign-in. It isn’t deleted, and no accounts or memberships are removed.

Owners get the emails above when enforcement and then the connection turn off. If your plan includes single sign-on again, the page becomes editable again: turn the connection’s Allow sign-in back on and require SSO again where you need it.

​

Further reading