CCSM Elite R82 study materials
CCSM Elite R82 study resources

CCSM Elite R82: Identity and Access Management

CCSM Elite R82 · Work through your exam, one topic at a time.

All guide sections

Identity and Access Management

Identity and Access Management tests the full lifecycle: proofing, authentication, authorisation, federation, and deprovisioning, with heavy emphasis on privileged access. Items typically ask which protocol fits a scenario or what must happen when a person changes role.

Separate the four ideas

Identification is the claim; authentication is the proof; authorisation is the permission decision; accountability is the audit trail tying actions to an identity. Blurring authentication with authorisation is the most common source of wrong answers.

Factors and assurance

Factors are something you know, have, or are; location and behaviour are supporting signals rather than primary factors. MFA requires different factor types - two passwords is not MFA. FIDO2/WebAuthn credentials are origin-bound and therefore phishing-resistant. NIST SP 800-63 separates identity assurance (IAL), authenticator assurance (AAL), and federation assurance (FAL), so a high-assurance transaction may need stronger proofing independent of password strength.

Federation protocols

  • SAML 2.0 carries XML assertions for browser-based enterprise SSO.
  • OAuth 2.0 is an authorisation delegation framework; it issues scoped access tokens and is not an authentication protocol.
  • OpenID Connect adds an identity layer over OAuth 2.0, returning an ID token as a signed JWT.
  • Kerberos uses tickets issued by a KDC for mutual authentication inside a realm.

Access control models

Discretionary (owner decides), mandatory (system labels), role-based (roles; watch role explosion), attribute-based (fine-grained, context-aware), and rule-based.

Worked example

A mobile app offers "sign in with provider" to read a user's calendar. The correct design is OAuth 2.0 authorisation code flow with PKCE and a scope limited to calendar read. But the app also needs to know who the user is, and an access token must never be treated as proof of identity; add OpenID Connect so an ID token asserts the subject. The reasoning: answer "what may this client do?" with OAuth, and "who is this?" with OIDC.

Traps that cost marks

  • Using OAuth access tokens as authentication evidence.
  • Confusing SAML assertions with Kerberos tickets.
  • Deprovisioning leavers but not internal movers, leaving accumulated entitlements.
  • Standing administrator rights instead of just-in-time elevation with break-glass logging.
  • Access reviews signed by someone without authority over the entitlement.