Attribute-based access control (ABAC) grants or denies a request by comparing attributes of the user, resource, and environment against explicit rules. Instead of asking whether someone has a particular role, it asks whether the current facts satisfy the access condition. This supports precise, context-aware authorization and can enforce least privilege, but it depends on clear rules and reliable attribute data. section 17.1.2 section 17.4
ABAC can evaluate attributes such as:
- User attributes: department, clearance level, and region. section 17.1.2
- Resource attributes: owner, sensitivity, department, and creation date. section 17.1.2
- Environment attributes: request time, IP address, and device type. section 17.1.2
- Distributed-system claims: department, region, clearance level, project IDs, or teams, provided services agree on their meanings and sources. section 17.2.2 section 17.4
Matching a user to a document
A rule can allow access when user.department equals document.department and the user’s clearance is high enough. Similar policies can allow finance users to access EU invoices, permit highly cleared operators to download encrypted backups, or deny requests outside working hours. A rule may also grant access when clearance is top or region is US: Mary passes the clearance condition, John passes the region condition, and Bob passes neither. section 17.1.2
Figure 17.1 Comparing RBAC, ABAC, and ReBAC. RBAC grants access based on predefined roles such as user, manager, and administrator. ABAC adds flexibility by using user and resource attributes such as department, shift, and clearance level to make decisions. ReBAC focuses on relationships among entities, such as who owns a resource or who is responsible for whom, making it ideal for collaborative and delegated access scenarios.
Compare ABAC with role-based access control and relationship-based access control: ABAC uses user and resource attributes, RBAC uses predefined roles, and ReBAC uses relationships among entities. section 17.1
ABAC is useful when roles cannot express differences such as department, region, ownership, or request context. In monoliths, evaluating attributes is relatively straightforward because user and resource data are local. In service-oriented systems, every service must enforce its own decisions and must not trust an upstream denial or approval blindly. Inconsistent values such as EU, Europe, and FR can produce authorization failures or gaps, while complex rules can become difficult to maintain. section 17.2.1 section 17.2.2 section 17.3
