Implement and maintain identity and access management

Provisioning/deprovisioning, permission assignments, identity proofing, federation (SSOSingle Sign-On — One authentication grants access to multiple systems, SAMLSecurity Assertion Markup Language — XML-based SSO protocol for web applications, OAuthOpen Authorization — Authorization framework for delegated access, OIDCOpenID Connect — Identity layer built on OAuth 2.0), access control models (MACMandatory Access Control — System-enforced access based on security labels, DACDiscretionary Access Control — Resource owner controls access permissions, RBACRole-Based Access Control — Permissions assigned to roles, users assigned to roles, ABACAttribute-Based Access Control — Access decisions based on attributes (user, resource, environment)), MFAMulti-Factor Authentication — Requiring multiple authentication factors (TOTPTime-based One-Time Password — Time-synchronized OTP (authenticator apps), HOTPHMAC-based One-Time Password — Counter-based OTP, FIDO2Fast Identity Online 2 — Passwordless authentication standard (WebAuthn)), password concepts (passwordless, managers), and privileged access management (JITJust-In-Time — Temporary access granted only when needed, vaulting, ephemeral credentials).

Exam approach: “Given a scenario” — expect to configure access controls for a described org, select the right federation protocol, and troubleshoot IAMIdentity and Access Management — Framework for managing digital identities and permissions misconfigurations. Understanding the tradeoffs between access control models is critical.

Offensive context: Understanding how attackers intercept and manipulate JWTs and OIDCOpenID Connect — Identity layer built on OAuth 2.0 claims at the proxy level makes this objective’s defensive configuration more meaningful. Identity-Aware Proxy and Workload Identity concepts extend port-level validation to enterprise-scale zero-trust — and knowing how token replay and claim manipulation attacks work is what makes your IAMIdentity and Access Management — Framework for managing digital identities and permissions configuration airtight.

Account Lifecycle

Provisioning

• Create accounts when users join. Assign roles and permissions based on job function, not individual request.
• Automate where possible — HR system triggers account creation, role assignment based on department/title.
• Identity proofing: verify the person is who they claim to be before granting access. For employees this is the hiring process. For external users, it might be document verification, knowledge-based questions, or out-of-band verification.

Permission Assignment

• Assign permissions to roles, not individuals. When someone changes jobs, change their role — permissions follow automatically.
• Least privilege from day one. It’s easier to grant additional access than to claw back excess permissions.
• Separation of duties — no single person should control an entire critical process (e.g., the person who approves payments should not be the person who initiates them).

Deprovisioning

• Remove access immediately when an employee leaves. Not tomorrow. Not next week. Immediately.
• Disable the account first, delete later (preserve for audit trail).
• Revoke all tokens, sessions, APIApplication Programming Interface — Interface for software-to-software communication keys, VPNVirtual Private Network — Encrypted tunnel over public networks certificates.
• Audit shared resources the departing user had access to.
• Automate — HR termination triggers deprovisioning workflow. Manual processes get forgotten.

Access Reviews

• Regular audit of who has access to what. Permissions accumulate over time (privilege creep).
• Managers review their team’s access quarterly. Security reviews privileged accounts monthly.
• Recertification: if a manager can’t justify why someone has access, revoke it.

Federation and SSO

Single Sign-On (SSO)

One authentication event grants access to multiple services. User logs in once, gets access to email, file sharing, CRM, etc. without re-authenticating.

Why it matters for security:

• Fewer passwords = fewer weak passwords = fewer credential stuffing targets
• Centralized authentication = centralized MFAMulti-Factor Authentication — Requiring multiple authentication factors enforcement
• Centralized deprovisioning = disable one account, all access stops

SAML (Security Assertion Markup Language)

• XMLExtensible Markup Language — Markup language for structured data exchange-based, mature, enterprise-focused
• Identity Provider (IdPIdentity Provider — Service authenticating users for SSO/federation): Authenticates the user (Google Workspace, Okta, Azure ADActive Directory — Microsoft directory service for identity management)
• Service Provider (SP): The application being accessed
• Flow: User hits SP → SP redirects to IdPIdentity Provider — Service authenticating users for SSO/federation → IdPIdentity Provider — Service authenticating users for SSO/federation authenticates → IdPIdentity Provider — Service authenticating users for SSO/federation sends SAMLSecurity Assertion Markup Language — XML-based SSO protocol for web applications assertion (XMLExtensible Markup Language — Markup language for structured data exchange) back to SP → SP grants access
• The assertion contains claims: who the user is, what groups they belong to, when the auth happened
• Common misconfiguration: Not validating the assertion signature. An attacker can forge assertions if the SP doesn’t verify the IdP’s signature.

OAuth 2.0

• Authorization framework, not authentication. Grants access to resources without sharing credentials.
• Designed for APIApplication Programming Interface — Interface for software-to-software communication access delegation: “Allow this app to read my calendar” without giving it your password.
• Uses access tokens (short-lived) and refresh tokens (longer-lived).
• Not an authentication protocol by itself. It tells you “this token has access to X” — not “the person holding this token is Y.”

OpenID Connect (OIDC)

• Authentication layer built on top of OAuthOpen Authorization — Authorization framework for delegated access 2.0. This is what makes OAuthOpen Authorization — Authorization framework for delegated access useful for login.
• Adds an ID token (JWTJSON Web Token — Token format for claims-based authentication) containing user identity claims.
• Used by Google Sign-In, Sign in with Apple, most modern “Log in with…” flows.
• ID Token (JWTJSON Web Token — Token format for claims-based authentication): Base64-encoded JSON with header, payload, signature. Contains sub (subject/user ID), iss (issuer), aud (audience), exp (expiration), plus custom claims.

Protocol Selection

Scenario	Protocol	Why
Enterprise SSOSingle Sign-On — One authentication grants access to multiple systems (internal apps)	SAMLSecurity Assertion Markup Language — XML-based SSO protocol for web applications	Mature, wide IdPIdentity Provider — Service authenticating users for SSO/federation/SP support, designed for this
Modern web/mobile app login	OIDCOpenID Connect — Identity layer built on OAuth 2.0	Lightweight, JSON-based, mobile-friendly
APIApplication Programming Interface — Interface for software-to-software communication authorization (third-party access)	OAuthOpen Authorization — Authorization framework for delegated access 2.0	Designed for delegated access, scoped tokens
Legacy system integration	SAMLSecurity Assertion Markup Language — XML-based SSO protocol for web applications	Often the only option older systems support

Access Control Models

MAC (Mandatory Access Control)

• System enforces access based on labels/classifications. Users cannot change permissions.
• Data gets a classification label (Top Secret, Secret, Confidential). Users get a clearance level.
• Access granted only if clearance ≥ classification.
• Used in military and government. Rigid, high security, low flexibility.
• Example: SELinuxSecurity-Enhanced Linux — Linux kernel MAC implementation enforces MACMandatory Access Control — System-enforced access based on security labels policies on Linux.

DAC (Discretionary Access Control)

• Resource owner controls who has access. The person who creates a file decides who can read/edit it.
• Standard in most operating systems (file permissions, sharing settings).
• Flexible but risky — users can grant access too broadly. “Share with anyone with the link” is DACDiscretionary Access Control — Resource owner controls access permissions.
• Vulnerable to insider threat and accidental over-sharing.

RBAC (Role-Based Access Control)

• Permissions assigned to roles, users assigned to roles. No direct user-to-resource permissions.
• Admin, Editor, Viewer — each role has defined permissions. Users get the role that matches their job.
• Most common model in enterprise software.
• Scales well but can become unwieldy with role explosion (too many fine-grained roles).

ABAC (Attribute-Based Access Control)

• Access decisions based on attributes: user attributes (department, clearance, location), resource attributes (classification, owner), environment attributes (time, network, device).
• Most flexible model. Policies are rules: “Allow if user.department = Finance AND resource.classification ≤ Confidential AND time.hour between 8-18.”
• More complex to implement and audit than RBACRole-Based Access Control — Permissions assigned to roles, users assigned to roles.
• Used when RBACRole-Based Access Control — Permissions assigned to roles, users assigned to roles isn’t granular enough.

Rule-Based Access Control

• Access determined by predefined rules, not user identity or roles.
• Firewalls are rule-based: allow/deny based on source, destination, port, protocol.
• Time-based access: “This door unlocks between 7 AM and 7 PM.”

Model Comparison

Model	Who Decides	Flexibility	Complexity	Use Case
MACMandatory Access Control — System-enforced access based on security labels	System/admin	Lowest	High	Military, classified data
DACDiscretionary Access Control — Resource owner controls access permissions	Resource owner	Highest	Low	File systems, personal sharing
RBACRole-Based Access Control — Permissions assigned to roles, users assigned to roles	Admin (via roles)	Moderate	Moderate	Enterprise apps, most organizations
ABACAttribute-Based Access Control — Access decisions based on attributes (user, resource, environment)	Policy engine	Highest (controlled)	Highest	Fine-grained, context-aware access

Multifactor Authentication (MFA)

Something you know + something you have + something you are. MFAMulti-Factor Authentication — Requiring multiple authentication factors requires two or more different categories.

Factors

Category	Examples
Knowledge (something you know)	Password, PINPersonal Identification Number — Numeric passcode for authentication, security questions
Possession (something you have)	Phone (SMSShort Message Service — Text messaging on mobile networks/app), hardware token, smart card
Inherence (something you are)	Fingerprint, face recognition, retina scan
Location (somewhere you are)	GPSGlobal Positioning System — Satellite-based location tracking, IPInternet Protocol — Network layer addressing and routing geolocation, network-based
Behavior (something you do)	Typing pattern, gait analysis

MFA Methods

TOTPTime-based One-Time Password — Time-synchronized OTP (authenticator apps) (Time-Based One-Time Password)

• Algorithm generates a code based on shared secret + current time
• Codes rotate every 30 seconds
• Apps: Google Authenticator, Authy, Microsoft Authenticator
• Vulnerable to phishing if user enters code on fake site (attacker relays it in real time)

HOTPHMAC-based One-Time Password — Counter-based OTP (HMACHash-based Message Authentication Code — Combines hash with secret key for integrity + authentication-Based One-Time Password)

• Code generated based on shared secret + counter value
• Counter increments on each use, not time-based
• Doesn’t expire until used — less secure than TOTPTime-based One-Time Password — Time-synchronized OTP (authenticator apps) if token is intercepted

FIDO2Fast Identity Online 2 — Passwordless authentication standard (WebAuthn) / WebAuthn

• Hardware-based authentication using public key cryptography
• Device generates a key pair. Private key stays on device. Public key registered with service.
• Phishing-resistant: The authentication is bound to the origin (website domain). A fake site can’t request the credential.
• Implementations: YubiKey, Windows Hello, Touch ID/Face ID passkeys
• This is the direction the industry is moving. Passwordless.

Push Notification

• Auth request sent to registered device. User approves or denies.
• Vulnerable to MFAMulti-Factor Authentication — Requiring multiple authentication factors fatigue attacks (attacker spams push notifications until user approves to make it stop)
• Mitigation: number matching (user must enter a displayed number, not just tap approve)

SMSShort Message Service — Text messaging on mobile networks

• Code sent via text message.
• Better than nothing. Worse than everything else.
• Vulnerable to SIMSubscriber Identity Module — Smart card identifying a mobile subscriber swapping, SS7 interception, social engineering of carrier
• Not recommended for high-value targets. NISTNational Institute of Standards and Technology — US standards body, publishes CSF and SP 800 series deprecated SMSShort Message Service — Text messaging on mobile networks for MFAMulti-Factor Authentication — Requiring multiple authentication factors (then softened to “restricted”).

MFA Method Selection Logic

If the scenario says…	Choose…	Because…
”Phishing-resistant authentication”	FIDO2Fast Identity Online 2 — Passwordless authentication standard (WebAuthn)/WebAuthn	Origin-bound, can’t be phished
”Highest security, hardware-based”	FIDO2Fast Identity Online 2 — Passwordless authentication standard (WebAuthn) (YubiKey)	Hardware key, phishing-resistant, no shared secrets
”Enterprise-wide, balance of security and usability”	Push notification with number matching	Convenient, mitigates MFAMulti-Factor Authentication — Requiring multiple authentication factors fatigue
”Offline environments or air-gapped systems”	TOTPTime-based One-Time Password — Time-synchronized OTP (authenticator apps)	Works without network connectivity
”Legacy system, no app support”	SMSShort Message Service — Text messaging on mobile networks (but document the risk)	Better than nothing, but weakest option
”Counter MFAMulti-Factor Authentication — Requiring multiple authentication factors fatigue attacks”	Number matching or FIDO2Fast Identity Online 2 — Passwordless authentication standard (WebAuthn)	Requires user to verify, not just tap approve
”Passwordless authentication”	FIDO2Fast Identity Online 2 — Passwordless authentication standard (WebAuthn)/Passkeys	Eliminates password entirely

Access Control Model Selection Logic

If the scenario says…	Choose…	Because…
”Military/government, classification labels, mandatory”	MACMandatory Access Control — System-enforced access based on security labels	Label-based, system-enforced, no user discretion
”Users share files and set their own permissions”	DACDiscretionary Access Control — Resource owner controls access permissions	Owner-controlled, flexible
”Enterprise app, users grouped by job function”	RBACRole-Based Access Control — Permissions assigned to roles, users assigned to roles	Role-based, scales well, most common
”Access based on user department + time of day + device type”	ABACAttribute-Based Access Control — Access decisions based on attributes (user, resource, environment)	Attribute-based, context-aware, most flexible
”Firewall rules, time-based door locks”	Rule-based	Predefined rules, not identity-based
”Which model prevents role explosion?”	ABACAttribute-Based Access Control — Access decisions based on attributes (user, resource, environment)	Policies replace fine-grained roles
”Simplest to audit”	RBACRole-Based Access Control — Permissions assigned to roles, users assigned to roles	Clear role-to-permission mapping

Password Concepts

Password Policies

• Minimum length matters more than complexity rules. A 16-character passphrase beats an 8-character P@ssw0rd!.
• NISTNational Institute of Standards and Technology — US standards body, publishes CSF and SP 800 series 800-63B guidance: minimum 8 characters (preferably longer), no complexity rules, no forced rotation unless compromise is suspected, screen against known-breached passwords.
• Account lockout after failed attempts (but this enables denial of service — balance with rate limiting and CAPTCHACompletely Automated Public Turing Test to Tell Computers and Humans Apart — Challenge to verify human interaction).

Passwordless Authentication

• Replace passwords entirely with FIDO2Fast Identity Online 2 — Passwordless authentication standard (WebAuthn)/WebAuthn, certificate-based auth, or biometric + device attestation.
• Eliminates phishing, credential stuffing, and password reuse.
• The direction the industry is heading. Passkeys (Apple, Google, Microsoft) are the consumer-facing version.

Password Managers

• Generate and store unique, complex passwords for every service.
• User remembers one master password. Manager handles the rest.
• Enterprise: centralized password vaults (1Password Business, Bitwarden, LastPass) with sharing, audit trails, and access controls.

Privileged Access Management (PAM)

Privileged accounts (root, admin, service accounts with elevated permissions) are the highest-value targets. PAMPrivileged Access Management — Securing and monitoring privileged accounts controls how they’re used.

Just-In-Time (JIT) Access

• Elevated access granted only when needed, for a defined duration. No standing admin privileges.
• User requests access → approval workflow → temporary elevation → auto-revocation.
• Dramatically reduces the window of opportunity for attackers who compromise an account.

Password Vaulting

• Privileged credentials stored in an encrypted vault. Users check out credentials when needed.
• Vault logs every checkout — who, when, for what purpose.
• Automatic rotation after checkout or on a schedule.

Ephemeral Credentials

• Short-lived credentials that expire automatically. No long-lived APIApplication Programming Interface — Interface for software-to-software communication keys or service account passwords.
• Cloud-native: GCP Workload Identity, AWS IAMIdentity and Access Management — Framework for managing digital identities and permissions Roles for Service Accounts — credentials valid for minutes, not months.
• If compromised, the window of exploitation is minimal.

Break-Glass Procedures

• Emergency access when normal PAMPrivileged Access Management — Securing and monitoring privileged accounts workflows aren’t available (vault is down, approver is unreachable).
• Break-glass accounts exist but are heavily monitored. Using one triggers immediate alerting and mandatory post-use audit.
• Sealed credentials (physical or digital) opened only in emergency.