Skip to content

Attribute-Based Access Policy

Access-control policy — instantiates Role-Scoped Disclosure Minimization

Computes at request time what a consumer may receive by evaluating attributes of the actor, resource, purpose, and context against per-field necessity rules — so the disclosed view narrows or widens with the situation instead of being a fixed grant.

Attribute-Based Access Policy decides disclosure as a computation over attributes rather than a stored grant. When a consumer asks for a record, a policy decision point evaluates a vector of signals — who the actor is and what role they hold, the purpose they've declared, the sensitivity of the resource, and context such as time, location, device, or a live risk score — against rules that bind each attribute combination to exactly the fields it justifies. The one idea that makes it this mechanism: access is never a fixed fact about a person, it is re-derived on every request, so the same actor gets a wide view under one set of conditions and a narrow one under another. That is what lets least-privilege scale past a handful of static roles to situations no fixed role table could enumerate in advance.

Example

An SRE asks for read access to the production billing database. A static role would have to choose once and for all: either "SRE" always carries prod read, or it never does. Attribute-Based Access Policy evaluates the request instead. Role is sre; declared purpose is incident #4821; the incident is open; the SRE is currently on-call; the connection is from a managed device on the corporate network; the resource is tagged pii-bearing. The governing rule reads roughly: an SRE may read PII-bearing prod tables only while on-call and attached to an active incident and from a managed device — otherwise deny.

All conditions hold, so the policy returns a scoped, four-hour read grant — with an obligation to mask the stored card numbers. When the incident closes or the on-call rotation flips, the same request now evaluates to deny, and the access simply evaporates. Nobody revoked anything; the grant was only ever true while its attributes were.

How it works

The distinctive machinery is evaluation, not storage. A policy decision point takes the request's attribute vector and runs it through a set of rules, combined by an explicit algorithm (deny-overrides, permit-overrides, or first-applicable) with a default of deny. The decision — permit, deny, or permit-with-obligations — is handed to an enforcement point that carries it out. What separates this from static role-to-view mapping is that environment, purpose, and risk are first-class inputs: the policy can say "only during the incident," "only from a compliant device," "only if the risk score is low," none of which a fixed role can express. The policy is the decision layer; it does not itself hold or shape the data.

Tuning parameters

  • Attribute breadth — how many signals feed the decision. More attributes buy finer control but multiply what has to be governed, kept fresh, and reasoned about when something is wrongly allowed.
  • Combining algorithm — deny-overrides vs. permit-overrides vs. first-applicable. This fixes which way an ambiguous or conflicting rule set resolves; deny-overrides fails safe.
  • Default stance — deny-by-default vs. allow-by-default. Deny-by-default means a request no rule covers is refused rather than waved through.
  • Attribute freshness — how current the context signals must be. A stale on-call flag or a cached ticket state grants access the present situation no longer warrants.
  • Policy granularity — coarse resource-level rules vs. per-field rules. Finer granularity minimizes more precisely but makes the policy set heavier to author and audit.

When it helps, and when it misleads

Its strength is least privilege at a scale no static role table reaches: one policy language expresses context-sensitive, purpose-bound, field-level access across many resources, and each grant is conditional rather than standing. It is the natural generalization of a Role-Based View once "the role" stops being enough to decide.

Its failure modes come from the same expressiveness. Large attribute-driven policy sets drift toward the unauditable — nobody can answer "why was this allowed?" — and a single permissive catch-all rule can silently restore the broad access the whole scheme was meant to prevent. Attributes that are stale or spoofable grant the wrong view convincingly. The classic misuse is running it backwards: reverse-engineering an attribute or a declared purpose so the policy blesses access someone already decided to take. The discipline that guards against this is to deny by default, keep the rule set small and reviewable, and log the decision together with the attributes it turned on — so every grant stays explainable and least privilege[1] is a property you can check, not just assert.

How it implements the components

  • consumer_role_and_purpose_profile — the actor's role, declared purpose, and surrounding context are the attribute vector the decision is computed from; the policy consumes this profile on every request.
  • field_level_necessity_rule — the policy rules bind each attribute combination to the exact fields it justifies, deny by default; this is where "necessary for this role-and-purpose" is written down and enforced.

It decides but does not shape the payload — enforcing the decision and emitting only the permitted fields is API Response Projection; classifying which data is sensitive in the first place is Data Loss Prevention Policy; and the consumer's purpose is authored upstream as a Purpose-Based Access Request, which this policy only evaluates.

Notes

The policy only decides; something else must enforce. A permit-with-obligation ("mask the card column") is worthless unless the enforcement point actually applies it, so this mechanism is only as strong as the API Response Projection or redaction step that carries out its verdict. Keeping decision and enforcement separate is deliberate — it lets the policy be reviewed as policy — but it also means an unenforced obligation is a silent leak.

References

[1] The principle that every actor should operate with the minimum access its task requires, articulated by Saltzer and Schroeder in their 1975 survey of protection principles. Attribute-based policy is one way to approximate it dynamically rather than through coarse standing roles. ↩