Skip to content

Attribute Based Access Control (ABAC) Overview

Attribute-Based Access Control (ABAC) in Privacera allows you to define dynamic policies based on attributes of users, groups, roles, and tags. Instead of maintaining static lists of users or resources, ABAC enables context-aware enforcement, ensuring that access decisions adapt based on identity metadata and business logic such as department, location, clearance level, or sensitivity labels attached to users, roles, and data resources.

Privacera also supports policies based on resources, which is covered in the Tag Based Access Control (TBAC).

Key benefits of ABAC in Apache Ranger include:

  • Dynamic Authorization: Access decisions automatically adjust based on changing attributes without frequent policy updates.
  • Fine-Grained Access: Enables precise control by using multiple attributes to define complex access rules.
  • Policy Simplification: Reduces administrative overhead by managing fewer, attribute-driven policies rather than numerous static rules.
  • Enhanced Security: Minimizes risks by ensuring access is continuously evaluated and enforced according to real-time attribute values.

Implementation Design

Most data engines do not support ABAC natively, so depending on the integration, it is handled differently:

  1. Apache Ranger Plugin: ABAC is handled by the plugin during query execution.
  2. PolicySync: ABAC is translated into the target system's native constructs and applied to the data engine using custom User Defined Functions (UDFs) or explicit user or group based permissions.

Examples of ABAC Policies

Here are some examples of how ABAC can be implemented in Privacera using Apache Ranger policies. These examples illustrate how to leverage user attributes and group attributes to create dynamic access control policies.

1. Resource Access Based on User Attributes

In this example, table access is dynamically controlled based on the user's department attribute (${{USER.dept}}).

User Department (${{USER.dept}}) Resource Access
Alice finance finance.transactions ✅ Allowed
Bob marketing finance.transactions ❌ Denied

Policy Expression:

Allow Access: ${{USER.dept}} == 'finance'

2. Resource Access Based on Role Attributes

In this example, table access is controlled based on the role's department attribute using GET_UR_ATTR('dept').

User Assigned Role Role Department Resource Access
Alice finance_analyst finance finance.transactions ✅ Allowed
Bob marketing_coordinator marketing finance.transactions ❌ Denied
Carol finance_manager finance finance.transactions ✅ Allowed

Policy Expression:

Allow Access: GET_UR_ATTR('dept') == 'finance'

Benefits of Role Attributes:

  • Simplified Management: Assign attributes to roles instead of individual users, reducing administrative overhead.
  • Consistent Access Control: Users automatically inherit access rights from their role attributes, ensuring consistent policy enforcement.
  • Dynamic Authorization: As role attributes change, access is automatically updated without modifying individual user assignments.

3. Dynamic Row-Level Filtering Based on User's Group Membership

Here, users can view only the rows matching their assigned group membership, utilizing UG_NAMES_CSV().

Dataset (sales.records):

Region Product Sales Amount
US A $10,000
Europe B €8,500
APAC C ¥950,000
User Groups Rows Visible
Dave US Rows with Region='US'
Eva Europe Rows with Region='Europe'
Frank APAC Rows with Region='APAC'

Policy Expression (Row-Level Filter):

region in ('${{UG_NAMES_CSV.replace(",", "','")}}')

4. Dynamic Column Masking Based on User's Group Membership

Sensitive columns are masked dynamically, depending on whether the user belongs to a specific group.

Dataset (employee.payroll):

Employee ID Name Salary SSN Role
101 Grace $120,000 123-45-6789 payroll_mgr
102 Heidi $95,000 987-65-4321 intern
User Groups Salary Column SSN Column
Grace payroll_mgr $120,000 123-45-6789
Ivan intern MASKED MASKED

Policy Expression (Column Masking Rule):

CASE WHEN Role in ('${{UG_NAMES_CSV.replace(",", "','")}}') THEN {col} ELSE 'MASKED' END

Here is the updated version of the Tag-Based Masking Policy example using User Attributes instead of group membership:

5. Tag-Based Masking Policy Using User Attributes

Columns tagged as PII are masked unless the user has an attribute data_clearance set to high.

Dataset with Tags:

Column Tag
customer.email PII
customer.address PII
customer.age None
User ${{USER.data_clearance}} customer.email customer.address customer.age
Judy high ✅ Visible ✅ Visible ✅ Visible
Ken low 🔒 Masked 🔒 Masked ✅ Visible

Masking Policy Expression:

Mask if: ${{USER.data_clearance}} != 'high'

Explanation:

  • All columns tagged as PII will be masked for users who do not have a data_clearance value of high.
  • Non-sensitive columns (no tag) remain fully visible to all users.

6. Tag-Based Masking Policy Using Role Attributes

Similar to user attributes, columns tagged as PII can be masked based on role attributes. In this example, access is determined by the role's data_clearance level rather than the individual user's attribute.

Dataset with Tags:

Column Tag
customer.email PII
customer.address PII
customer.age None
User Assigned Role Role Data Clearance customer.email customer.address customer.age
Judy senior_analyst high ✅ Visible ✅ Visible ✅ Visible
Ken junior_analyst low 🔒 Masked 🔒 Masked ✅ Visible
Linda data_steward high ✅ Visible ✅ Visible ✅ Visible

Masking Policy Expression:

Mask if: GET_UR_ATTR('data_clearance') != 'high'

Explanation:

  • All columns tagged as PII will be masked for users whose role does not have a data_clearance value of high.
  • This approach simplifies management as the clearance level is assigned to the role rather than to each individual user.
  • When a user's role changes, their access automatically adjusts based on the new role's attributes.