Key Takeaways: Identity Governance
A one-page reference. Reread this before an exam or before moving on. Dense by design.
Core vocabulary (memorize cold)
| Term | One-line definition | Example (Meridian) |
|---|---|---|
| IAM program / IGA | Org-wide capability to manage identities' full lifecycle + prove right access | The whole identity governance discipline |
| Directory service | Specialized DB that is the source of truth for identities | Active Directory; Entra ID |
| LDAP | Protocol to query/modify directory data | "Authenticate against LDAP" |
| SSO | Authenticate once, reach many apps | One FIDO2 login → 40 apps |
| Federation | SSO across organizations via pre-set trust | Employee logs into a vendor portal with the bank's IdP |
| SAML | Auth + federation in signed XML assertions | Enterprise SSO to a SaaS app |
| OAuth 2.0 | Delegated authorization (scoped access tokens) | App reads your calendar, no password shared |
| OIDC | Authentication on top of OAuth (signed ID token/JWT) | "Sign in with your company account" |
| JML lifecycle | Joiner-Mover-Leaver: provision, reconcile, deprovision | HR-driven account lifecycle |
| Provisioning / SCIM | Create/remove accounts; SCIM = REST/JSON automation across systems | Auto-create on hire, auto-disable on leave |
| Access certification / review | Periodic authoritative confirmation each grant is still valid | Quarterly review of wire-approvers |
| Orphaned account | Account with no valid owner/purpose | The contractor enabled 11 months after leaving |
SAML vs. OIDC vs. OAuth 2.0 (the exam discriminator)
| SAML 2.0 | OIDC | OAuth 2.0 | |
|---|---|---|---|
| Answers | Who is this user? (+federation) | Who is this user? | What may this app do? |
| Purpose | Authentication + federation | Authentication | Authorization (delegated) |
| Format | XML | JSON / JWT | JSON (tokens) |
| Key artifact | Signed assertion | Signed ID token (JWT) | Access token (scoped) |
| Built for | Enterprise SaaS SSO | Web/mobile login | API/resource delegation |
| Era / weight | Older, heavier | Modern, light (on OAuth) | Modern, light |
One-liner: OAuth = authorization; OIDC = authentication (on OAuth); SAML = authentication + federation, in XML. Never infer identity from a bare OAuth access token → token-substitution/"confused deputy" risk.
Token/assertion validation checklist (identical across all three):
- ✅ Verify the signature against the IdP's known public key (reject if it fails).
- ✅ Enforce the audience (Audience / aud) — bound to this app only.
- ✅ Honor the short expiry (NotOnOrAfter / exp) — a captured token dies fast.
- ✅ Use a mature, maintained library — never hand-parse XML/JWT. The SP's validation is the security.
Directory comparison
| Active Directory (AD) | Entra ID (formerly Azure AD) | LDAP | |
|---|---|---|---|
| What it is | On-prem directory product | Cloud identity service | A protocol |
| Authenticates with | Kerberos (+ NTLM legacy) | SAML / OAuth / OIDC | (query/modify, not an auth method) |
| Organized as | Domains → OUs → users/groups | Users, groups, apps (no OU tree) | Hierarchical tree |
| Policy mechanism | Group Policy | Conditional Access | — |
| Built for | Machines on a corp network | SaaS + cloud + web | Vendor-neutral directory access |
| Guarded by | Domain controllers (top target) | Microsoft cloud | — |
- Most enterprises run hybrid: on-prem AD synced upward to Entra ID. AD is usually authoritative.
- ⚠️ Disable at the source. Disabling only in Entra ID can be re-enabled by the next sync from AD.
- AD attack paths to recognize (defend, never weaponize): Kerberoasting (crack service tickets → long random service passwords, Ch.20), pass-the-hash (reuse stolen hash → admin tiering, Ch.19), LDAP enumeration (least privilege limits what ordinary accounts can read, Ch.17).
Joiner-Mover-Leaver (JML)
| Transition | What must happen | Failure if botched |
|---|---|---|
| Joiner | Provision account + birthright access by role (HR triggers it) | Over-provisioning; manual copy of last person's access |
| Mover | Reconcile: +grant new role, −revoke old role | Privilege creep; SoD toxic combinations |
| Leaver | Fully deprovision everywhere, promptly | Orphaned account — valid, unmonitored, dangerous |
- Driven by the system of record (HR for employees). Contractors are the blind spot — give them a roster + leaver trigger.
- SCIM = automate provisioning/deprovisioning across systems → "disable everywhere" becomes real.
- Mandatory account-expiration date on contractor accounts = fail-safe: dies on schedule even if everyone forgets.
Access review / orphaned-account hunt — checklist
Find orphans = reconcile directory (who can get in) vs. systems of record (who should): - 🚩 No HR/roster record — strongest orphan signal. - 🚩 Stale activity — no login in 90/180 days → disable-after-inactivity. - 🚩 No owner / no purpose — especially service accounts (Ch.20).
Make certification real (not rubber-stamp):
- Plain-language entitlement descriptions (not LN_APPRV_TIER2_PROD).
- Auto-flag the risky/anomalous/stale grants for scrutiny; enrich each row (HR status, last login).
- Keep lists short by reviewing high-risk access more often.
- Track and enforce revocations — a review with no removals is a red flag, not a clean bill.
Why orphans are dangerous (3 properties): valid (defeat front door) · unmonitored (misuse invisible) · privileged/well-connected (accumulated access) → the engine of lateral movement & privilege escalation.
Remediation rules: disable at the authoritative source; disable, don't delete (preserve forensic evidence, allow reversal).
Decision aids — "when to use what"
- SSO'd login for a web/mobile app, need user identity → OIDC (validate
aud+ signature). - Enterprise SaaS, corporate "log in with company account" → SAML.
- App needs scoped access to a resource on the user's behalf, no password → OAuth 2.0.
- Departing person → disable the one IdP identity (cuts off all federated apps) + deprovision non-SSO accounts.
- Hybrid AD/Entra disable → change on-prem AD (the source), not just the cloud copy.
- Contractor onboarding → roster record + account expiration date at creation (fail-safe).
Certification crosswalk
| Concept | CompTIA Security+ | (ISC)² CISSP domain |
|---|---|---|
| SSO, federation, SAML/OAuth/OIDC | 1.0 General Concepts; 4.0 Security Operations | Identity & Access Management (IAM) |
| Directory services (AD/LDAP/Entra) | 4.0 Security Operations | IAM; Security Architecture & Engineering |
| Identity lifecycle (JML), provisioning, SCIM | 4.0 Security Operations | IAM (provisioning/deprovisioning) |
| Access certification / review; orphaned accounts | 4.0; 5.0 Governance, Risk & Compliance | IAM; Security Assessment & Testing |
| Privilege creep / SoD enforcement | 4.0 Security Operations | IAM; Security & Risk Management |
Project additions this chapter
- Meridian program: the Identity Governance (IGA) process — systems of record, JML triggers/automation, certification cadence (quarterly high-risk / annual rest), and the orphaned-account hunt. Sits between the access-control policy (Ch.17) and the PAM standard (Ch.19); retires risk R2 from Ch.1.
bluekittoolkit:idgov.py—orphan_accounts(users, hr)(reconcile directory vs. source of truth) andaccess_review(grants)(tag grants KEEP/REVOKE for certification).
Common pitfalls
- Confusing OAuth (authorization) with OIDC/SAML (authentication); using a bare OAuth token for login.
- Trusting SSO/federation without validating the SP's assertion/token checks (signature, audience, expiry).
- Disabling a leaver only in the cloud when on-prem AD is authoritative → re-enabled by the next sync.
- Mover processes that only add access → privilege creep; long-tenured staff become the biggest risk.
- Letting contractors/affiliates live outside any system of record → orphans with no leaver trigger.
- Rubber-stamp certifications (100% keep, completed in minutes) — an audit artifact that catches nothing.
- Treating identity hygiene as paperwork rather than as lateral-movement prevention.