Implement and maintain identity and access management

Provisioning/deprovisioning, permission assignments, identity proofing, federation (SSO, SAML, OAuth, OIDC), access control models (MAC, DAC, RBAC, ABAC), MFA (TOTP, HOTP, FIDO2), password concepts (passwordless, managers), and privileged access management (JIT, vaulting, ephemeral credentials).

Exam approach: “Given a scenario” — expect to configure access controls for a described org, select the right federation protocol, and troubleshoot IAM misconfigurations. Understanding the tradeoffs between access control models is critical.

Offensive context: Understanding how attackers intercept and manipulate JWTs and OIDC 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 IAM 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, API keys, VPN 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 MFA enforcement
• Centralized deprovisioning = disable one account, all access stops

SAML (Security Assertion Markup Language)

• XML-based, mature, enterprise-focused
• Identity Provider (IdP): Authenticates the user (Google Workspace, Okta, Azure AD)
• Service Provider (SP): The application being accessed
• Flow: User hits SP → SP redirects to IdP → IdP authenticates → IdP sends SAML assertion (XML) 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 API 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 OAuth 2.0. This is what makes OAuth useful for login.
• Adds an ID token (JWT) containing user identity claims.
• Used by Google Sign-In, Sign in with Apple, most modern “Log in with…” flows.
• ID Token (JWT): 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 SSO (internal apps)	SAML	Mature, wide IdP/SP support, designed for this
Modern web/mobile app login	OIDC	Lightweight, JSON-based, mobile-friendly
API authorization (third-party access)	OAuth 2.0	Designed for delegated access, scoped tokens
Legacy system integration	SAML	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: SELinux enforces MAC 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 DAC.
• 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 RBAC.
• Used when RBAC 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
MAC	System/admin	Lowest	High	Military, classified data
DAC	Resource owner	Highest	Low	File systems, personal sharing
RBAC	Admin (via roles)	Moderate	Moderate	Enterprise apps, most organizations
ABAC	Policy engine	Highest (controlled)	Highest	Fine-grained, context-aware access

Multifactor Authentication (MFA)

Something you know + something you have + something you are. MFA requires two or more different categories.

Factors

Category	Examples
Knowledge (something you know)	Password, PIN, security questions
Possession (something you have)	Phone (SMS/app), hardware token, smart card
Inherence (something you are)	Fingerprint, face recognition, retina scan
Location (somewhere you are)	GPS, IP geolocation, network-based
Behavior (something you do)	Typing pattern, gait analysis

MFA Methods

TOTP (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)

HOTP (HMAC-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 TOTP if token is intercepted

FIDO2 / 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 MFA 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)

SMS

• Code sent via text message.
• Better than nothing. Worse than everything else.
• Vulnerable to SIM swapping, SS7 interception, social engineering of carrier
• Not recommended for high-value targets. NIST deprecated SMS for MFA (then softened to “restricted”).

MFA Method Selection Logic

If the scenario says…	Choose…	Because…
”Phishing-resistant authentication”	FIDO2/WebAuthn	Origin-bound, can’t be phished
”Highest security, hardware-based”	FIDO2 (YubiKey)	Hardware key, phishing-resistant, no shared secrets
”Enterprise-wide, balance of security and usability”	Push notification with number matching	Convenient, mitigates MFA fatigue
”Offline environments or air-gapped systems”	TOTP	Works without network connectivity
”Legacy system, no app support”	SMS (but document the risk)	Better than nothing, but weakest option
”Counter MFA fatigue attacks”	Number matching or FIDO2	Requires user to verify, not just tap approve
”Passwordless authentication”	FIDO2/Passkeys	Eliminates password entirely

Access Control Model Selection Logic

If the scenario says…	Choose…	Because…
”Military/government, classification labels, mandatory”	MAC	Label-based, system-enforced, no user discretion
”Users share files and set their own permissions”	DAC	Owner-controlled, flexible
”Enterprise app, users grouped by job function”	RBAC	Role-based, scales well, most common
”Access based on user department + time of day + device type”	ABAC	Attribute-based, context-aware, most flexible
”Firewall rules, time-based door locks”	Rule-based	Predefined rules, not identity-based
”Which model prevents role explosion?”	ABAC	Policies replace fine-grained roles
”Simplest to audit”	RBAC	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!.
• NIST 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 CAPTCHA).

Passwordless Authentication

• Replace passwords entirely with FIDO2/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. PAM 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 API keys or service account passwords.
• Cloud-native: GCP Workload Identity, AWS IAM 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 PAM 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.