Identity and Access Management (IAM)
How enterprise identity actually works: the joiner-mover-leaver lifecycle, SAML and OIDC, token validation, RBAC versus ABAC, workload identity, privileged access, and the failure modes that leave standing admin behind.
Identity and access management is the control plane that answers three questions about every request in an estate: who is this, what are they allowed to do, and what did they do. It is the layer that determines blast radius, because in a reasonably maintained system an attacker rarely breaks cryptography — they arrive holding valid credentials and use exactly the access those credentials carry.
That framing matters because it changes the objective. The goal is not to make authentication hard. It is to make any single compromised identity worth as little as possible, and to make the fact of its use visible.
What IAM Is
Three distinct mechanisms are usually collapsed into one word:
- Authentication establishes who is making the request, and with what confidence. A password establishes less than a hardware-backed factor; both establish something about a moment, not about the rest of the session.
- Authorization decides whether that principal may perform this operation on this resource, right now. It is a per-request decision even when it is cached.
- Audit records the decision so a human can reconstruct what happened. Without decision logs the other two are unfalsifiable.
A well-built IAM layer also covers identities that are not people. In most estates, workloads, service accounts, and automation outnumber humans, and they are typically the weakest-governed population.
The Identity Lifecycle
Joiner, mover, leaver — the whole discipline in three events. Most organisations do the first one well because it blocks work, and the other two badly because nothing visibly breaks when they are skipped.
JOINER MOVER LEAVER
│ │ │
▼ ▼ ▼
HR / source of truth (one record per human)
│ │ │
▼ ▼ ▼
identity provider ── groups ── entitlements ── revocation
│ │ │
├─ SCIM push ─────┴────────────────────────────┤
▼ ▼
applications applications
│ │
├─ local accounts? ← the SSO bypass │
├─ personal API tokens? ← survives offboarding │
└─ cloud roles / keys? ← often missed ────────┘
THE MOVER IS THE DANGEROUS ONE:
grants are additive, revocation is nobody's job,
so privilege accumulates with tenure.Pick one system of record for humans and have everything else derive from it. Provisioning to applications should be pushed automatically — the standard mechanism for SaaS is SCIM — so that the identity provider is genuinely authoritative rather than merely typical. Anything with its own local login, its own API tokens, or a cloud key issued out of band sits outside that guarantee and will survive an offboarding.
The mover event is the one that quietly accumulates risk. Someone moves from support to engineering to platform, and at each step new access is granted while old access is left alone, because removing it risks breaking something and nobody is accountable for the removal. Over a few years the most dangerous account in the company belongs to a well-liked employee who has been there the longest. The fix is structural: grant through groups tied to role, re-derive membership on the move, and make access reviews compare entitlements against current role rather than merely confirming the person still works here.
Authentication Protocols
| Protocol | What it is for | Notes |
|---|---|---|
| SAML | Browser-based single sign-on to enterprise applications | XML assertions posted through the browser; long-established and widely supported; signature and audience validation are where implementations go wrong |
| OAuth 2.0 | Delegated authorization — letting an application act on a resource on your behalf | Not an authentication protocol. Treating an access token as proof of who the user is, without an identity layer, is the classic misuse |
| OIDC | Authentication layered on OAuth 2.0 | Adds an ID token with claims about the user and a discovery mechanism for keys; the usual default for new applications |
| SCIM | Provisioning and deprovisioning accounts into applications | The half of SSO that people skip; without it, SSO controls login but not account existence |
| Kerberos / LDAP | Internal directory and network authentication | Still load-bearing in many estates; frequently the path where modern factors are not enforced |
Two properties matter more than the choice between them. Multi-factor authentication should be phishing-resistant on any path that reaches administrative capability, because one-time codes can be relayed in real time by a proxy. And every legacy protocol still enabled is an alternative front door that usually predates the factor policy.
Validating a Token
Resource servers get this wrong in consistent ways, and the failures are silent — a broken validator accepts everything and looks perfectly healthy.
- Verify the signature against the issuer’s published keys, fetched from the issuer’s key endpoint and cached with an eye to rotation. Never let the token select its own algorithm or key material; pin the expected algorithm and reject anything else, including “none”.
- Check the issuer and the audience. A perfectly valid token minted for a different service in the same identity provider is a valid signature and the wrong answer.
- Check expiry and not-before with a small, bounded clock skew allowance rather than a generous one.
- Authorize on claims at the resource, not at the gateway alone. A gateway that authenticates and forwards blindly turns every internal service into an open one.
- Plan for revocation. A self-contained token remains valid until it expires; there is no callback. Keep access-token lifetimes short and put revocation on the refresh exchange, or use introspection against the issuer where immediate revocation genuinely matters. Choosing a long lifetime for convenience is choosing a long window after a theft.
Authorization Models
| Model | Decides on | Strength | Where it breaks |
|---|---|---|---|
| RBAC | Roles held by the principal | Simple to reason about, reviews well, maps to job function | Role explosion once reality is multi-dimensional — role per team per environment per data class |
| ABAC | Attributes of principal, resource, and context | Expressive; handles environment, tenant, classification, time | “Who can access this?” becomes a computation rather than a lookup, which makes reviews and audits harder |
| ReBAC | Relationships in a graph (owner, member, parent) | Natural for documents, folders, and nested tenancy | Needs a purpose-built store and careful invalidation; hand-rolled versions get slow and wrong |
| ACLs | Explicit entries per object | Precise for small, sharply-bounded sets | Unmanageable alone at scale; no way to answer questions across objects |
Most mature systems converge on the same shape: coarse-grained roles for the broad grant, attributes for context such as environment and data classification, and relationship checks inside the application for object-level ownership. Centralise the decision in policy that is versioned and tested like code, distribute the enforcement into the services, and log every decision with enough context to answer a question about it months later. Decide explicitly what happens when the policy service is unreachable — an authorization layer that fails open under load is not a control, and this is exactly the behaviour nobody tests.
Workload Identity
Machine identities are the larger population and the softer target. The dominant failure is the long-lived static key: created once, pasted into a configuration, shared between environments, never rotated, and valid for as long as it exists.
The durable pattern is to stop distributing secrets and start proving identity. A workload authenticates using something the platform can attest — an instance identity document, a mounted service-account token, a signed identity issued by the platform — and exchanges it for a short-lived credential scoped to one job. A build system can federate to a cloud role the same way, so pipelines hold no standing keys at all. Where a static credential genuinely cannot be avoided, it needs a named owner, an automated rotation path, and a revocation drill that has actually been run. See secrets management for the storage and distribution side of this.
Privileged Access
The objective is no standing administrative access. Elevation should be requested, justified, time-bounded, and recorded, so that the normal state of every account is ordinary. Break-glass accounts exist for the case where the identity provider itself is unavailable; they are kept offline, alarm loudly on use, and are exercised on a schedule so that the first real use is not also the first attempt.
Separation of duties belongs here too: the principal that approves a change should not be the principal that applies it, and the principal that can alter audit logs should be neither. This is the control that converts a single compromised account from a catastrophe into an alert.
Failure Modes
| Anti-pattern | What it produces | Fix |
|---|---|---|
| Standing administrative access | Every phishing success is immediately a full compromise | Just-in-time elevation with expiry and an audit record |
| Local application accounts alongside SSO | A login path that ignores factors, policy, and offboarding | Disable local login; provision and deprovision through the directory |
| Shared accounts and shared keys | Attribution is impossible; rotation is never done because it breaks everyone | One identity per human and per workload, always |
| Deprovisioning only in the identity provider | Personal tokens and cloud keys outlive the employment | Offboarding enumerates tokens, keys, and app-local accounts too |
| Access reviews that only confirm employment | Accumulated privilege is rubber-stamped quarterly | Review entitlements against current role; default to removal |
| Deeply nested groups | Nobody can compute what a grant actually confers | Flatten, limit nesting depth, and make effective-access queryable |
| Service accounts owned by an individual | Orphaned automation with live credentials after they leave | Team ownership, recorded, with rotation tested |
| Authorization enforced only at the gateway | Any internal foothold reaches every service | Enforce at the resource; see zero trust |
Checklist
- One system of record for human identity; applications federate to it
- Provisioning and deprovisioning are automated, not ticket-driven
- Phishing-resistant factors required on every administrative path
- Legacy authentication paths enumerated and disabled or fenced
- Token validation checks signature, issuer, audience, expiry, and algorithm
- Access-token lifetimes short enough that revocation latency is acceptable
- No standing admin; elevation is time-bounded and logged
- Break-glass accounts monitored, alarmed, and rehearsed
- Workloads use short-lived credentials, not distributed static keys
- Every remaining static key has an owner, a rotation path, and a tested revocation
- Authorization decisions are logged with enough context to investigate later
Related reading in this section: zero trust architecture builds per-request authorization on top of this layer, application security and DevSecOps covers where authorization bugs are found, threat modeling covers elevation-of-privilege analysis, and compliance engineering covers the access-review evidence auditors sample. The Security & Compliance index lists the rest of the section.
