Enforced SSO & domains

Once a customer's SAML connection works, most enterprises want it to be the only way their employees sign in — no personal passwords, no social logins. Atlas does this by tying an email domain to an SSO connection.

How it works

1. You add and verify the customer's domain (e.g. acme.com) on their organization.

2. You link the verified domain to their SSO connection.

3. You turn on enforcement.

From then on, anyone entering an @acme.com address on your sign-in page is redirected to Acme's IdP — Atlas won't offer them a password, code or social option. They're also routed into the Acme organization automatically.

Verifying a domain

Domain verification proves the customer controls the domain (typically via a DNS TXT record). Until it's verified, you can't enforce SSO for it — this prevents one customer from hijacking another's users.

Enforcement modes

• Enforced — the domain's users must use SSO. Existing passwords for those users are disabled.

• Optional / suggested — users may use SSO or another method (useful during a migration).

Migrating existing users

If some @acme.com users already have password accounts, plan the cutover:

1. Enable the SSO connection in optional mode and let people try it.

2. Announce a cutover date.

3. Switch to enforced; from then on those users sign in only via the IdP. Their identity and data carry over — only the sign-in method changes.

What about admins outside the domain?

You can keep a break-glass admin outside the enforced domain, or rely on the IdP's own admin roles. Document this so a customer isn't locked out during an IdP outage.

Next

Automate the account lifecycle → SCIM provisioning.