AuthorizationABACpolicyattributespolicy enginecontext

ABAC and Policy-Based Authorization

Decide by evaluating a rule over the requester's attributes, the resource's attributes, the action and the environment — expressive where roles are not, and dangerous when the rules become unreadable.

▶ Run the labFollow the failure

Frame the problem

Security starts with a concrete asset, attacker capability and trust crossing.

Asset
Access decisions that depend on context: organisation, classification, region, time, device.
Attacker & capability
Someone who controls an attribute the policy trusts, or who finds a rule combination the author did not anticipate.
Trust boundary
Between the policy decision point and the code that enforces it.
Asset→Threat→Attack Surface→Trust Boundary→Vulnerability→Exploit Path→Impact→Mitigation→Defense in Depth→Residual Risk

Attributes in, allow/deny out

A policy takes subject attributes (department, clearance, tenant), resource attributes (owner, classification, tenant), the action, and environment (time, network, device posture) and returns a decision. "A user can access documents belonging to their organisation unless the document is marked restricted, in which case they must also hold the restricted-reader attribute" is one rule, and it would be dozens of roles.

The critical property is where attributes come from. Subject attributes must originate in an authoritative source — the directory, the database — never the request. A policy that reads department from a header is a policy the client writes.

1allow read on Document d for user u when
2    d.tenant == u.tenant                       # tenancy first
3    and (d.classification != "restricted"
4         or "restricted-reader" in u.attributes)
5    and env.time within u.workingHours          # environment
6# u.* comes from the directory; d.* from the record; nothing from the request body

Keeping policy auditable

Policy languages make it easy to write rules nobody can evaluate by reading. Keep rules deny-by-default with explicit allows, test them with a table of (subject, resource, action) → expected, and log the decision with the rule that fired. A policy engine that cannot explain a decision is a black box in the middle of your access control.

Latency matters too: policy evaluated remotely on every request is a dependency on the request path, with the fail-open/fail-closed decision from Fail Open vs Fail Closed attached.

Key points

  • Attributes must come from authoritative sources, never the request.
  • Deny by default; allow explicitly.
  • Test policies with decision tables and log which rule fired.
  • Policy is expressive, so keep it readable.

Boundary control exercise

This lesson uses the shared boundary-control exercise.

Boundary control check
Untrusted input / identity
→
Trust boundary
→
Privileged asset
Prevention may fail silently.

Follow the attack

Safe conceptual simulation: capability → missing control → crossed boundary → asset impact.

  1. 1
    Attacker → influence an attribute the policy trusts (a header, a self-editable profile field).
  2. 2
    Attribute → rule allows what it should not.
Blast radius
  • Silent over-grant across everything the rule governs.

Defend, detect, recover

One prevention is a single point of security failure. Layer it and make failure observable.

Prevent
  • • Source attributes server-side.
  • • Decision tables in CI.
  • • Explainable decisions.
Detect
  • • Log decisions with the firing rule; alert on allow rates that change after a policy deploy.
Respond & recover
  • • Roll back the policy; replay logged decisions to scope exposure.
Residual risk
  • • Rule interactions are hard to reason about at scale.
← Role-Based Access ControlBroken Access Control (IDOR / BOLA) →