Single Sign-On: Overview and Prerequisites
The Aeon 7 staff web client can authenticate staff against your institution's identity provider, so signing in to Aeon uses the same campus credentials as everything else. Aeon supports SAML 2.0 (Shibboleth and federations like InCommon) and OpenID Connect (Entra ID, Okta, Keycloak, and similar). The staff client speaks the protocol itself; there is no Shibboleth service-provider module or IIS add-on to install.
Find what you need
| You want to… | Read |
|---|---|
| Set up SAML or Shibboleth sign-in | Setting Up SAML Single Sign-On |
| Set up Entra ID, Okta, Keycloak, or another OIDC provider | Setting Up OpenID Connect Single Sign-On |
| Look up a field on the Single Sign-On page | Single Sign-On Settings Reference |
| Rotate or replace a SAML signing certificate | Managing Service Provider Certificates |
| Run Test sign-in, decode a staff error, or find the audit record | Testing and Troubleshooting Single Sign-On |
| Convert staff accounts, one at a time or in bulk | Moving Staff Accounts to Single Sign-On |
Three things to understand first
Single sign-on is an account mode, not a login button. Every staff account is either Local (password + authenticator) or Single sign-on, set by Authentication method on the staff record. Turning single sign-on on moves nobody: it makes the SSO button available, and each account is then converted individually. An SSO account signs in only at the identity provider. Aeon answers a password attempt on it by sending it into the SSO flow, and ignores a forgot-password request for it. A mix of Local and SSO accounts is the normal state for as long as a rollout takes.
No account is ever created by signing in. If the identity provider asserts an identity that no staff account claims, the sign-in is denied. Create the account first, then connect it to an institutional identity.
You can't lock yourself out. The password sign-in path is never switched off. Even under Single sign-on only, the password form sits behind an Admin sign-in link that is always on the login page. Before single sign-on can be turned on, Aeon makes you prove that path works: the save opens a Confirm emergency access dialog asking for a Local administrator's username, password, and authenticator code, and completes only when all three check out. Aeon then refuses to convert the last unlocked Local administrator and warns whenever fewer than two remain. Keep two permanently: with authenticator codes mandatory, a single emergency administrator means one lost phone is a lockout.
Where the settings live
Customization Manager → Integrations & Messaging → Single Sign-On. The page and its API require the Integrations configuration capability — deliberately not the diagnostics capability, so a role that can only read logs can't change which identity provider Aeon trusts. API keys are refused outright on the SSO configuration endpoints.
Full validation runs only when you save with single sign-on enabled. With it off, the page saves incomplete drafts, so you can build the configuration over several sittings and switch it on when everything is ready.
Before you start: server groundwork
If Atlas hosts your Aeon, the four items below are handled for you. On an on-premises install, go through them with whoever administers the server. On every deployment, the staff accounts you plan to invite each need an email address saved on the account.
| Prerequisite | Why it matters | How to check |
|---|---|---|
| Public URLs | Everything Aeon hands your identity provider — entity ID, ACS URL, logout URL, metadata, the OIDC redirect URI — is built from the staff API's and the staff web client's public addresses. | Open the Service provider tab and read the SP entity ID, ACS URL, and Single Logout URL. localhost anywhere means the base URLs aren't right yet; fix that before registering Aeon anywhere. The layers Aeon reads them from are under Override public URLs in the settings reference. |
| HTTPS on the staff web client | Served over plain HTTP at a real hostname, every sign-in fails at the last step with "The sign-in code is invalid or has expired," because that step uses a browser feature available only over HTTPS. Aeon accepts an http:// base URL and only logs a warning, so the failure looks like a puzzle rather than a misconfiguration. | The staff web client's public address starts with https://. |
| Outbound email | Invitations, the recommended way to convert staff, are delivered through Aeon's outgoing mail. The invitation button stays disabled for an account with no email address. | Aeon's outgoing mail delivers. |
| Server clock | SAML assertions and OIDC tokens carry tight validity windows, judged against the API server's clock. The tolerance is Clock skew: 180 seconds by default, adjustable from 0 to 600. | Time sync is healthy on the API server. Widening Clock skew is for a provider that genuinely needs more room, not for a server that is wrong about the time. |
Once converted, a staff member clicks the SSO button instead of typing a password. Aeon's authenticator step still applies by default, and they can't change or reset an Aeon password. See Moving Staff Accounts to Single Sign-On for the full comparison.