A collaboration service may need to let outside counsel view documents for one matter until an engagement expires, require approval before sensitive sharing, and restrict customer-data access to managed devices. Encoding such exceptions as roles, groups, or scattered checks makes changes risky and hard to audit. Policy-based access control (PBAC) makes these requirements explicit policies that are evaluated when access is requested. section 1.5.2 section 1.7
PBAC is an authorization model that externalizes decision logic from application code and static lists. A policy engine evaluates policies to allow or deny a particular request, using current information rather than only a fixed assignment. The application or another enforcement component still applies the resulting decision; PBAC separates the decision logic from the application behavior it protects. section 1.1 section 6.3
Figure 1.1 Embedding access logic throughout application code (left) creates tight coupling. Externalizing authorization into a separate component (right) makes access policies explicit, decouples decision-making from application behavior, and enables scalable, auditable access control.
Externalizing authorization replaces tightly coupled checks throughout application code with an explicit decision component, making policies easier to maintain and audit consistently. section 1.1
A policy can draw on several forms of access information at runtime:
- Roles and organizational structure, such as broad job responsibilities or administrative duties. section 6.3
- Attributes of the principal, resource, action, and environment, including clearance, time, device posture, region, or operational status. section 6.3.3
- Relationships such as ownership, management, invitation, sharing, team membership, or customer affiliation. section 6.3
- External obligations, including regulatory, contractual, or tenant-specific requirements. section 5.3
PBAC is a hybrid framework rather than a replacement for every other authorization model. Role-based access control (RBAC), attribute-based access control (ABAC), and relationship-based access control (ReBAC) become policy inputs instead of isolated choices. Roles can handle broad responsibilities, relationships can govern collaboration and delegation, and attributes can constrain sensitive actions by changing context. Policies may be structured data or executable code, but the shared principle is to avoid hardcoding individual access decisions. section 6.3 section 6.3.3
Table 6.6 How PBAC incorporates and extends RBAC, ABAC, and ReBAC by treating roles, attributes, and relationships as inputs to externalized policies evaluated at runtime
| Model |
Core concept |
How PBAC incorporates it |
|---|---|---|
| RBAC |
Roles grant permissions |
Roles are used as input to policy decisions. |
| ReBAC |
Relationships define access |
Policies reference relationships such as ownership or management. |
| ABAC |
Attributes drive decisions |
Policies are written using combinations of attributes. |
The comparison shows how PBAC incorporates RBAC, ABAC, and ReBAC: policies reference roles, combinations of attributes, and relationships while remaining externally evaluated. section 6.3
Tenant-specific document sharing
A multi-tenant service can express customer differences as policy and data rather than separate product forks. One tenant may use simple roles; another may require department administration, regional restrictions, identity-system integration, approval requirements, and partner access limited by time, purpose, and relationship. For a particular document request, the policy engine evaluates the relevant current facts and the service enforces the decision. section 1.5.3 section 1.3.1
PBAC also supports governance and security architecture. Policies can be reviewed, tested, and managed holistically, helping organizations verify that data is used only by appropriate people in appropriate situations. In zero-trust designs, each request can be evaluated with identity attributes, device posture, operational signals, and environmental context; foundational security, shared operational, and application policies may contribute to one decision. Reliable decisions therefore depend on accurate, current identity and contextual data, clear policy ownership, and coverage across applications and APIs. section 2.7.3 section 15.2 section 15.7
The result is fine-grained authorization that can adapt without repeatedly rewriting business logic. This can improve auditability, consistency, agility, security, and customer fit, but the greater expressiveness also requires careful governance to prevent policy complexity. PBAC is useful wherever static ACLs or role assignments cannot adequately express real-time, context-sensitive access requirements, including SaaS, Internet of Things deployments, zero-trust systems, and AI-agent tool access. section 1.7 section 6.4 section 18.3.4
