Enterprise access control: ABAC vs RBAC in service-oriented architectures

It was a quiet night in the city, around midnight on a weekday. I was part of the change team, and one of the few people on the office floor. This was of an Australian bank's Identity and Access Management (IAM) Operations, within the Cyber Security department at the time. For the Operations team, it was a routine task: taking the Identity Management system offline to deploy and onboard new roles into the system. That night, we were onboarding about 50 roles. These roles were a key part of the bank's Role-Based Access Control (RBAC) system. With the bank modernizing its operations and regularly introducing new applications, this process had become a consistent part of our work, typically involving the addition of around 200 roles each month. At the bank, we used a lot of RBAC policies to grant and revoke access to the bank's workforce. It got me thinking about RBAC and its problem with "role explosion", and if Attribute-Based Access Control (ABAC) was a better alternative.

In this blog, we will explore different approaches to enforcing RBAC and ABAC in an enterprise context. We’ll examine what drives the business need to choose between RBAC and ABAC, the various architectural deployments of these access control methods, and the implications of their selection.

Defining authorizations (i.e. who should have access to what) is straightforward, though resource-intensive. With the expertise of your Business Analysts, you can map out user profiles and define the resources each should access, aligning them with organizational needs and industry standards. However, the real challenge lies in consistently enforcing these access control policies across all applications and services with confidence and reliability, while also ensuring they are properly maintained and auditable.

While there are multiple methodologies for implementing access control, the two most popular methods in the industry for enforcing access control are RBAC and ABAC. RBAC is a method of granting users access to resources based on predefined roles, such as auditor or admin, while ABAC provides access based on user attributes, such as location and department. Let us take a look at some of the sample policies that resemble whats actually used in practice at the bank:

RBAC

Role Name or Role Rule	Access
If role starts with "APIGW_"	Allow access to internal API Gateway at the authentication layer. Within the API gateway further enforce access if appropriate such as "APIGW_Admin" or "APIGW_Auditor"
If role starts with "CashAuthorized_"	Allow access to Cash Withdrawal app at the authentication layer. Within the app further enforce access on the amount able to withdraw, such as "CashAuthorized_1000" can only withdraw upto $1,000, "CashAuthorized_10000" can only withdraw upto $10,000 and so on

ABAC

Attribute Name	Attribute Value	Access
UserType	Contractor or Employee	Mailbox on the mail server '@bank.com', Employee Discount Portal, Expense Requester
UserType	Contractor	Mailbox on the mail server '@contractor.bank.com'
DepartmentName	VendorOrg	Access to Vendor Portal
DepartmentName	NOT VendorOrg	Access to Intranet Sites

So, what forms an access control (the "AC" portion of RBAC/ABAC) policy? The key components involved in making access control decisions are:

• Principal: This is defined by the user's roles, groups, or user attributes.

  "user": {
    "id": "12345",
    "username": "alan",
    "email": "alan@bank.com",
    "attributes": {
      "department": "Finance",
      "location": "Sydney",
      "employmentStatus": "Full-Time",
    },
    "roles": [
      {
        "name": "FinanceManager",
        "assignedDate": "2024-12-20"
      }
    ]
  }
}

• Action: This specifies the allowed operations on the resource.

read
write
delete

• Resource: This is the resource the user is trying to access such as files, API endpoints, etc.

read:reports
write:userAttributesAPI
delete:logEntries

• Context: Includes dynamic or contextual rules such as task at hand, discretionary, location, time, and device. The context variables could be part of the Principal object attributes.

   {
    "context": {
      "task": "approve_loan",
      "discretionary": "high",
      "location": {
        "country": "US",
        "region": "California",
        "city": "San Francisco"
      },
      "time": {
        "start": "2025-01-27T08:00:00Z",
        "end": "2025-01-27T18:00:00Z"
      },
      "device": {
        "type": "laptop",
        "os": "Windows 10",
        "ipAddress": "192.168.1.10"
      }
    }

All these components together gets evaluated against a policy that ultimately results in an "allow" or "deny" decision for a specific action. Let's look at how RBAC and ABAC fit into the access control policy.

Business Drivers

Here are some of the reasons that could drive the selection of RBAC or ABAC as a method of choice for deploying Enterprise Access Control.

RBAC

• Simplifies the assignment and revocation of access for users working on time-bound projects or performing temporary tasks when attributes of the user remains unchanged. For example, consider a contractor working for the bank on a 3-year engagement. During this time, the contractor may transition between multiple projects within the bank, each requiring different levels of access based on the project. However, the contractor's core attributes such as title, department, location remain unchanged. RBAC also makes it easy to grant access for someone stepping in for a specific task or project, with a clearly defined expiration date.
• Ensures consistent application of access rights by grouping related permissions across multiple applications and services. This standardization makes it easier to add or remove access reliably.
• Facilitates access reviews by requiring reviewers to individually evaluate and provide business justifications for role assignments. This ensures that access decisions are well-documented and audit-ready.
• Allows organizations to explicitly define roles that align with regulatory requirements, such as SOX or HIPAA. These roles can be easily mapped to compliance standards and are straightforward to audit.

ABAC

• Enables automatic access based on inherent attributes, also known as birthright access. For instance, all users with the "employee" attribute can have access to internal resources like the company’s partner discount listings.
• Provides access tied to specific user contexts such as department, organization, or location. For example, granting printer access on a specific floor if the user’s office address matches that floor level.
• Supports access that automatically adjusts based on dynamic changes in user attributes, such as title or location. For example, users with the "manager and above" title can be dynamically granted access to approve leave requests for their direct reports.
• Allows access that doesn’t require approvals or manual intervention before being granted. ABAC allows role assignments that are generally considered pre-approved for that user attribute. Such as access to the printer on level 2 would be automatic if your "address" attribute says you are based on level 2.

Architecture

In a Service-Oriented Architecture (SOA), enterprises strive to design components as independent services wherever possible. This approach includes offering authentication, authorization, and access control as standalone services. Applications can invoke these services as needed, promoting loose coupling and improved scalability.

With this in mind, let’s examine how an access control architecture can be implemented.

The access control ecosystem for RBAC and ABAC can be broadly categorized into two key areas: User-to-Role/Attribute and Role/Attribute-to-Resource.

User-to-Role/Attribute

The process of identifying users and determining their roles or attributes is a core part of the authorization process, often referred to as "identity and role/attribute mapping". For example, the user "Alan" might have the role "Admin" and the attribute "Department: IT." These user-to-role or user-to-attribute relationships are typically maintained in one or more systems, such as HR systems, user directories (e.g., Active Directory, RADIUS), or databases. In modern service-oriented enterprises, this information may also be retrieved through REST API calls to external systems.

Figure 1: Diagram showing user's access to resources

In the above image, we demonstrate how the "App" is informed about the Principal's role or attribute information in the request. The App could be informed by either:

1. The Identity provider performs the user role and/or attribute lookup in a database and embeds that information as a part of the ID JWT or SAML Token. The app receiving the token can validate the token signature and trust the information passed about the Principal.
2. The App performs its user role and/or attribute lookup.

Role/Attribute-to-Resource

The process of determining which permissions (or resources) are assigned to specific roles or attributes is a key part of access control policy lookup and enforcement. For example, the attribute "IT Department" might grant access to "Resource B."

Figure 2: Diagram showing and architecture of possible policy enforcement points in user's access of resources

The image above illustrates how access control policies are determined and enforced at various levels within an enterprise. Organizations may adopt some or a combination of these policy decisions and enforcement mechanisms. Let’s walk through a single request journey—from the user to the resource—and explore how policies can be evaluated and enforced along the way.

For example, consider a user signing into an application to view a report. In this scenario, the components of the access control policy are:

• Principal: Alan
• Action: read
• Resource: report_1
• Context: from an external device to the enterprise

Let's go over this request and see how access control policies can be evaluated and enforced at different points of the request.

1. The user attempts to sign in through an Identity Provider (IdP), which could be an external SaaS-based provider like Okta or Microsoft Entra ID, or an IdP hosted within the enterprise's infrastructure.

2. The Identity Provider may enforce identity-related authorization policies and decide whether to allow or deny the request. For instance, it might block requests originating from certain device types, blacklisted geolocations, or specific IP addresses. These policies can be defined within the IdP itself or managed externally by calling out to a centralized Policy Decision Point (PDP).

3. The Identity-Aware Proxy (IAP) operates at the network edge and enforces web-based access control based on the identity attributes and roles presented by the user. For example, if the user is anonymous, only sections of the website designated as "public" are accessible. If the user is authenticated, access is granted to internal pages as permitted by the defined policies and roles.

    # Sample policy structure in a Proxy
    
    # Public access for anonymous users
    location ~* ^/(home|about|contact)$ {
        allow all;
    }

    # Access for regular users
    location /dashboard {
        if ($http_x_user_role = "user") {
            allow all;
        }
        deny all;
    }

    # Access for admin users
    location /admin {
        if ($http_x_user_role = "admin") {
            allow all;
        }
        deny all;
    }

4. The API Gateway is positioned at the edge of the network. It can validate tokens and decide whether to enforce access control policies. These policies may be defined within the API Gateway itself, or the gateway may call out to a central Policy Decision Point (PDP) to check the policy and then enforce policies in the API Gateway accordingly.

5. A Service Mesh is increasingly popular in modern service-oriented architectures (SOA), where every capability is designed as a service, and internal applications can leverage shared capabilities. A service mesh can enforce network-level policies between services. For instance, it could enforce that only the "Reporting Dashboard" (a frontend service) is allowed to call the "Reports API" service, while all other services are denied access.

6. The application can enforce resource access policies either by embedding policies directly or by calling an external policy engine deployed as a sidecar PDP or a central PDP. For example, Cerbos supports both deployment models, with the sidecar architecture offering the advantage of extremely low latency for policy decisions. This is particularly useful when the central PDP is far from the app, avoiding delays caused by routing through multiple network hops.

#via SDK

if cerbos_client.is_allowed("view", "alan", "report_1"):
# access allowed

7. The resource itself can serve as the final layer of policy enforcement, directly controlling access. For example, in this case, the report "report_1" exists in a database and could be governed by a database policy that determines whether access is allowed or denied.

-- Create role for Service A
CREATE ROLE reporting_service;

-- Grant SELECT on report_1 to Service A
GRANT SELECT ON report_1 TO reporting_service;

-- Deny access for all other users
REVOKE ALL ON report_1 FROM PUBLIC;

Fragmented vs. Central Access Control Enforcement

Just as you would protect your home in layers, such as with a boundary gate and a front door lock, access control enforcement in an enterprise is applied in layers, as illustrated in Figure 2 the location of PEPs in user's journey to access a resource. While access control enforcement occurs in layers, the policy definition module (i.e., the PDP) does not need to be fragmented. Fragmented policy definition only leads to unnecessary management overhead, duplication of efforts, and complex scenarios when trying to determine what is deployed where. Layered policy enforcement can be further enhanced by using a Sidecar PDP to reduce latency in policy decisions through caching.

Let me share a real-life story that highlights the drawbacks of having a fragmented policy definition.

During my time in IAM operations, one of our recurring challenges was investigating access issues where users couldn’t log in to an app despite being authorized and following all the necessary steps to request access and attempt a login.

A particular app, let’s call it App X, was especially prone to such issues. The root cause wasn’t the enforcement of the access policy but rather how it was defined across multiple layers of the system. Resolving an issue often required coordination between at least three teams, as App X’s access policy was fragmented—spanning the web proxy, the identity manager or user provisioning software, and the user directory.

Compounding the problem was the enterprise ticketing system. User tickets frequently bounced between these teams, leading to delays. As a result, what could have been a straightforward fix often took a week to resolve.

Implications

Alright, we've identified the drivers for RBAC and ABAC and explored how they might be architecturally enforced. But what limitations or key considerations should we keep in mind before moving forward? Successfully implementing either model requires careful planning, along with robust systems and processes to ensure their effectiveness. Here are the key factors to consider for each:

RBAC

• Ensure that Line Managers, System Owners, and Process Owners understand their roles in the access approval process. They should be available to approve access requests within expected timeframes. Delays or inaction can impact project deadlines and reduce user productivity.
• Establish a process to assign backup approvers in case primary approvers are unavailable, such as during leave, to avoid bottlenecks in access approvals.
• Reviewers should ensure that access duration aligns with business needs. Assigning too short a duration can lead to unnecessary process overhead, while overly long durations can pose business risks if access remains active when no longer required.
• Implement a process to periodically check apps and services for unauthorized access. This ensures users do not gain additional permissions outside the defined RBAC roles.
• Conduct regular reviews of roles to avoid excessive role proliferation. For example, a system with 100 permissions but 200 roles with overlapping permissions undermines the purpose of Role-Based Access Control.
• Use clear and descriptive role names that are distinct from technical application role identifiers. For example, a role named "System Admin for AWS S3 Buckets" is more intuitive than "AWS_S3_10101010," simplifying reviews and audits.
• Assign each role to a designated owner and associated department to ensure accountability for maintaining and updating roles as organizational needs evolve.
• Without mechanisms to optimize the creation and management of roles, they can quickly spiral out of control. In previous experience managing IAM systems, I observed the onboarding of approximately 200 roles per month. While some were necessary, the absence of processes to streamline role creation and ensure proper resource coverage led to significant inefficiencies and complexity.

ABAC

• Systems and applications enforcing ABAC must have access to current user attributes with each request to ensure access decisions align with policies. For instance, if the source system (e.g., HR system) syncs with the enterprise directory or apps only once every 24 hours, there could be a mismatch between the user’s actual updates and the access granted.
• Since user attributes directly determine access, anyone managing the attribute source systems effectively becomes part of the IT Security and Access Control team. They must be trained accordingly to handle updates with security considerations. For example, if a user's title is updated to "CEO" in the source system, ABAC-based access controls would instantly reflect this change across systems.
• Adding more ABAC policies can quickly increase system complexity, making it challenging to understand who has access to what. For example, a policy might grant access to "Resource A" for a user located in Denver with the role of "Auditor" and sub-organization "X," while another policy grants access to "Resource B" for a user in Denver with the role of "Senior Auditor" and sub-organization "Y." This level of granularity can make access management harder to visualize and maintain.

Wrap

So, which should you choose: RBAC or ABAC? In reality, it will likely be a hybrid approach that combines both. In an enterprise, you’ll need pre-approved access to be provisioned to users as part of their birthright access, based on specific titles and attributes, where ABAC is an ideal fit. At the same time, the enterprise may require a well-defined system of roles that facilitates easy mapping to compliance requirements and supports time-constrained project access expiration, which makes RBAC a valuable option.

While implementing RBAC and ABAC methodologies and enforcing layered access control across enterprise networks, it's important to note that your policy definitions need not be fragmented. With centralized policy management tools like Cerbos PDP and Cerbos Hub, you can work toward consolidating your PDP into a unified solution. A common recommendation for enterprise customers is to adopt "one tool for one capability." In this case, policy definition in an enterprise can reasonably be consolidated into a single tool, offering clearer visibility, easier management, and the elimination of redundant efforts.

So the next time you are faced with RBAC vs ABAC, let the enterprise requirements drive your architectural decision and implementation.

What's next?

If you want to dive deeper into implementing and managing authorization, join one of our engineering demos or check out our in-depth documentation.