Attribute-Based Access Control (ABAC).

Attribute-Based Access Control replaces static role assignments with dynamic policies. A decision engine evaluates rules over attributes of four kinds: the subject (department, clearance, role), the resource (classification, owner, tag), the action (read, delete, export), and the environment (time of day, source IP, device posture, threat level). This enables very fine-grained, context-aware decisions — for example, allowing a doctor to read a chart only during their on-call shift and from a managed device. ABAC is formally defined in NIST SP 800-162 (updated 2019), which frames it as a way to control information sharing without provisioning accounts per resource in advance.

Most real deployments follow the XACML reference architecture, which splits enforcement into four cooperating functions: the Policy Enforcement Point (PEP) intercepts the request, the Policy Decision Point (PDP) evaluates it, the Policy Information Point (PIP) fetches missing attributes, and the Policy Administration Point (PAP) manages the rules. Modern stacks often replace XACML's verbose XML with Open Policy Agent's Rego or AWS/Azure attribute conditions. ABAC's strengths are flexibility and scale — a handful of policies can express what would take thousands of RBAC roles — but its weaknesses are policy complexity, harder auditing ("who can access X?" becomes a solver problem), and total dependence on trustworthy, fresh attribute sources.

flowchart LR
  U[Subject requests action] --> PEP[Policy Enforcement Point]
  PEP --> PDP[Policy Decision Point]
  PDP -->|needs attributes| PIP[Policy Information Point]
  PIP -->|subject / resource / env| PDP
  PAP[Policy Administration Point] -->|rules| PDP
  PDP -->|Permit or Deny| PEP
  PEP -->|allow| R[Resource]
  PEP -->|deny| X[Blocked]