Identity management Study Guide

📖 Core Concepts Identity Management – Process that registers users (or devices) and assigns them the correct access rights during onboarding. Access Management – Enforces the rights defined by identity management; the “gatekeeper” that decides what a user can actually do. Digital Identity – Online representation of a person, device, or application, containing identifying data and any ancillary attributes. Identity Federation – Trust relationship where one system (identity provider) authenticates a user and shares a signed assertion with other systems (service providers). Role‑Based Access Control (RBAC) – Grouping of permissions into roles that map to job functions; assigning a role to a user grants all its permissions automatically. Identity Governance & Administration (IGA) – Policies, processes, and organizational units responsible for defining schemas, overseeing provisioning, and ensuring compliance. 📌 Must Remember IAM = Identity + Access Management – terms are interchangeable in most contexts. Authentication ≠ Authorization – Auth = “Who are you?”; Authz = “What can you do?” Key federation protocols: SAML 2.0 (XML‑based assertions) and OpenID Connect (OAuth‑based). Primary IAM system types: Access‑governance (who can access what) IAM (auth + authz + provisioning) Entitlement‑management (permission assignment) User‑provisioning (account lifecycle automation) Delegation lets a local admin act on behalf of another user without full admin rights. Privacy rule: Personal identifying information must be protected per organizational guidelines. 🔄 Key Processes User Provisioning Workflow Request → Approval → Account creation → Role assignment → Credential delivery → Ongoing audit. Authentication Flow (e.g., OpenID Connect) User → Client app → Redirect to Identity Provider → User authenticates → ID token returned → Client validates token → Access granted. Federation Assertion Exchange (SAML) User → Service Provider → Redirect to Identity Provider → IdP authenticates → Generates signed SAML Assertion → Returns to SP → SP validates and creates session. Delegation Process Delegator selects delegate → System creates scoped delegation token/role → Delegate performs limited actions → Token expires/revoked. 🔍 Key Comparisons SAML vs. OpenID Connect SAML: XML‑based, heavy, used mainly for enterprise SSO. OpenID Connect: JSON/REST, built on OAuth 2.0, lightweight for modern web/mobile apps. Authentication vs. Authorization Authentication: Verifies identity (password, biometrics, token). Authorization: Determines allowed actions after identity is proven. Access‑Governance vs. Entitlement‑Management Access‑Governance: Focuses on “who may access which resource.” Entitlement‑Management: Focuses on “what specific permissions are granted.” ⚠️ Common Misunderstandings “IAM only handles passwords.” – IAM also covers roles, provisioning, federation, delegation, and privacy controls. “If I’m authenticated, I automatically have all rights.” – Authentication only proves identity; authorization still restricts actions. “SAML and OpenID Connect are interchangeable.” – They differ in format, typical use‑cases, and token handling; choose based on ecosystem. 🧠 Mental Models / Intuition “Lock and Key” model: Authentication is the key that fits the lock (identity). Authorization is the door the key opens – different doors for different keys. “Circle of Trust” diagram: Visualize identity provider at the center; every service provider sits on the circumference, all trusting the central assertion. “Role as a Bundle” metaphor: Think of a role like a pre‑packed grocery bag; give the bag to a user and they receive everything inside without picking items individually. 🚩 Exceptions & Edge Cases Hybrid federation – Some environments use both SAML (legacy) and OpenID Connect (new apps) simultaneously; mapping of attributes may require translation. Delegation scopes – Delegated rights can be time‑bounded or resource‑bounded; ensure the token’s scope matches the intended temporary authority. Multi‑factor authentication (MFA) bypass – Certain service accounts may be exempt for automation; document and monitor these exceptions carefully. 📍 When to Use Which Choose SAML when integrating with large, enterprise SSO portals or legacy applications that require XML assertions. Choose OpenID Connect for modern web/mobile services, especially when you already use OAuth 2.0 for API access. Use a dedicated Access‑Governance tool if you need fine‑grained policy enforcement across many heterogeneous resources. Use an Entitlement‑Management system when the primary challenge is managing large numbers of granular permissions rather than whole roles. 👀 Patterns to Recognize Single Sign‑On (SSO) pattern: One authentication event → multiple service providers receive the same signed assertion. “Least Privilege” pattern: Users receive the minimal role needed; look for role hierarchies that could cause privilege creep. Provision‑Deprovision cycle: New hire → role assignment → periodic audit → termination → account disable → record retention. 🗂️ Exam Traps Confusing “authentication” with “authorization.” Test items may phrase “who can do X?” – that’s authorization, not authentication. Assuming SAML is always more secure than OpenID Connect. Security depends on implementation (signing, token expiration), not the protocol name. Over‑generalizing “IAM = only passwords.” Look for answer choices that mention MFA, federation, or role management – those are also core IAM functions. Misreading “access‑governance system” as “identity‑provisioning system.” Governance focuses on policy enforcement; provisioning automates account lifecycle.