Identity and Access Management

Overview

Identity and Access Management (IAM) is the discipline of ensuring that the right people have access to the right resources at the right times, and that access is revoked when it is no longer appropriate. The core challenge is managing the entire identity lifecycle from the moment an employee joins an organization through all role changes until separation, while preventing both under-provisioning (legitimate users locked out) and over-provisioning (excessive access accumulation).

Identity Lifecycle Events

Every employee identity passes through a series of lifecycle events that require IAM action:

• Hire / onboarding — create account, provision access appropriate to job role, issue credentials
• Transfer — change department access; revoke access to previous department resources; add access for new department. Failure to revoke creates access accumulation.
• Promotion — add elevated access for new responsibilities. Previous access may or may not remain appropriate and must be reviewed.
• Separation / offboarding — immediately disable all accounts, revoke all credentials, recover issued hardware. Delayed offboarding leaves active accounts for departed employees — a critical security gap.

Organizations that lack automated IAM workflows frequently accumulate orphaned accounts (accounts belonging to departed employees that were never disabled) and access creep (users accumulating permissions from every role they ever held). Both create exploitable attack surfaces.

Identity Proofing

Before an identity is provisioned in an IAM system, the organization must verify that the person requesting access is who they claim to be. This process is called identity proofing and proceeds through three stages:

Identity proofing is particularly important for privileged accounts where the consequences of granting access to the wrong person are severe. It is also the basis for strong authentication systems: you can only issue a credential (smart card, certificate, hardware token) once identity has been formally proofed.

Provisioning and Deprovisioning

Provisioning is the process of creating accounts, assigning permissions, and issuing credentials when access is needed. Best-practice provisioning is role-based: the job role determines a standard set of access rights, and the user is assigned to that role rather than individual permissions being granted ad hoc.

Deprovisioning is the process of removing access when it is no longer needed. Effective deprovisioning requires:

• Disabling accounts immediately upon separation, not scheduling for later
• Revoking all active sessions, tokens, and API keys, not just the primary password
• Removing from all security groups and distribution lists
• Recovering hardware tokens, smart cards, and issued equipment

Single Sign-On (SSO)

Single Sign-On allows users to authenticate once and then access multiple applications without being prompted for credentials again. The user's authenticated session is shared with all applications that trust the SSO provider. This reduces credential fatigue, eliminates the need to manage separate passwords for each application, and creates a single audit log of authentication events.

The 24-hour session timer: SSO sessions have a maximum lifetime, typically 24 hours. After 24 hours, the user must re-authenticate with their full credentials regardless of activity. This timer limits the window of exposure if an SSO token is compromised — an attacker who captures a token cannot use it indefinitely. The timer is the exam's primary focus regarding SSO session mechanics.

SSO trade-off: SSO creates a single point of failure for authentication. If the SSO provider is unavailable, users cannot authenticate to any dependent application. If the SSO account is compromised, the attacker gains access to all connected applications simultaneously. These risks are managed through MFA on the SSO login, high-availability SSO infrastructure, and short session timeouts.

LDAP and X.500 Directory Architecture

LDAP (Lightweight Directory Access Protocol) is the protocol used to query and modify directory services. It is the protocol layer; the underlying data model comes from the X.500 standard, which defines how directory information is structured and named.

The X.500 model organizes directory entries into a Directory Information Tree (DIT) with a strict hierarchy. Entries in the DIT fall into two categories:

Common Name (CN) identifies a specific leaf object within its container. A complete Distinguished Name (DN) uniquely identifies an object by specifying its full path through the DIT hierarchy, for example: CN=John Smith,OU=Finance,O=Acme Corp,C=US

In Active Directory, LDAP operates on port 389 (unencrypted) or port 636 (LDAPS — LDAP over TLS). The exam typically expects knowledge that LDAP uses 389 and LDAPS uses 636.

LDAP Authentication Flow

When a user authenticates to a system using LDAP as the back-end directory:

1. The user presents credentials (username + password)
2. The application sends a bind request to the LDAP server with the user's DN and credentials
3. The LDAP server validates the credentials against its stored directory entry
4. The LDAP server returns success or failure to the application
5. On success, the application grants access based on the user's group memberships and attributes in the directory

LDAP is not itself an SSO protocol; it is a directory lookup protocol. SSO products (like Active Directory with Kerberos, or SAML-based systems) use LDAP to look up user attributes and group memberships after authentication has occurred.

SAML (Security Assertion Markup Language)

SAML is an XML-based standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). When a user accesses an SP, the SP redirects them to the IdP to authenticate; the IdP issues a signed XML assertion confirming authentication; the user presents this assertion to the SP, which grants access without the user entering credentials on the SP's site.

Critical limitation: SAML was not designed for mobile applications. SAML assertions are XML documents exchanged via browser redirects. Mobile apps often use native clients rather than browsers, which breaks the redirect-based SAML flow. For mobile authentication scenarios, OAuth/OpenID Connect is the modern replacement.

OAuth and OpenID Connect

OAuth and OpenID Connect are often confused. Understanding the distinction is a high-yield exam topic:

Common exam trap: A scenario describes an application that needs to know who the user is. OAuth alone is wrong — OAuth only handles authorization (what the app can access), not authentication (who the user is). OpenID Connect is the correct answer when identity verification is required.

Real-world example: “Log in with Google” buttons on websites use OpenID Connect to verify identity (Google is the IdP; the website is the RP — Relying Party). OAuth is used when you authorize a third-party app to access your Google Drive on your behalf without giving the app your Google password.

Federation and Interoperability

Federation extends identity trust across organizational boundaries. Instead of creating duplicate accounts in every partner organization's directory, federation allows users to authenticate with their home organization's IdP and then access resources at partner organizations using a trust relationship between the organizations' identity systems.

Examples of federation in practice:

• University students accessing research resources at partner universities using their home university credentials
• Employees of a company accessing a SaaS platform using their corporate Active Directory credentials rather than a separate SaaS-specific account
• “Login with Facebook” or “Login with Google” buttons on external websites — the user's Google/Facebook identity is federated to the external site

Interoperability refers to the ability of different IAM systems from different vendors to work together using common standards (SAML, OAuth, OIDC, SCIM). Interoperability prevents vendor lock-in and enables federation across heterogeneous environments where not every organization uses the same identity platform.