Identity and Access Management: Federation, Models, and Lifecycle Control
What this domain tests
Domain 5 tests the full identity path: proving who someone is, deciding what they may do, recording what they did, and removing access when the relationship ends. Expect questions on authentication factors, federation protocols, access control models, privileged access, and joiner-mover-leaver hygiene.
Core rules
- Authentication factors are knowledge, possession, and inherence. Multi-factor means different categories; two passwords are not MFA. Time-based one-time passwords and push notifications are phishable, while FIDO2/WebAuthn credentials bound to an origin resist phishing.
- Kerberos issues a ticket-granting ticket after initial authentication, then service tickets, giving single sign-on inside a realm.
- SAML 2.0 federates authentication: the identity provider issues a signed assertion about the subject to the service provider. OAuth 2.0 is delegated authorization, issuing access tokens with scopes to resources; it is not an authentication protocol. OpenID Connect adds an identity layer on OAuth 2.0 with an ID token.
- Access control models: discretionary (owner grants), mandatory (system labels), role-based (permissions attached to job roles), and attribute-based (policy evaluates subject, resource, action, and context such as time or device posture). Rule-based systems evaluate static conditions.
- Least privilege and separation of duties are enforced through role design and approval workflows. Provisioning must handle movers, not just joiners and leavers: a transfer should strip old entitlements before granting new ones.
- Privileged access management vaults credentials, brokers sessions, records activity, and can grant just-in-time elevation. Shared administrator accounts destroy accountability even when vaulted.
Worked example
A contractor needs read access to one project folder in a SaaS application for six weeks. The correct design federates the SaaS app to the corporate identity provider using SAML, maps an entitlement group to the read role, and places the contractor in that group with a time-bound membership approved by the data owner, with periodic access review and full session logging. Creating a local account with a shared password fails accountability and leaves orphaned access after the contract ends.
Traps that cost marks
- Describing OAuth 2.0 as an authentication protocol, or using SAML assertions to carry authorization decisions.
- Blurring role-based and attribute-based control when the scenario turns on context such as location or device health.
- Granting new permissions on transfer without removing the previous ones.
- Assuming a password vault alone gives accountability while administrators still share one credential.