Attribute-Based Access Control (ABAC)

The central Policy Decision Point (PDP) evaluates subject, resource, action, and environmental attributes against a set of policies. Unlike RBAC, which checks a single role assignment, ABAC computes a Boolean decision based on the intersection of multiple attributes.

• Subject Attributes: Department, clearance level, job code.
• Resource Attributes: Classification tag, owner, creation date.
• Action Attributes: Read, write, delete.
• Environmental Attributes: Time of day, network location, threat level.

Access logic is externalized from application code and written in declarative, machine-readable languages like eXtensible Access Control Markup Language (XACML) or Open Policy Agent (OPA) Rego. This decoupling allows security teams to update authorization logic without modifying the application source code or redeploying services.

• XACML: A verbose, XML-based standard for fine-grained authorization.
• OPA/Rego: A lightweight, high-performance policy engine using a declarative query language.

ABAC policies adapt in real-time to situational context. A user who has 'Editor' access from a managed corporate device during business hours might be downgraded to 'Viewer' when connecting from a personal device or a high-risk geo-location.

• Risk-Adaptive Access: Integrates with threat intelligence feeds to deny access if the user's session risk score exceeds a threshold.
• Temporal Constraints: Enforces access windows based on time and date attributes.

ABAC enables field-level and record-level security without creating an explosion of static roles. A single policy can state: 'A physician may view the medical records of patients assigned to their care unit, but only the diagnosis and treatment fields, not the billing information.'

• Data Masking: Dynamically redacts sensitive fields based on user attributes.
• Relationship-Based Access: Uses attributes to define relationships (e.g., 'treating physician' vs. 'primary care provider').

A single Policy Administration Point (PAP) manages the lifecycle of access rules across heterogeneous systems. This eliminates the fragmentation of managing ACLs in databases, IAM roles in cloud consoles, and middleware rules separately.

• Obligation Services: Policies can trigger downstream actions (e.g., 'If access is granted to PII, generate an audit log and notify the DPO').
• Policy Versioning: Maintains a history of policy changes for rollback and compliance audits.

ABAC enforces dynamic SoD by evaluating conflicting attribute combinations rather than just conflicting roles. A policy can prevent a single user from both submitting and approving a purchase order if the resource value exceeds $10,000, regardless of their assigned roles.

• Conflict Resolution: Algorithms resolve contradictory policy outcomes (e.g., one policy grants access, another denies it) using combining algorithms like 'Deny-Overrides'.
• Transactional Verification: Ensures SoD is maintained across multi-step workflows.