10.4 Identity & Access Management Solutions (Domain 4.7)

Identity and Access Management Solutions

Domain 4.7 asks you to design appropriate Identity and Access Management (IAM) solutions. The August 2026 outline lists: federated identity, Identity Providers (IdP), Single Sign-On (SSO), Multi-Factor Authentication (MFA), Cloud Access Security Broker (CASB), and secrets, key, and certificate management. In cloud application security, identity is often the real perimeter: networks are software-defined and APIs are reachable; who can call what dominates risk.

IAM Building Blocks (Exam Precision)

Domain 3.4 introduced identification/authentication/authorization for infrastructure; Domain 4.7 applies IAM design to application and SaaS access patterns and the material (secrets/certs) that underpins machine trust.

Why IAM Design Dominates Cloud Apps

Exam framing: When a breach starts with a stolen password to a console or SaaS app, preferred designs emphasize federation + MFA + least privilege + monitoring, not only a new network ACL.

Federated Identity

Federated identity allows a relying party (application, cloud platform, SaaS) to accept authentication assertions from an external Identity Provider under a trust relationship. Users authenticate once to their home organization; the app trusts the IdP’s claims (subject, groups, MFA strength, tenant ID).

How Federation Works (Conceptual)

1. User attempts to access the application (service provider / relying party).
2. App redirects to the configured IdP (or discovers it via email domain).
3. User authenticates to the IdP (password, MFA, passkey, etc.).
4. IdP issues a signed assertion/token (SAML assertion, OpenID Connect ID token, etc.).
5. App validates signature, issuer, audience, lifetime, and maps claims to local authorization.
6. App establishes an application session or API access token as designed.

Security Properties and Risks

Design Practices

• Explicit trust: pin issuers, metadata certificates, and endpoints; prefer automated but integrity-protected metadata refresh.
• Audience restriction: tokens must be for this app.
• Least-privilege claims mapping: map groups to roles carefully; deny by default.
• Session controls: app session lifetime, refresh rotation, logout (including federated logout where supported).
• Break-glass: emergency local admin accounts tightly controlled and monitored—not many standing local passwords.
• Workload federation: cloud roles assumed via OIDC from CI systems (short-lived), reducing static keys.

Federation vs Directory Synchronization

Federation trusts assertions at login time. Directory sync copies identities into another system. Many enterprises use both (sync for identity lifecycle + federation for AuthN). On the exam, federation is about cross-domain trust for authentication, not merely copying user rows.

Identity Providers (IdP)

An Identity Provider authenticates users (and sometimes devices) and issues identity assertions to relying parties. Cloud architectures may include:

IdP Security Responsibilities

Choosing and Integrating IdPs

• Prefer centralized workforce IdP for employee access to multi-cloud and SaaS.
• Separate customer identity from workforce identity stores when populations and risk differ.
• For multi-tenant SaaS products you build, support customer IdP federation (SAML/OIDC) as an enterprise feature—and validate every tenant’s metadata carefully to prevent cross-tenant federation mix-ups.
• Avoid each application inventing its own password database when federation is feasible.

Exam trap: Treating “we have an IdP” as complete IAM. Authorization design, secrets for workloads, and SaaS shadow IT still remain.

Single Sign-On (SSO)

Single Sign-On lets a user authenticate once and access multiple applications without separate logins for each. SSO is commonly implemented via federation protocols (SAML, OpenID Connect) or enterprise SSO portals.

Benefits and Tradeoffs

SSO Design Checklist

1. Protocol choice fit: OIDC for modern apps; SAML still common for enterprise SaaS.
2. MFA at SSO—do not allow password-only for privileged or sensitive apps.
3. Application onboarding process—every SSO app registered with correct ACS/redirect URIs (open redirect risks).
4. Session management—idle timeouts, absolute timeouts, step-up auth for sensitive actions.
5. Logout behavior—local logout vs single logout expectations documented.
6. Non-SSO exceptions—service accounts and break-glass inventoried.
7. Mobile and API patterns—SSO for users; OAuth flows for delegated API access; never embed user passwords in mobile apps.

SSO vs Federation Wording on Exams

• Federation emphasizes trust between security domains and assertion acceptance.
• SSO emphasizes user experience of one login → many apps. They often co-occur: federation enables SSO across domains. A single web app with one local login is not enterprise SSO.

Multi-Factor Authentication (MFA)

MFA requires two or more independent factors from categories such as something you know, have, or are (and modern phishing-resistant device-bound authenticators).

Factor Quality

MFA Architecture Practices

• Enforce MFA for workforce cloud consoles, email, VPN/ZTNA, and sensitive SaaS.
• Step-up MFA for high-risk transactions inside applications (payments, wire, bulk export).
• Conditional MFA based on risk signals without creating easy bypasses.
• Protect recovery paths—account recovery is a frequent MFA bypass if weak.
• Service accounts: MFA does not apply the same way; use workload identity and secret controls instead of shared human MFA devices.
• Measure coverage—MFA registration gaps are findings.

MFA Failures the Exam Likes

Bottom line: MFA is one of the highest-value IAM controls for interactive users; design quality of factors and recovery matters as much as “MFA on” checkboxes.

Cloud Access Security Broker (CASB)

A Cloud Access Security Broker is a security enforcement point between consumers and cloud service providers that applies enterprise security policies to cloud use. CASB addresses SaaS and cloud service visibility/control gaps that traditional network firewalls miss—especially for managed devices and sanctioned apps, and sometimes for shadow IT discovery.

CASB Deployment Modes (Conceptual)

Many programs combine modes.

CASB Policy Capabilities

CASB in the IAM Architecture

CASB complements IdP/SSO/MFA:

• IdP authenticates the user.
• SSO delivers access to SaaS.
• MFA strengthens AuthN.
• CASB enforces what users do with data in cloud services and discovers unmanaged services.
• Secrets management protects keys used by integrations CASB may monitor.

Exam discrimination: CASB is not a substitute for application secure coding of your software; it is a control for cloud service consumption and SaaS security posture. If the stem is about your developers’ API BOLA, CASB is usually the wrong primary answer; if the stem is about employees uploading PII to unsanctioned storage, CASB fits.

Secrets, Key, and Certificate Management

Cloud apps depend on secrets (API tokens, passwords, connection strings), cryptographic keys, and certificates. Managing them is an IAM-adjacent control plane for machine and application trust.

Secrets Management

Key Management

Certificate Management

Unified Lifecycle View

Anti-Patterns

1. Long-lived access keys in Git history.
2. One shared production secret for all microservices.
3. Manual cert renewal on a sticky note calendar.
4. Granting developers permanent decrypt on all CMKs.
5. Copying production secrets into lower environments with weaker controls.
6. Leaving default certificates on appliances and gateways.

End-to-End IAM Design Scenario

A multi-cloud enterprise: workforce uses a central IdP with phishing-resistant MFA for admins; SSO/federation into cloud consoles and SaaS; CASB API mode on major SaaS for DLP and sharing controls; applications validate OIDC tokens and enforce RBAC; microservices use workload identities—not static keys; secrets live in a vault with rotation; TLS certificates auto-renew at the gateway and mesh. Developers never store cloud access keys in repos. That architecture hits every Domain 4.7 bullet.

Putting Domain 4.7 Together for the Exam

1. AuthN path: IdP → MFA → federation/SSO → app session/token validation.
2. AuthZ path: claims/roles → least privilege in app and cloud IAM—never skip object-level checks.
3. SaaS consumption: CASB for visibility/control beyond pure AuthN.
4. Machine trust: secrets/keys/certs lifecycle with short-lived credentials preferred.
5. Prefer centralized identity policy over per-app password silos for workforce access.

Common Traps

• Confusing SSO with authorization (login ≠ permission).
• Federation without validating token signatures/audience.
• MFA checkbox with weak SMS-only for global admins and weak recovery.
• Calling any proxy a CASB without policy/visibility functions.
• Excellent human MFA while hardcoding cloud keys in CI.
• Forgetting certificate expiry as an availability and security incident.
• Assuming CASB fixes vulnerabilities in your custom application code.