Control objective
Attribute-based access control evaluates policy over attributes of the subject, resource, requested action, and environment. It can express decisions that depend on ownership, classification, device state, time, network, transaction value, or other current facts.
Attribute contract
For each attribute, define the source, identifier, type, allowed values, meaning, update authority, collection time, maximum age, and failure behavior. The decision point must distinguish missing, invalid, stale, and false values.
Policy behavior
Write conditions against a scoped authorization request. Define combining and conflict behavior. Test boundary values and absent attributes. Keep resource attributes close to the system that owns their meaning. Avoid copying fast-changing application state into a distant policy system without a freshness model.
Failure and residual risk
More attributes increase expressiveness and dependency risk. Source compromise can create valid-looking false context. Cached values can preserve access after change. Inconsistent schemas can produce silent mismatch. Collection can create privacy exposure without decision value.
Pomerium boundary
Pomerium policy can evaluate user, request, device, time, and external context for route access. Applications own record and action attributes that exist only in application state. Operators must define provenance and freshness for every Pomerium policy input.
Evaluation checklist
- Does each attribute have a source, meaning, type, and owner?
- Is maximum age suitable for the protected action?
- Are missing, invalid, stale, and conflicting values tested?
- Does policy collect only attributes that affect the decision?
- Which application attributes must remain in application authorization?
