Security model overview
Purpose: How authentication and authorisation actually work across author and publish, and the defaults to verify.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | The mental model under every permissions question |
Two very different tiers
| Author | Publish | |
|---|---|---|
| Users | Real humans via SSO (SAML) + service users | Mostly anonymous + service users; members if authenticated site |
| AuthZ concern | Who may edit/publish what | What anonymous may READ |
| Exposure | Private network only | Internet-facing (behind dispatcher) |
The publish-side question people forget: replicated ACLs decide what anonymous can read. Content that renders fine on author can 404 on publish (ACL not replicated / no anonymous read) or — worse — internal content can be readable because a broad allow went out with the tree.
Request → decision pipeline
Request → Authentication handler (SAML/token/basic/anonymous)
→ Session with principal + group memberships
→ Every repository access checked against ACLs (walk-up evaluation — nearest rule wins)
→ Render only what the session may readThere is no "the app checks permissions" layer to forget — Oak enforces on every read/write. Your job is correct ACLs and correct sessions (service users, not admin).
Defaults to verify on every environment
- [ ] No default credentials anywhere (the famous admin defaults changed, verified by trying them; same for other well-known accounts per hardening docs)
- [ ] Anonymous write nowhere; anonymous read only under intended /content trees
- [ ] Self-registration off; author accessible only via VPN/private network
- [ ] Publish consoles/CRXDE unreachable (dispatcher + local config — dispatcher security)
- [ ] Encapsulated token / clustering keys synced correctly across publish farm (login consistency)
- [ ] The "Adobe security checklist for 6.5" run and evidenced per go-live (go-live checklist)