Learning outcomes
- Build fixtures from subject, resource, action, context, policy, and expected result.
- Cover positive, negative, boundary, conflict, indeterminate, and failure cases.
- Compare policy versions and detect unexpected permission expansion.
- Verify decision, enforcement, evidence, and bypass resistance together.
Operating objective
Authorization tests prove that a stated subject, resource, action, context, and policy version produce the intended result and that the enforcement point applies it. Tests must show denials and safe failures, not only successful access.
Build a small fixture vocabulary from production concepts. Use stable synthetic subjects, groups, relationships, devices, resources, actions, times, and risk states. Keep fixtures free of live credentials and personal data.
Signals and evidence
For each fixture, record the expected decision, reason, policy revision, enforcement response, and audit event. Cover:
- representative allow and explicit deny;
- default deny for missing or unknown facts;
- each boundary just below, at, and above its limit;
- conflicting and not-applicable rules;
- invalid, stale, or unavailable policy inputs;
- another tenant, owner, role, and action;
- direct-origin and alternate-protocol bypass;
- changed object state between check and use;
- old and new policy versions during rollout.
Compare the complete decision set before and after each change. Review every new allow and removed deny.
Response and recovery
Stop a rollout when a required fixture changes unexpectedly, an evaluator cannot load policy, version convergence fails, or enforcement evidence is missing. Keep the last known safe policy available for rollback. After rollback, purge or expire decision caches and confirm that all enforcers report the expected version.
Turn real incidents and near misses into minimal regression fixtures. Remove sensitive event data while preserving the decision boundary.
Design tradeoffs and residual risk
Unit tests are fast but can miss integration, distribution, and bypass failures. End-to-end tests provide stronger evidence but can be slow and difficult to isolate. Generated combinations improve breadth but can hide poor expected outcomes. Production shadow evaluation finds real inputs but must not change enforcement and can expose sensitive context.
Use layered tests. Keep a small mandatory end-to-end set for the highest-impact permissions.
Pomerium boundary
Pomerium policy tests can validate expected route decisions for defined identities and context. They do not test an upstream application's object and action permissions. Add application tests and end-to-end requests that prove both layers enforce their own decisions.
Exercise
Write a decision table for a finance route with employee group, managed device, office time, two tenants, read, write, and approve actions. Add missing group, unknown device, stale device record, policy-input outage, wrong tenant, and direct-origin cases.
Change one rule. Compare every result and explain each changed allow or deny before deployment.
Evaluation checklist
- Does each fixture include subject, resource, action, context, and expected result?
- Are deny, boundary, conflict, indeterminate, stale, and failure cases present?
- Does the suite test the enforcement path and evidence, not only evaluator output?
- Does a policy diff expose every permission expansion and contraction?
- Can rollback restore one known safe version across all evaluators and caches?
Next learning unit
Authorization Decision Log
Record enough structured evidence to explain and test an access decision without storing credentials or excess personal data.
