Attribute-Based Access Control (ABAC)

ABAC makes authorization decisions by evaluating attributes against a set of policies. Unlike Role-Based Access Control (RBAC), which grants access based solely on a user's role assignment, ABAC can combine multiple attributes from different entities.

• Subject Attributes: Characteristics of the user or service (e.g., department, security clearance, job function).
• Resource Attributes: Properties of the data or service being accessed (e.g., classification level, data type, owner).
• Action Attributes: The operation being attempted (e.g., read, write, delete, approve).
• Environmental Attributes: Contextual factors at the time of access (e.g., time of day, device posture, network location, geolocation).

A policy might state: 'Allow read access to financial records if the user's department is Finance, the resource classification is Confidential, and the device is a managed corporate asset.'

The core of ABAC is the Policy Decision Point (PDP), a logical component that evaluates access requests against a central repository of policies written in a formal language like eXtensible Access Control Markup Language (XACML) or Open Policy Agent (OPA) Rego.

• Policy Language: Policies are expressed as Boolean rules that combine attributes using logical operators (AND, OR, NOT).
• Separation of Concerns: Policy authoring is decoupled from application code. Security administrators can update access rules without modifying the underlying application logic.
• Externalized Authorization: The authorization logic is extracted from the application and managed as a standalone service, enabling consistent policy enforcement across a heterogeneous application landscape.

This architecture allows for complex, fine-grained rules like 'Doctors can read records of patients in their department during their shift from a hospital-managed workstation.'

ABAC is inherently context-aware, evaluating real-time environmental signals at the moment of access. This contrasts with static access control lists (ACLs) that grant persistent permissions.

• Real-Time Risk Assessment: Access can be denied if a user's device is non-compliant, their geolocation is anomalous, or the request occurs outside of business hours, even if their static attributes are valid.
• Continuous Evaluation: In a zero-trust architecture, ABAC policies are re-evaluated continuously throughout a session. A change in device posture or network location can trigger an immediate revocation of access.
• Adaptive Policies: Policies can be written to step up authentication requirements (e.g., require MFA) based on the sensitivity of the requested resource or a calculated risk score from a User and Entity Behavior Analytics (UEBA) system.

This dynamic nature makes ABAC the foundational authorization model for Zero-Trust Architecture (ZTA).

ABAC enables fine-grained permissions that go far beyond coarse role assignments. It can control access to specific fields within a document, rows in a database, or actions on an API endpoint.

• Data-Centric Security: Policies can filter data at the record level. For example, a salesperson might only see CRM records for their assigned territory, enforced by the authorization engine.
• API Micro-Segmentation: ABAC can govern east-west traffic between microservices by evaluating the SPIFFE workload identity of the calling service, the API endpoint being hit, and the sensitivity of the data payload.
• Masking and Redaction: The policy decision can return not just 'Permit' or 'Deny', but also obligations like 'Permit with Redaction', instructing the Policy Enforcement Point (PEP) to mask sensitive fields like Social Security numbers before returning the data.

This granularity is essential for meeting compliance mandates like GDPR and HIPAA.

ABAC is implemented through a standardized architecture that decouples enforcement from decision-making, as defined in NIST SP 800-162.

• Policy Enforcement Point (PEP): The interceptor that guards a resource. It constructs an authorization request based on the subject, resource, and environment and forwards it to the PDP. The PEP enforces the binary decision.
• Policy Decision Point (PDP): The brain of the system. It receives the request from the PEP, queries the Policy Information Point (PIP) for missing attribute values, evaluates the applicable policies, and returns a decision.
• Policy Information Point (PIP): The attribute source. It acts as a bridge to external identity providers, device management systems, and databases to fetch real-time attribute values.
• Policy Administration Point (PAP): The management interface used by administrators to author, test, and deploy policies to the PDP.

This clean separation allows organizations to swap out identity providers or policy engines without rewriting applications.

ABAC is a superset of Role-Based Access Control (RBAC). While RBAC is simpler to implement, it suffers from 'role explosion' in large enterprises, where thousands of unique roles must be created to capture every permission combination.

• RBAC as an Attribute: In an ABAC system, a user's role is simply one attribute among many. A policy can use role as a coarse filter and then refine the decision with more granular attributes.
• Reducing Complexity: ABAC eliminates the need for combinatorial role mining. A single policy can replace hundreds of static roles by dynamically evaluating attributes.
• Hybrid Models: Most enterprise deployments use a hybrid approach, starting with RBAC for broad access and layering ABAC policies for sensitive or dynamic resources.

This evolutionary path allows organizations to adopt ABAC incrementally without a disruptive 'rip and replace' of their existing identity infrastructure.