Single sign-on (SSO)

Single sign-on (SSO)

SSO lets staff and pupils log in with their existing school account — no separate Keystone password to remember, no separate provisioning flow when someone joins or leaves. The trust’s identity provider becomes the source of truth for who can access what.

Supported providers

• Microsoft Entra ID (Azure AD) — most common in MAT IT
• Google Workspace — common in primaries + early-years
• Generic SAML 2.0 — for in-house identity systems
• Generic OIDC — for newer custom IdPs

The wizard at Platform admin → SSO → Wizard walks through each.

What the wizard does

1. Pick provider — Entra / Google / SAML / OIDC
2. Register Keystone in the IdP — wizard generates the redirect URI + entity ID; you paste them into the IdP’s app registration UI
3. Paste IdP details back — client ID, client secret (or SAML metadata URL)
4. Map claims — which IdP attribute is the email? Display name? Department?
5. Test — opens an SSO flow in a new tab; you log in as yourself, the platform confirms it received the right claims
6. Enable — flips SSO on for the workspace

The whole flow is 15-20 minutes if you have IdP admin access.

JIT (just-in-time) provisioning

When SSO is enabled, new users auto-provision on first login. Their roles + departments come from IdP groups via the claim mapping. Trust admins don’t manually create users.

Group → role mapping examples:

IdP group	Maps to Keystone role
helpdesk-team@trust	helpdesk::agent
helpdesk-leads@trust	helpdesk::admin
estates-team@trust	estates::agent
dsl@<academy>	dsl (scoped to that academy)
staff	helpdesk::requester (everyone)

Local logins

You can keep local (password-based) logins enabled alongside SSO. Useful for:

• Service accounts (integrations, API consumers)
• Pupils where SSO isn’t available
• Emergency access if SSO goes down

The login screen shows both options when both are enabled. The default action button is SSO.

Forcing SSO

For trusts that want to disable local logins for staff entirely:

• Domain restriction — local logins only allowed for emails outside the staff domains
• Role restriction — local logins disabled for users with staff-typed roles
• Workspace toggle — “SSO required for all logins” flag

Don’t disable local logins until you’ve tested SSO is working for everyone — the recovery path is awkward.

Group sync

By default, group-to-role mapping happens at login. A user added to a new IdP group sees the new role only after they next log in.

Optionally, enable scheduled group sync — every 15 minutes, the platform pulls the IdP’s group memberships for all known users and updates roles. This catches users who haven’t logged in for a while.

Audit

Every SSO login is logged with the IdP claims received. Useful for diagnosing “why does this user have this role?” — the audit log shows the group memberships at the time of the most recent login.

If a user’s claims change unexpectedly (e.g. they’re suddenly missing the safeguarding group), the audit log tells you when the change happened.