# 15 SSO/SAML to hardened IdP

> v0.1.3 · role: Prevent · edition: All (+IdP) · [policy: #8 · #3](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

Hands Workspace sign-in to an external identity provider over SAML or OIDC, so authentication policy — and its logging — lives in one place across all your SaaS. The break-glass admin ([20 Break-glass admin + offline backup codes](breakglass-admin.md)) stays on Google authentication as the fallback, and super admins always authenticate directly with Google — a fixed property of the newer SSO profiles (legacy SSO profiles can still let super admins sign in via SSO).

Documentation: [About SSO](https://knowledge.workspace.google.com/admin/apps/about-sso)

## Caveats

- SSO moves the blast radius to the IdP — an IdP compromise is now a full Workspace compromise, so the IdP must itself be phishing-resistant (№7) or it's a downgrade of authentication.
- Google's 2SV settings do not apply to users signing in via a third-party IdP — MFA becomes the IdP's job, so verify it is actually enforced there, and keep Google-side 2SV on for every OU the SSO profile does not cover.
- Signing out of the IdP does not end the Google session — and when the Google session length (№12) expires, Google can renew the session without a fresh sign-in if the IdP session is still valid, so set the IdP session to expire before the Google session; otherwise a revoked IdP user keeps working for hours.
- Never assign the SSO profile to the break-glass account (№20) — an IdP outage would then leave the tenant with no way in.

## Setup steps

1. Add a third-party SSO profile (SAML or OIDC) with the IdP's sign-in/sign-out URLs and verification certificate. — `Security › Authentication › SSO with third-party IdP`

   SSO profile = <IdP name>; IdP entity ID, Sign-in page URL, Sign-out page URL, Change password URL, Certificate uploaded (up to two)

   docs: [Setting up SSO](https://knowledge.workspace.google.com/admin/apps/setting-up-sso)

2. Assign the profile to the OUs (organizational units) / groups that must federate; leave the break-glass admin OU on 'None (Google)' so it can still sign in when the IdP is down or compromised. — `Security › Authentication › SSO with third-party IdP › Manage SSO profile assignments`

   - **OU <staff>** = <IdP profile>
   - **OU <break-glass>** = None (Google authentication)

   docs: [Setting up SSO](https://knowledge.workspace.google.com/admin/apps/setting-up-sso)

3. Under the newer SSO profiles, super admins always authenticate directly with Google; the legacy SSO profile does not guarantee this (super-admin SSO can occur via IdP-initiated or domain-specific sign-in flows), so migrate off it if still in use. That bypass is the break-glass property this control leans on when the IdP is down or compromised — and it is why Google-side 2SV must stay enforced for the admin OU: the super-admin password never stops working. — `Security › Authentication › SSO with third-party IdP`

   Super admins = Google sign-in (fixed behaviour of the newer SSO profiles; not guaranteed on the legacy profile); Google-side 2SV enforced for the admin OU

   docs: [Super administrator SSO](https://knowledge.workspace.google.com/admin/apps/super-administrator-sso)

4. Keep Google-side 2SV/phishing-resistant enforcement in place for any account not covered by the SSO profile, so partial-SSO accounts are not left password-only. — `Security › Authentication › 2-Step Verification`

   - **2SV enforcement** = On for all non-federated OUs

   docs: [Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification) · [How 2-Step Verification works with third-party IdPs](https://knowledge.workspace.google.com/admin/security/how-2-step-verification-works-with-third-party-idps)

## Ongoing maintenance

- **[automatable: script]** Before IdP certificate expiry: rotate the certificate in the SSO profile (watch the expiry date with a scheduled check).

## How to verify

1. Sign in as a federated test user — the login must redirect to the IdP. Then sign in as the break-glass account — it must NOT redirect and must accept Google credentials.

## Settings screens

- Security > Authentication > SSO with third-party IdP
  - console: https://admin.google.com/ac/security/sso
  - screenshot: ../screenshots/admin.google.com/ac/security/sso.png
- Security > Authentication > 2-Step Verification (confirm Google-side 2SV posture is retained where SSO is partial)
  - console: https://admin.google.com/ac/security/2sv
  - screenshot: ../screenshots/admin.google.com/ac/security/2sv.png