Policy-Based Access Control (PBAC): A Comprehensive Overview

Broken access control, privilege creep and role explosion put all organizations at risk. Long gone are the days when we just had couple roles within an organization, today we’re looking at dozens or even hundreds of different roles. This not only makes the task of managing roles harder but it also puts those organizations at risk.

Table Of Contents

• What Is Policy Based Access Control (PBAC)?
• Differences Between ABAC, RBAC, ReBAC and PBAC
• Major Strengths of PBAC
• PBAC Use Cases And Examples
• Conclusion

Modeling and managing user access within systems is more crucial than ever for data security, integrity and compliance.

There are plenty of access control models available on the market today.

Well-known examples include:

• Role-Based Access Control (RBAC),
• Relationship-Based Access Control (ReBAC),
• Attribute-Based Access Control (ABAC).

However, in this piece we're focusing on the PBAC model also known as Policy-Based Access Control and how it differentiates itself these from traditional access control models in terms of scalability, flexibility and security.

What Is Policy Based Access Control (PBAC)?

To put it simply, it is an authorization method which governs access to resources based on policies that reflect an organization's business objectives.

The PBAC model uses both attributes and roles to derive policies, unlike traditional access control frameworks where only roles or attributes are used to derive access rights. This feature makes PBAC a truly powerful and dynamic approach to control parameters.

Powered by Policy As Code (PaC)

Unlike traditionally where policies are manually enforced, not scalable and lack framework for implementation. The PBAC model applies policies in a completely different way.

The PBAC model uses a methodology called policy as code (PaC), meaning that policy can be written directly into code.

It gets rid of the manual work of compliance teams and merges into the code automating its processes along the way. From version control, review and validation, everything is automated from A to Z.

And you’ve guessed it, there are multiple benefits to automating policy management with PaC, here are some of them:

• More secure
• Helps avoiding human error
• Easier to audit
• Running test cases is a lot easier
• Check and enforcement of policy is automated
• Automation = Scalable
• Saves times and money
• Integrates policy within development
• Gives a framework to how policies are to be implemented

Note: A policy can be anything that governs operations and processes within an application or organization using PBAC, this can be a rule, condition or an instruction.

Differences Between ABAC, RBAC, ReBAC and PBAC

To better explain the differences between PBAC and these common access control models, first, we'll give a brief summary of them, then move on to PBAC and the differentiation.

Let's start with Attribute Based Access Control (ABAC).

Attribute-based Access Control (ABAC)

An ABAC model will use attributes derived from a subject, resource or environment to decide if access is granted or not to a resource within a system.

These attributes can be any value which makes this model able to handle complex scenarios.

In this model, authorization is more fine-grained because these attributes can have a dynamic value which can change.

Enabling us to define dynamic authorization rules and behaviors, one example is controlling which action can be performed within a system based on a user’s time, location and IP address.

ABAC models can get quite complex and come with the risk of unwanted behaviors if the values of these attributes aren’t looked after and audited. It is also complex to administrate, it takes longer to learn and become an expert at.

Role-based Access Control (RBAC)

In a RBAC model permissions are defined as actions a user can take on a resource.

These permissions are then grouped into roles and those roles are then assigned to subjects in a system. These subjects can be Users, Groups or Systems.

Roles in this type of model are static making it a lot easier to map and see how they relate to each other.

The RBAC model comes with a downside which is role explosion.

This happens when there are so many authorization scenarios that a large number of roles are required to cover all of them. Which makes the task of managing roles a lot more difficult and in some cases can be a security concern.

One of the downsides of this model is that it takes considerable time to implement because administrators need time to figure out each role and their permissions.

Relationship-based Access Control (ReBAC)

As the name says, this model relies on relationships to derive authorization.

This is done by ascribing relationships between subjects and resources in a system. These relationships can get quite complex when grouping resources. ReBAC is a “policy-as-data” type of model, unlike other models which are “policy-as-code” type.

This type of authorization modeling can be done with other models, but is a lot easier and concise when done with ReBAC because a graph is often used to build this type of model.

It is also a flexible model allowing us to have authorization at a resource level and it also offers a parent-child relationship between subjects and resources.

Policy-based Access Control (PBAC)

PBAC has some key benefits over older frameworks, the key reason is that policies are used to derive authorization by combining both a subject’s tasks and policies using a policy-as-code methodology.

Another key feature which makes it a lot more attractive than other solutions is its simplicity in creating and testing policies. This is great for running audits and being compliant with strict privacy laws in certain jurisdictions.

While a role-based system grants access based on roles, a policy based system grants access based on policies, this offers us a lot of flexibility when managing access permissions. PBAC models are built to scale with an organization’s growth through automation, write once and it takes care of the rest.

Unlike ABAC where rules are written in eXtensible Access Control Markup Language (XACML) or using the Open Policy Agent (OPA) using the Rego language which is often hard to understand for someone without a background in IT.

On the other hand, PBAC providers allow policies to be coded in a plain language format and in some cases using a Graphical User Interface (GUI). Making implementing access control policies easier for management teams by not having to rely on the IT department to make changes every now and then.

Here’s a simple illustration of how a PBAC model would work in a work environment with employees:

Pieces of information and data are the building blocks of a PBAC model, it relies on them to make access decisions. By using existing data it offers a flexible solution to policy building. In terms of clarity PBAC is the winner, it gives administrators a clear view of who has access to what, when and how across all assets within an organization.

Let’s have a deeper look into what makes PBAC so unique.

Major Strengths of PBAC

Dynamic and Flexible

PBAC models are dynamic, meaning that they can take multiple parameters into consideration when granting access and permissions to a user, which enables us to be specific when creating rules.

• User attributes (Employee, CEO, CTO)
• Resource attributes (File, Database, Network segments)
• Action attributes (Login, Read, Write)
• Contextual or environmental attributes (Physical Location, Device, Time)

PBAC uses Boolean logic when assessing if access should be granted or not, it does so by processing these attributes in an “if, then” manner which is different from other models.

We can apply rules within a PBAC system in a fully-automated fashion, making it adaptable to changing conditions, such as not allowing an employee to gain access to a system during weekends from his home computer. This gives us more control and enables us to make access decisions in real-time with high-granularity by taking context into consideration.

Policy based systems are dynamic by nature, making them adaptable to an organization's needs, whether it’s a small startup or a full blown enterprise with dozens of departments.

They’re also blazingly fast, as an administrator you have full control over user permissions, you can add, remove or edit permissions to every single user within an organization at the click of your mouse.

Secure and Reliable

As humans we’re prone to errors and this is no exception when it comes to managing policies and access control. Policy management can be automated within a PBAC system removing the need of a human to manually review policies which is great for security.

Another benefit of using the PBAC model is the separation of privileges within an organization where each component is isolated to minimize the risk in the event of a security breach. Take for example a hacker who compromises one segment of a network, they won’t get full access to the rest of the network if privileges are strictly regulated across the network.

PBAC closes the security gaps left open by RBAC and this is done by being proactive with access control security.

Compliant and Consistent

Being compliant today is important when it comes to following regulatory laws in certain jurisdictions. PBAC systems make the task a lot easier for compliance teams to follow legal requirements from data privacy and security laws such as GDPR, HIPAA and CPRA.

PBAC enables us to easily align internal policies with access control by regulating access to sensitive data across an organization or application in a consistent and systematic way.

PBAC Use Cases And Examples

As said earlier, PBAC is extremely dynamic in nature and can adapt to different environments. It can scale with an organization’s growth, if a policy states that “HR can access employee data”, it does not matter if there are a hundred or a thousand employees. The policy still applies and is enforced.

Let’s have a look at real-world examples where PBAC is in action:

Let’s see a simple example of an attorney working in a legal firm, here’s how access control policies in a PBAC system would be applied to him.

• User Policy: Allow access to the firm’s main portal.

• Resource Policy: Allow access to client files assigned to him.

• Action Policy: Allow permission to read and edit files of clients.

• Environmental and Contextual Policy: Block access to the firm's portal on Sunday’s and Saturday’s.

Here’s how it would be implemented in Python using the Cedar policy language:

from cedar.client import CedarClient

# Initialize Cedar client
cedar_client = CedarClient(api_key='YOUR_CEDAR_API_KEY_HERE', base_url='CEDAR_API_BASE_URL_HERE')

# User Policy: Allow access to the firm's main portal.
user_policy = {
    'condition': {
        'user': {
            'role': 'employee'
        },
        'resource': {
            'portal': 'firm'
        }
    },
    'permission': 'allow'
}

# Resource Policy: Allow access to client files assigned to him.
resource_policy = {
    'condition': {
        'user': {
            'role': 'employee'
        },
        'resource': {
            'file_type': 'client'
        }
    },
    'permission': 'allow'
}

# Action Policy: Allow permission to read and edit files of clients.
action_policy = {
    'condition': {
        'user': {
            'role': 'employee'
        },
        'action': {
            'read': True,
            'edit': True
        }
    },
    'permission': 'allow'
}

# Environmental and Contextual Policy: Block access to the firm's portal on Sundays and Saturdays.
contextual_policy = {
    'condition': {
        'day': ['Sunday', 'Saturday'],
        'resource': {
            'portal': 'firm'
        }
    },
    'permission': 'deny'
}

# Add policies to Cedar
cedar_client.add_policy('user_policy', user_policy)
cedar_client.add_policy('resource_policy', resource_policy)
cedar_client.add_policy('action_policy', action_policy)
cedar_client.add_policy('contextual_policy', contextual_policy)

# Here’s how to check access for a user attempting to login into the firm's portal on a Sunday.
user_attributes = {'role': 'employee'}
resource_attributes = {'portal': 'firm'}
day = 'Sunday'

access_permission = cedar_client.check_access(user_attributes, resource_attributes, day)
print("Access permission:", access_permission)

Conclusion

There are multiple access control models out there, all with their pros and cons when it comes to authorization management.

As we’ve seen, some of them require a high level of expertise in access control management to implement, others not.

In this article, we’ve seen the nuts and bolts of each one of them and how they manage and derive access control rulings using either attributes, roles, relationships or policies.

The PBAC model using the policy-as-code approach to define, update and enforce policies helps bridge the gap between the RBAC and ABAC model, offering the best of both worlds.

It fills the gap left by older models, by making management easier and by being preventative and blocking potential doors leading to vulnerabilities.