Identity & Access Management

Every mechanism in Identity and Access Management is a stage in one fixed-order chain. Identification is the subject asserting who it claims to be (a username, a badge number); authentication is proving that claim with one or more factors; authorization is the decision of what the now-proven subject may do to a given object; and accountability is the after-the-fact logged record that ties the action back to the subject. The order is load-bearing: you cannot authorize an identity you have not authenticated, and you cannot hold a subject accountable for an action you cannot attribute, so when a scenario goes wrong, locate the failing stage first. The six subtopics map onto this chain: access-control frames the whole subject → access-control system → object model, identification-authentication owns the identify-and-prove steps, authorization-mechanisms owns the may-do decision, provisioning-lifecycle keeps that decision correct over time, and federated-identity plus authentication-systems carry the proof across boundaries and over the wire.

A subject is the active entity requesting an operation; an object is the passive entity to be protected: a file, record, device, process, facility, or service. Between them sits the access-control system: the policy, the decision point that evaluates the request against that policy, and the enforcement point that lets it through or blocks it. The always-invoked, tamperproof, verifiable mediator that does this enforcement is the reference monitor. The model (DAC, MAC, RBAC, ABAC) defines the rules and the reference monitor enforces them. This same model spans logical access (information, systems, applications, services) and physical access (facilities, equipment): a request to read a file and a request to badge into a data center are both evaluated by an access-control system before the resource is reached, which is why one control vocabulary governs both worlds.

The NIST SP 800-63 framework grades three stages of trust on independent scales, and the security leader's job is to set each from the risk of the transaction rather than assuming one implies another. Identity Assurance Level (IAL) grades how rigorously the identity was proofed before any credential was issued (IAL1 self-asserted, IAL2 validated evidence, IAL3 in-person or supervised-remote). Authenticator Assurance Level (AAL) grades how strongly the login proves possession (AAL1 single-factor, AAL2 two distinct factors, AAL3 a hardware authenticator plus verifier-impersonation resistance). Federation Assurance Level (FAL) grades how strongly a federated assertion is protected when the proof crosses an organizational boundary. A self-asserted (IAL1) account can still demand AAL2 login, and strong authentication on a weakly-proofed account is worthless because you are confidently authenticating the wrong person.

A sound posture starts closed: absent an explicit grant the request is denied (default-deny / fail-closed), so a gap in policy is safe rather than permissive. Least privilege then restricts each subject to the minimum access its task needs, and need-to-know is least privilege applied to information: a clearance sets the ceiling of what a subject may ever see while need-to-know decides which specific data within that ceiling the subject requires now. But access granted once and forgotten decays into privilege creep, so the identity provisioning lifecycle (joiner-mover-leaver, governed by NIST SP 800-53 AC-2) re-baselines access on every move, deprovisions promptly on every leave, and periodic access reviews recertify that each privilege is still needed. Just-in-time access and zero-standing-privilege designs push this further by granting elevated rights only for the moment of need and revoking them automatically: least privilege enforced not just at grant time but across the whole account lifecycle.

Within a single security domain, single sign-on (SSO) lets a user authenticate once and reach many applications; federation is SSO extended ACROSS an organizational boundary, where one organization agrees in advance to trust the authentication another organization's identity provider (IdP) asserts. The protocols in authentication-systems are the canonical pattern in action: a trusted authority issues a verifiable artifact (a Kerberos ticket, a SAML assertion, an OIDC ID token) that a resource accepts in place of re-checking the credential itself. The recurring trade is concentration of blast radius: an SSO session, a federated IdP, or a Kerberos KDC is one place to enforce strong authentication and disable a departing user everywhere, and equally one single point of failure whose compromise impersonates everyone, everywhere. The leader contains that by hardening the authority, protecting its signing keys, scoping trust to only the attributes each consumer needs, and monitoring assertion issuance rather than trusting a contract.