Identity and Access Management (IAM)

Decision frame

IAM answers four different questions: Who or what is this identity? How is the current claimant authenticated? What may the resulting subject do? How does access remain aligned as people, devices, services, and relationships change? Keep identity proofing, authentication, authorization, and lifecycle separate when analyzing a scenario.

Grant access from approved business need and least privilege. Prefer individual, attributable, time-bounded access. Treat human, service, device, workload, privileged, shared, and external identities according to their risks.

Objective map

Identity proofing and authentication

Identity proofing establishes confidence that a claimed real-world identity is correctly bound to a digital identity. Use evidence, verification, authoritative sources, enrollment controls, and fraud resistance proportional to risk and law. Authentication later verifies that the claimant controls approved factors or credentials.

Factors are something known, possessed, or inherent, with contextual signals such as device, location, network, time, and behavior. Multiple items from the same category are not true multi-factor authentication. Passwords need length, blocklists, protected storage, rate limiting, secure recovery, and resistance to reuse and phishing. One-time codes improve some attacks but can still be phished. Hardware-backed, verifier-bound cryptographic authenticators can provide stronger phishing resistance. Biometrics are probabilistic identifiers and need false accept/reject analysis, liveness, privacy, enrollment, and fallback.

Risk-based authentication adjusts requirements from context but must not become an opaque bypass. Recovery is often the weakest path: verify the claimant, notify affected users, limit recovery privileges, protect support staff, and monitor unusual resets. Session management needs secure tokens, timeout, rotation, revocation, reauthentication for sensitive actions, and protection against fixation and theft.

Federation and single sign-on

Federation lets one domain rely on identity assertions or tokens from another. Define identity provider, relying party or service provider, trust anchor, protocol, claims, audience, validity, signing keys, and lifecycle. SAML commonly supports enterprise browser federation. OpenID Connect adds an identity layer over OAuth 2.0 for supported application patterns. OAuth is primarily delegated authorization; an access token is not automatically proof of user authentication for every design. Kerberos provides ticket-based authentication within trusted realms and is sensitive to time, key, and delegation design.

Validate issuer, audience, signature, algorithm, time, nonce or state where applicable, redirect URI, and claim mapping. Minimize token lifetime and scope. Protect signing keys and metadata changes. Map groups or attributes deliberately and prevent claim manipulation from creating privilege. Plan identity-provider outage, key rotation, merger, supplier termination, and emergency access.

SSO reduces password sprawl and centralizes policy but increases dependency and blast radius. Use strong controls, resilient design, monitoring, and step-up authentication for higher-risk actions.

Authorization models

Discretionary access control lets an owner decide within policy. Mandatory access control uses centrally controlled labels and clearances. Role-based access control groups permissions by job function. Rule-based access uses system rules such as network or time conditions. Attribute-based access control evaluates attributes of subject, resource, action, and environment. Risk-adaptive approaches incorporate contextual risk. Most real systems combine models.

Define default deny, least privilege, need to know, separation of duties, and complete mediation. Prevent toxic combinations such as initiating and approving the same payment. Privileged access management should control request, approval, credential or session issuance, just-in-time elevation, recording, command or action constraints, monitoring, and review. Break-glass access must be limited, independently monitored, tested, and reviewed after use.

Authorization decisions require current context. Group membership, role, device, location, data classification, relationship, transaction amount, and risk can change. Cache decisions only within a safe validity period and invalidate when authoritative attributes change.

Identity lifecycle

Create identities from authoritative events. Obtain owner and access approval, enforce separation, and provision only required entitlements. For movers, reassess access rather than adding new permissions indefinitely. For leavers, disable access promptly, revoke sessions and credentials, transfer ownership, preserve required records, recover assets, and monitor for delayed integrations.

Reconcile directories, applications, cloud platforms, databases, devices, facilities, secrets, keys, and service accounts. Access reviews should give reviewers understandable entitlements and use evidence; rubber-stamp certification creates false assurance. Identify dormant, orphaned, shared, generic, duplicate, and overprivileged accounts. Service identities need owner, purpose, credential lifecycle, allowed workloads, and retirement trigger.

Resilient implementation

Directories and identity services are critical infrastructure. Protect administrative tiers, replicas, backups, time sources, DNS, certificates, connectors, synchronization, and recovery. Separate identity administration from ordinary workstation use. Monitor authentication failures, unusual success, impossible travel where meaningful, new factors, resets, privilege change, consent, token issuance, and dormant-account use.

Fail securely without making recovery impossible. An identity outage plan should define cached access, emergency roles, offline procedures, maximum duration, monitoring, and reconciliation. Do not create a permanent shared administrator password as the continuity strategy.

Decision patterns

Scenario drill

A company acquires another organization and must provide access to selected applications within 30 days without merging directories immediately.

1. Establish a bounded federation trust and authoritative lifecycle contacts.
2. Map a minimal set of partner groups or attributes to application roles; do not import broad administrator claims.
3. Validate issuer, audience, signatures, time, keys, session duration, and deprovisioning.
4. Require stronger authentication and approval for privileged access.
5. Monitor token issuance, unusual access, claim changes, and inactive identities.
6. Define transition, review, supplier-like separation, and trust termination.

Common traps

• Calling OAuth an authentication protocol without the identity-layer design.
• Counting two knowledge secrets as multi-factor authentication.
• Adding new mover access without removing incompatible old access.
• Treating SSO as risk reduction without addressing central dependency.
• Using group membership without ownership, expiry, and reconciliation.
• Giving service accounts permanent broad credentials because no human uses them.
• Designing a break-glass path that is never tested or monitored.

Self-check

1. Distinguish proofing, identification, authentication, authorization, and accounting.
2. Compare RBAC and ABAC for a high-change environment.
3. Trace an OIDC sign-in from issuer to application session and name validation steps.
4. Design lifecycle controls for a contractor, service account, and privileged administrator.
5. Explain how identity services recover during a major outage without normalizing bypass.

Primary references

• ISC2 CISSP exam outline
• NIST SP 800-63 Digital Identity Guidelines
• NIST SP 800-207: Zero Trust Architecture