Identity and Access Management — Flashcards

IAM (Identity and Access Management) ensures the right people have access to the right resources at the right times with timely revocation when no longer needed. Four lifecycle events: (1) Hire — create account, provision role-based access, issue credentials. (2) Transfer — revoke old department access, add new department access. (3) Promotion — add elevated access, review whether prior access remains appropriate. (4) Separation — immediately disable all accounts, revoke all tokens, recover hardware. Failure at any transition creates security gaps.

Access creep (privilege creep): accumulation of permissions across multiple roles over time without revoking previous role access during transitions. Caused by incomplete deprovisioning at transfer/promotion events. An employee who moved through Finance, HR, and IT retains all three sets of permissions. Orphaned accounts: accounts belonging to departed employees that were never disabled. Caused by delayed or missed offboarding. Both create exploitable attack surfaces — orphaned accounts can be used by former employees or attackers; access creep violates least privilege.

Resolution — collect enough information to uniquely identify the individual: name, date of birth, employee ID, government ID number. Distinguishes this person from all others. Validation — verify that the collected information is genuine using authoritative sources (government databases, HR records). Confirms the ID is authentic and belongs to the person presenting it. Attestation — a qualified party (HR manager, identity officer) formally attests that identity verification was completed, creating an auditable record that authorized access was granted to the verified individual.

SSO allows users to authenticate once and access multiple applications without re-entering credentials. Key benefit: eliminates credential fatigue, reduces password sprawl, creates a single authentication audit log. 24-hour session timer: SSO sessions expire after a maximum lifetime (typically 24 hours) requiring full re-authentication; this limits the exposure window if a session token is compromised — stolen tokens cannot be used indefinitely. Primary risk: SSO is a single point of failure — if the account is compromised, the attacker gains simultaneous access to all connected applications.

LDAP (Lightweight Directory Access Protocol) is the protocol for querying and modifying directory services. It implements the X.500 standard, which defines the data model. The X.500 DIT has two object types: Container objects — Country (C), Organization (O), Organizational Unit (OU); hold other objects; organize the hierarchy. Leaf objects — users, computers, printers, service accounts; represent actual entities; cannot contain other objects. LDAP ports: 389 (unencrypted) and 636 (LDAPS over TLS).

A Distinguished Name (DN) is the globally unique identifier for an object in the LDAP directory. It specifies the full path from the leaf object up through all container objects to the root: CN=Alice Chen,OU=Marketing,O=Acme,C=US. A Common Name (CN) is only the name of the leaf object within its immediate parent container — it is not globally unique (two different OUs could each have a CN=Alice Chen). The DN is always used when the directory query requires a globally unique reference; the CN alone is insufficient for that purpose.

SAML (Security Assertion Markup Language) is an XML-based protocol for exchanging authentication and authorization assertions between parties. Identity Provider (IdP): authenticates the user and issues a signed XML assertion. Service Provider (SP): trusts the IdP assertion and grants access without requiring the user to re-authenticate. Not suitable for mobile: SAML assertions are XML documents exchanged via browser redirects. Native mobile apps do not use browser redirect flows, breaking the SAML mechanism. Modern mobile authentication uses OAuth 2.0 and OpenID Connect with JSON-based tokens instead.

OAuth 2.0 is an authorization framework. It grants a third-party application permission to access resources on behalf of a user without exposing credentials. It does NOT verify who the user is. OpenID Connect (OIDC) is an authentication protocol built on top of OAuth 2.0. It adds an ID token (JSON Web Token) that confirms the user's identity. Key rule: if the scenario requires knowing WHO the user is → OpenID Connect. If the scenario requires granting a third party ACCESS to resources on the user's behalf → OAuth 2.0. “Login with Google” uses OIDC for identity; sharing Google Drive access uses OAuth.

Federation extends identity trust across organizational boundaries through trust relationships between Identity Providers. A user authenticates at their home organization's IdP. The home IdP issues an identity assertion. Partner organizations that have established a trust relationship with the home IdP accept that assertion as proof of identity and grant access based on it — no separate account creation at the partner is needed. Examples: university research partnerships (home credentials access partner databases), corporate SaaS access using Active Directory credentials, “Login with Facebook/Google” on external sites. The key mechanism is the inter-organizational trust relationship, not account replication.

Interoperability is the ability of different IAM systems from different vendors to work together without requiring all parties to use the same platform. It prevents vendor lock-in and enables federation across heterogeneous environments. Four enabling standards: SAML — XML assertions for web SSO and federation. OAuth 2.0 — cross-platform authorization delegation. OpenID Connect — cross-platform identity verification on top of OAuth. SCIM (System for Cross-domain Identity Management) — automates provisioning and deprovisioning of users across multiple identity systems and SaaS platforms.

Deprovisioning must happen immediately upon separation — delayed offboarding leaves active accounts for attackers or disgruntled former employees. Complete deprovisioning requires: (1) Disable all accounts across all systems (AD, VPN, email, SaaS applications). (2) Revoke all active sessions — active SSO tokens, API keys, OAuth tokens, and application sessions remain usable until explicitly invalidated. (3) Remove from all security groups and distribution lists. (4) Recover hardware — laptops, mobile devices, hardware tokens, smart cards. Disabling only the primary password while leaving tokens and API keys active is an incomplete deprovision.

LDAP bind process: (1) User presents credentials. (2) Application sends a bind request to the LDAP server with the user's Distinguished Name and credentials. (3) LDAP server validates credentials against the stored directory entry. (4) LDAP server returns success or failure. (5) On success, the application grants access based on group memberships and attributes in the directory. LDAP's relationship to SSO: LDAP is a directory lookup protocol, not an SSO protocol. SSO products (Kerberos, SAML systems) use LDAP to look up user attributes and group memberships after authentication has occurred. LDAP alone does not provide SSO capability.