Attribute-based access control (ABAC) authorizes a request by evaluating current facts about the principal, resource, action, and environment against policy rules. It fits decisions that cannot be captured by a job title alone: clearance, department, region, device posture, time, request purpose, network risk, and regulatory flags can all affect access. section 6.2 section 5.3
Policies stay stable while their inputs change per request. A policy engine gathers relevant attributes, selects and evaluates applicable policies, then returns an allow or deny decision. Layered policies can impose organization-wide requirements alongside rules for particular actions, departments, or sensitive resources. section 6.2.1 section 6.2.2
Deployment outside business hours
A deployment policy can require high clearance and a company-managed device. During business hours, those conditions permit deployment; at 10 p.m., the engineer must also be on call. The same policy therefore changes its decision as the request’s hour and on-call status change. section 6.2 section 6.2.1
Figure 6.4 Attribute-based authorization with principal, resource, and environment attributes. Access decisions are based on evaluating policies in the context of attributes from multiple sources. Alice’s attributes meet the policy conditions, so access is granted. Bob’s do not, so access is denied.
Compare two finance users facing the same document policy: matching department and location are insufficient when one requester lacks the required clearance. section 6.2
ABAC is strongest when policies need contextual precision, but it depends on operational discipline:
- Use reusable, centralized policies to avoid encoding access logic separately in every application. section 6.2.3
- Govern attribute definitions, freshness, consistency, and provenance; inaccurate inputs can produce incorrect decisions. section 6.2.2
- Control policy growth with naming conventions, taxonomy, and tooling so overlapping rules remain understandable and auditable. section 6.2.5
- Choose relationship-based access control when ownership, invitations, delegation, or graph-like connections drive access. section 6.2.5
ABAC complements rather than necessarily replaces role-based access control (RBAC) and relationship-based access control (ReBAC). Roles can retain broad job responsibilities, relationships can model collaboration, and attributes can enforce context-sensitive constraints. Policy-based access control (PBAC) supplies a common pattern for externalizing and evaluating these inputs at runtime. section 6.3.3 section 6.4
A typical deployment places a policy enforcement point (PEP) in an application, gateway, proxy, or backend service. It sends a request to a policy decision point (PDP), which obtains attributes through policy information points (PIPs); policy administration points (PAPs) manage the policy set. Performance and explainability become important as policies and attribute sources multiply. section 6.2.2 section 6.2.3
