Overview
Policy-Based Access Control (PBAC) is an access control paradigm that makes authorization decisions based on policies rather than static assignments. Instead of directly assigning permissions to users, PBAC evaluates policies that consider attributes of the user, the resource, the action, and the environment to determine whether access should be granted.
PBAC is an umbrella term encompassing several models: Attribute-Based Access Control (ABAC) uses user and resource attributes; Role-Based Access Control (RBAC) uses role assignments; Relationship-Based Access Control (ReBAC) uses relationships between entities. In practice, most real-world implementations are hybrids—using roles for coarse-grained access and attributes for fine-grained, context-aware decisions.
The appeal of PBAC is flexibility and expressiveness: you can write policies like "users in the Finance department can view invoices for their own region during business hours" rather than creating thousands of static role assignments. The challenge is complexity—policies must be carefully designed, tested, and maintained, and the policy evaluation engine must perform at scale.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| What is the primary policy model? | RBAC, ABAC, ReBAC, hybrid | Hybrid: RBAC for coarse-grained, ABAC for fine-grained context | Pure ABAC is hard to manage; pure RBAC lacks context awareness. |
| What is the policy language? | Vendor-specific, OPA/Rego, Cedar, XACML, custom | OPA/Rego or Cedar for modern deployments; vendor-native if IGA-integrated | XACML is powerful but complex; custom is hard to maintain. |
| Where is policy evaluated? | Centralized PDP, distributed PDPs, embedded in apps | Centralized PDP with local caching for consistency; distributed for latency-sensitive | Centralized is easier to manage; distributed needs sync and consistency strategy. |
| How do you handle policy versioning? | No versioning, manual, GitOps | GitOps: policies in version control, CI/CD for testing and deployment | Policy changes without version control lead to audit and rollback problems. |
| How do you test policies? | Manual, automated unit tests, simulation | Automated unit tests + simulation against production-like data | Untested policies cause outages and security gaps. |
| How do you handle policy conflicts? | First match, deny overrides, allow overrides, explicit priority | Deny overrides (explicit deny wins) with clear priority rules | Ambiguous conflict resolution leads to unpredictable behavior. |
Architecture & Reference Patterns
Pattern 1: Centralized policy decision point (PDP)
Applications delegate authorization decisions to a central PDP:
- Policy Enforcement Point (PEP): Application intercepts access request.
- Policy Information Point (PIP): Gathers attributes (user, resource, context).
- Policy Decision Point (PDP): Evaluates policy and returns permit/deny.
- Policy Administration Point (PAP): Where policies are authored and managed.
Standards like AuthZEN provide a common API between PEP and PDP for interoperability.
Pattern 2: Hybrid RBAC + ABAC
Use roles for stable, coarse-grained access:
- "Finance Analyst" role grants access to financial reporting application.
Use attributes for dynamic, fine-grained constraints:
- Within the application, user can only see data for their assigned region.
- Access is only permitted during business hours from corporate network.
Pattern 3: Relationship-Based Access Control (ReBAC)
Model access based on relationships between entities:
- "User can view document if they are a member of the document's project."
- "User can approve expense if they are the submitter's manager."
ReBAC is powerful for collaboration and hierarchical scenarios but requires a relationship graph.
Pattern 4: Policy as Code with GitOps
Treat policies as code artifacts:
- Store policies in Git with version control.
- Require code review for policy changes.
- Run automated tests (unit tests, simulation) in CI pipeline.
- Deploy policies through CD pipeline with rollback capability.
- Audit trail via Git history.
See Policy as Code for implementation details.
Pattern 5: Context-aware authorization for AI agents
For workload and machine identities including AI agents:
- Evaluate runtime context (what action is the agent attempting, what data is involved).
- Apply constraints based on the human user the agent is acting on behalf of.
- Support dynamic trust levels based on agent behavior and attestation.
Implementation / Rollout
Phase 0: Discovery
Inputs: Current authorization mechanisms, access control pain points, compliance requirements, application inventory, attribute availability.
Outputs: Use case prioritization, policy model selection, attribute inventory, policy engine requirements.
Phase 1: Design
Outputs:
- Policy architecture (PDP, PEP, PIP, PAP locations).
- Policy language and engine selection.
- Attribute schema and sources.
- Policy authoring and review process.
- Testing strategy (unit tests, simulation, canary).
- Conflict resolution rules.
Phase 2: Build & Integrate
Outputs:
- Policy engine deployment.
- PEP integration with pilot applications.
- PIP integration with attribute sources (IdP, HR, application metadata).
- Policy authoring environment and version control.
- Automated testing pipeline.
- Monitoring and logging.
Phase 3: Rollout
Recommended sequence: Start with a single application with clear authorization needs; validate policy accuracy; expand to additional applications; move sensitive applications last.
Guardrails: Canary deployments, simulation mode (log decisions without enforcement), rollback procedures, audit logging.
Phase 4: Operate
- Monitor policy evaluation latency and error rates.
- Review policy decision logs for anomalies.
- Periodic policy review and cleanup.
- Attribute data quality monitoring.
- Policy versioning and audit trail maintenance.
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| Policy complexity explosion | H | H | Hard to understand policies, conflicts, maintenance burden | Policy governance, simplicity principles, regular review |
| Performance degradation (slow policy evaluation) | M | H | Latency spikes, timeout errors | Caching, policy optimization, distributed PDPs |
| Attribute data quality issues | M | H | Wrong decisions, user complaints, audit findings | Attribute validation, data quality monitoring, authoritative sources |
| Policy conflicts or gaps | M | H | Unexpected denials or permits, inconsistent behavior | Conflict detection tools, comprehensive testing, deny-by-default |
| Audit and explainability gaps | M | M | Compliance findings, inability to explain decisions | Decision logging, policy documentation, explainability features |
Workshop Questions
Security / IAM
- What authorization decisions need context beyond role membership?
- What attributes are available for policy decisions (user, resource, environment)?
- What is the acceptable latency for authorization decisions?
Application Owners
- What fine-grained authorization requirements does your application have?
- Can your application integrate with an external PDP (via API call)?
- What is the current authorization mechanism, and what are its limitations?
Compliance / Audit
- What audit evidence is required for authorization decisions?
- How must decisions be explainable (why was access granted or denied)?
- What policy change controls are required?
Architecture / Platform
- Where should PDPs be deployed (centralized, distributed, per-application)?
- What policy engine is preferred or already in use?
- How will policies be versioned, tested, and deployed?
Requirements Gathering Checklist
- [Security / IAM] What authorization decisions require context beyond roles (attributes, relationships, environment)?
- [Security / IAM] What policy model is appropriate (RBAC, ABAC, ReBAC, hybrid)?
- [Security / IAM] What attributes are available and where do they come from?
- [Architecture] Where will the PDP be deployed, and what is the latency requirement?
- [Architecture] What policy language/engine will be used (OPA, Cedar, XACML)?
- [Architecture] How will policies be versioned, tested, and deployed (GitOps)?
- [App Owners] What applications need PBAC integration, and can they call external PDPs?
- [App Owners] What fine-grained authorization requirements exist per application?
- [Compliance] What audit logging and decision explainability is required?
- [Compliance] What policy change controls and approval processes are needed?
References
- NIST SP 800-162 (Guide to Attribute Based Access Control Definition and Considerations)
- NIST SP 800-53 Rev. 5, AC-3 (Access Enforcement)
- XACML 3.0 (OASIS Standard for policy language)
- Open Policy Agent (OPA) and Rego language
- AWS Cedar policy language
- OpenID AuthZEN (Authorization API interoperability)
- Zanzibar: Google's Consistent, Global Authorization System (ReBAC reference)
- ISO/IEC 27001:2022 Annex A.5.15 (Access control)