SSO & SAML overview
Purpose: Understand how enterprise SSO attaches to AEM author (and authenticated publish sites) at a working-knowledge level.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Login mechanics awareness |
| Platform engineers | Configuration owners |
Author SSO (the common case)
AEM ships a SAML 2.0 authentication handler. The flow:
Browser → AEM author → (no session) → redirect to IdP (corporate SSO)
← SAML assertion (POST /saml_login) ←
AEM validates signature → creates/updates user → group sync from assertion → session| Config concern | Where |
|---|---|
| SAML handler (IdP URL, certificate, attribute mapping) | OSGi config per environment |
| IdP certificate | Truststore (Granite) |
| Auto-create users & map IdP groups → AEM groups | Handler config — this is where permissions actually happen |
| Fallback local login | /libs/granite/core/content/login.html?resource=… (break-glass admin) |
Group mapping is the part engineers get asked about: users get AEM permissions via groups that the assertion's group attribute maps onto. "I can't see X" after SSO usually = missing group in the IdP or mapping config.
Authenticated publish (member portals)
Same handler can protect publish. Delivery consequences dominate the design:
- Authenticated pages are not dispatcher-cacheable by default;
/auth_checkerpermits caching with per-request permission checks — design this early, not after launch. - Session stickiness/logout across publish farm members needs deliberate config (encapsulated tokens so any publisher validates the login).
- Mixed public/member sites: separate the trees (/content/phi/public vs /secure) so caching rules stay simple.
Rules
- Never build custom login before exhausting the product handlers (SAML, OAuth via IMS-adjacent setups, token auth).
- Local admin login must remain available and monitored (break-glass) — and MFA-protected at the IdP for everyone else.