Attribute-Based Access Control (ABAC)

ABAC moves beyond static roles to evaluate real-time attributes. Access is determined by Boolean logic rules that combine multiple characteristics.

• User Attributes: Department, clearance level, job function.
• Resource Attributes: Data classification, creation date, owner.
• Action Attributes: Read, write, execute, delete.
• Environmental Context: Time of day, network location, device posture.

This allows a single policy to grant access to 'all documents tagged Project-X' to 'any user with Role=Engineer' only if 'Location=HQ' and 'Time < 18:00'.

Unlike static Access Control Lists (ACLs), ABAC relies on a Policy Decision Point (PDP) and Policy Enforcement Point (PEP) architecture.

• PEP: Intercepts access requests and forwards them to the PDP.
• PDP: Evaluates attributes against the applicable policies and returns a Permit or Deny decision.
• Policy Information Point (PIP): The attribute source that provides real-time values (e.g., an LDAP directory or a time server).

This decoupling ensures authorization logic is centralized and can change instantly without modifying application code.

XACML is the OASIS standard that defines the architecture and policy language for ABAC. It provides a structured XML-based vocabulary to express complex access rules.

• Rule: A target, condition, and effect (Permit/Deny).
• Policy: A collection of rules with a combining algorithm (e.g., deny-overrides).
• Policy Set: A collection of policies.

XACML enables interoperability between heterogeneous systems, allowing a single authorization service to govern access across APIs, databases, and synthetic data pipelines.

In a private synthetic data factory, ABAC is critical for governing who can trigger generation jobs and access the resulting artificial datasets.

• Conditional Triggering: A policy may state that a data scientist can only initiate a CTGAN synthesis job if the source data has a privacy_budget > 0.5.
• Output Protection: Generated synthetic tables inherit the metadata tags of the source, preventing a user with clearance=low from downloading a high-fidelity replica of classification=secret data.
• Environment Lock: Synthesis jobs can be restricted to run only inside a Trusted Execution Environment (TEE) enclave.

While Role-Based Access Control (RBAC) assigns permissions to roles, ABAC assigns permissions to combinations of attributes.

• RBAC Limitation: 'Role explosion' occurs when thousands of fine-grained roles are needed to cover every permutation (e.g., US_Manager_DeptA_Shift1).
• ABAC Solution: A single policy defines the rule: User.Country == Resource.Jurisdiction AND User.Clearance >= Resource.Sensitivity.
• Context Awareness: RBAC cannot natively evaluate environmental risk factors like 'untrusted network' or 'anomalous login time', which are standard inputs for ABAC.

The integrity of ABAC depends entirely on the authoritative attribute sources. Attributes must be verifiable and tamper-proof.

• Subject Attributes: Issued by a trusted identity provider (IdP) via SAML or OIDC tokens.
• Resource Attributes: Stored in a secure metadata registry or a Tamper-Proof Model Registry.
• Environmental Attributes: Retrieved from secure sensors or endpoint detection and response (EDR) tools.

If an attacker can spoof a device_posture=compliant attribute, the entire policy evaluation is compromised, making mutual TLS and signed assertions essential.