Blog | G5 Cyber Security

ABAC/RBAC Authorization Guide

TL;DR

This guide explains how to implement authorization using Attribute-Based Access Control (ABAC) and Role-Based Access Control (RBAC), often managed with XACML policies. We’ll cover defining attributes, roles, policy creation, and enforcement.

1. Understanding the Concepts

Before we start, let’s clarify some terms:

ABAC is more flexible than RBAC, but also more complex to set up.

2. Defining Attributes

  1. Identify Key Attributes: Determine the attributes needed for your authorization decisions. Examples include:
    • User Attributes: Department, job title, security clearance level
    • Resource Attributes: Data sensitivity, owner, creation date
    • Environment Attributes: Time of day, location, network connection
  2. Attribute Storage: Choose a storage mechanism for attributes. Options include:
    • LDAP/Active Directory: For user attributes.
    • Databases: For resource and environment attributes.
    • Dedicated Attribute Stores: Specialized systems designed for ABAC.

3. Defining Roles (for RBAC)

  1. Identify Roles: Determine the roles within your organization. Examples include:
    • Administrator
    • Manager
    • User
    • Read-Only User
  2. Role Assignment: Assign users to appropriate roles. This is typically managed through an identity management system.

4. Creating XACML Policies

XACML policies define the rules for authorization. They consist of:

Here’s a simple example of an XACML policy allowing users in the ‘Finance’ department to read sensitive data:

<Policy 
        PolicyId="urn:example:finance-read-sensitive-data"
        Version="1.0">
  <Target>
    <Any Subject />
    <Any Resource />
    <Any Action />
  </Target>
  <Rule PolicyId="urn:example:finance-read-sensitive-data-rule" Effect="Permit">
    <Description>
      Allow users in the Finance department to read sensitive data.
    </Description>
    <Condition Function="urn:oasis:names:tc:xacml:1.0:function:string-equal">
      <AttributeValue AttributeId="http://example.com/user/department">Finance</AttributeValue>
      <AttributeValue AttributeId="http://example.com/resource/sensitivity">Sensitive</AttributeValue>
    </Condition>
  </Rule>
</Policy>

5. Policy Enforcement

  1. Policy Decision Point (PDP): The component that evaluates XACML policies and makes authorization decisions.
  2. Policy Enforcement Point (PEP): Intercepts access requests and sends them to the PDP for evaluation.
  3. Attribute Authority (AA): Provides attribute values to the PDP.

The typical flow is:

  1. User attempts to access a resource.
  2. PEP intercepts the request and gathers relevant attributes (user, resource, environment).
  3. PEP sends the attributes to the PDP.
  4. PDP retrieves necessary attribute values from AAs if needed.
  5. PDP evaluates XACML policies based on the attributes.
  6. PDP returns an authorization decision (Permit or Deny) to the PEP.
  7. PEP allows or denies access based on the PDP’s decision.

6. Tools and Technologies

7. Best Practices

Exit mobile version