Choosing the right access control model is a tough nut to crack for engineering and DevSecOps teams, particularly in modern architectures that leverage multi-tenancy, cloud repositories, microservices, or APIs to deliver product experiences.
Without the requisite level of access control safeguarding a system, attackers can always exploit security loopholes to perform unauthorized operations within that system. This explains why organizations dedicate significant time and resources to continuously refine their access control systems to align with evolving security requirements and best practices.
Now, you might be wondering which access control framework is the most secure or superior.
The thing is, there’s no one-size-fits-all approach when it comes to authentication and authorization. The right access control model — whether it is RBAC, PBAC, ABAC, or a hybrid approach — heavily depends on the specific context and prevailing circumstances of your organization at the time. It depends on the size of the business, the complexity of operations and business model, the sensitivity of data and resources being protected, or even industry regulatory requirements.
RBAC is an excellent choice for small to medium-sized organizations, engineering teams, or IT departments with straightforward access control requirements. However, PBAC and ABAC are better suited to large organizations with complex workflows and relationships, and the necessary engineering, IT, and DevSecOps resources to effectively manage this complexity.
In this article, we’ll explore the key differences and applications of three access control architectures — RBAC, PBAC, and ABAC. We’ll unravel their distinctive characteristics and potential similarities to arm you with the requisite knowledge to make an informed decision when selecting the most suitable model for your use case.
The static parts of role-based access control (RBAC)
Role-based access control (RBAC) is a widely adopted model for restricting access to system resources based on assigned roles, rather than individual identities.
Roles are a set of permissions that can be assigned to individuals or groups of users, including human users or non-person entities (NPEs) such as applications or services. Permissions, in turn, define the specific actions that these users are allowed to perform on various resources within the system.
However, it’s important to note that permissions are not directly assigned to users in RBAC. Instead, administrators define roles and associate specific permissions with them. Users are then assigned to suitable roles based on their responsibilities and functions within the system.
RBAC stands out as a highly adaptable access control framework because it doesn’t impose any specific set of security rules or principles on organizations. Instead, RBAC can be implemented in four distinct incremental levels, each incorporating widely recognized security principles and policies.
These principles, such as the principle of least privileges, data abstraction, and separation of duties, are integrated at the different implementation levels, allowing organizations to tailor the framework to their unique access management requirements.
Nonetheless, if you consider how permissions are assigned to roles and roles to users, RBAC is a highly rigid and static framework. Both roles and assigned permissions are predefined and inflexible.
Roles are strictly associated with permission sets and users are confined to these roles unless administrators initiate any changes. This static nature of RBAC can be limiting for complex architectures that frequently require adjustments to responsibilities, data sensitivity, or even security requirements. In such scenarios, organizations might opt for more dynamic access control models, such as PBAC or ABAC, to gain finer control and make granular decisions.
To provide finer-grained access permissions via RBAC, the model allows users to be assigned to multiple roles with overlapping permissions, and higher-level roles can inherit permissions from lower-level roles. However, this approach also introduces inherent security weaknesses.
Overlaps, whether intentional or unintentional, can grant users access to resources or allow them to perform actions intended for other roles. Consequently, this compromises the security principles that RBAC aims to uphold in the first place.
We’ve written a comprehensive article that covers roles-based access control (RBAC) in depth. You can find it here.
The pseudo-granular parts of policy-based access control (PBAC)
While PBAC and ABAC are often used interchangeably, they’re distinct concepts that only share similarities. All ABAC architectures can be considered as PBAC, but not all PBAC architectures qualify as ABAC.
Policy-based access control (PBAC) is an overarching term that refers to any access control system that uses policies to determine access permissions. In contrast, ABAC is a specific type of PBAC that employs attributes within its policies to make access control decisions.
Basic or traditional PBAC introduces more flexibility to the static roles and permissions in RBAC by incorporating predefined rules within its policies. These rules enable conditional relationships between requesting subjects or users (defined by role or group), the objects or resources being accessed (specified by resource type, path, or identifier), and the actions being performed on these resources (create, read, write, or delete operations).
While PBAC extends the capabilities of RBAC, it doesn’t match the fine-grained access control provided by ABAC. For example, Uber initially ran their microservices architecture on a basic PBAC with YAML policies centrally managed by a policy service. These YAML policies contained predefined rules that didn’t directly use attributes but referenced predefined roles, resource types, and actions.
While this basic PBAC system was functional in straightforward scenarios, it lacked the flexibility and granularity required to handle Uber’s evolving authorization requirements. For instance, customer service reps couldn’t retrieve payment-related information beyond the payment profile identifier (UUID) for customers in a specific country or city.
To address this problem, Uber migrated to an ABAC architecture and adopted dynamic policies based on attributes rather than rule-based policies. They leveraged Google’s Common Expression Language (CEL) to write policy conditions drawing upon different attribute sources within Uber and stored these conditions in an expression engine. They also introduced an attribute store to centralize all attributes referenced in the expression engine and implemented an attribute retrieval system that consumer services could use to retrieve attributes relevant to their unique business domains and operations.
For a more comprehensive exploration of Uber’s revamped ABAC architecture, refer to our “What is attribute-based access control (ABAC)?” article.
The choice of policy language (whether it’s XML, ALFA, OPA, OPAL, or CEL) might seem like a defining factor in categorizing an architecture as ABAC or PBAC. However, the key distinguishing feature lies elsewhere. What truly sets these architectures apart is whether they rely on attributes or rules and adhere, even loosely, to the standard ABAC-XACML architecture, which consists of PEP, PDP, PRP, PAP, and PIP components.
The fine-grained parts of attribute-based access control (ABAC)
Unlike RBAC’s static roles and PBAC’s predefined rules, attribute-based access control (ABAC) empowers organizations to implement contextual access management policies by incorporating a wide range of dynamic attributes and conditions.
Think of these attributes as unique labels or properties attached to users, resources, actions, and even the environment where an interaction occurs. Much like a human’s fingerprint, the combination of these attributes creates a detailed and distinctive profile for each access request, enabling highly precise and context-aware access control.
For instance, a user might possess the attribute “seniorEngineer,” a resource could have the attribute “confidential,” an action might be labeled as “edit,” and an environmental condition might be “deviceType.” If the attributes associated with a request align with the predefined conditions of a policy, access is granted; otherwise, it’s denied.
This flexibility enables systems to enforce access control decisions based on a granular understanding of the user or service making a request, the resource being accessed, and the context surrounding the request.
ABAC architectures leverage XACML (Extensible Access Control Markup Language), as specified by OASIS (Organization for the Advancement of Structured Information Standards), to define the conditions, rules, and policies that govern access decisions. However, modern organizations are increasingly embracing more user-friendly open-source policy languages to craft ABAC policies.
While XACML remains the standard for expressing ABAC policies, its complexity and debugging challenges have led to the development of alternative policy languages. These languages streamline the policy-writing process, making it more accessible to developers.
ABAC rules, irrespective of whether they’re written in XACML or other policy languages, significantly differ from the basic PBAC rules we observed in the Uber example. ABAC rules are constructed using attributes and function as conditional statements that determine whether a policy or policy set can be evaluated for a specific request. This approach eliminates the need for broad and inflexible roles, providing more granular control over who can access what, when, where, and why.
The XACML standard is not just a policy language for ABAC, but also an architectural guide. It defines how requests, policies, rules, and attributes should interact within ABAC systems, ensuring seamless decision-making and policy enforcement. This architecture functions as a well-coordinated system, with each component playing a crucial role.
A typical ABAC architecture that adheres to the XACML standard consists of five primary components that work in tandem:
- Policy enforcement point (PEP): Oversees compliance with established policies and enforces decisions that must have been made by the PDP.
- Policy decision point (PDP): Serves as the central evaluator and decision-maker, assessing attributes, policies, and rules to grant or deny access permissions.
- Policy information point (PIP): Functions as a data provider, retrieving and supplying the necessary attributes required by the PDP.
- Policy retrieval point (PRP): Acts as the policy retriever, fetching relevant policies based on the specific context of the request.
- Policy administration point (PAP): Manages the entire policy lifecycle, including the creation, modification, and deletion of policies.
It’s essential to acknowledge that not all ABAC systems strictly conform to this standard structure. In ABAC systems that employ custom policy languages, certain components, such as the retrieval and decision points may be absent since the policy agent directly manages these functions. Despite these variations, becoming acquainted with the XACML architecture provides a valuable framework for understanding the overall flow and interactions within an ABAC system.
How to choose the right access control model for your use case?
Choosing the right access control model is a highly contextual decision. Different models provide distinct advantages and drawbacks, depending on your specific requirements and context.
For example, RBAC is commonly preferred for its simplicity and straightforward implementation, particularly suitable for CRUD applications. However, RBAC’s static nature can be restrictive in dynamic development environments where access decisions are fluid or context-dependent.
ABAC, on the other hand, is highly suitable for architectures that require flexibility and granular control. ABAC’s fine-grained approach makes it particularly valuable for managing complex relationships within dynamic or highly regulated environments. However, this flexibility comes at the cost of increased complexity and administrative burden.
The right access control model extends beyond comparing RBAC, ABAC, and PBAC. Your specific infrastructure and applications play the most vital role.
For instance, SaaS applications introduce multi-tenancy and shared responsibility models that necessitate tailored access control strategies in a hybrid model. Microservices architectures, with their distributed nature and dynamic scaling, also require consistent and dynamic security across multiple services and components simultaneously.
Ultimately, your decision hinges on finding the right balance between security, usability, and scalability:
- Security: How sensitive is the data you’re protecting? What level of granularity and control do you need to enforce?
- Usability: How easy should it be for authorized users to access resources? How will/do users feel about the experience?
- Scalability: Can the chosen model adapt to your organization’s growth and evolving requirements? Will it remain manageable as systems and user bases expand? Can the complexity of ABAC be justified by the granular control?
By carefully assessing your requirements and constraints, you can navigate the inherent complexities of these access control models and choose the approach that best protects your systems from unauthorized access. Remember, it’s not just about choosing a model alone, it’s about finding the right balance for your specific use case.
You should choose RBAC if……
For many organizations, simplicity and ease of management is highly important when it comes to access control. This is where RBAC shines. It’s an excellent solution for straightforward scenarios, such as:
Small and medium-sized businesses: Ideal for small businesses with well-defined user groups, roles, and limited data sensitivity. Imagine an e-commerce platform with clearly defined roles for customers, editors, and administrators. Each role has distinct permissions, making access control straightforward to maintain.
Internal corporate applications: Many internal business applications have predictable user roles and access requirements. For example, a CRM system used by a sales team might only require a handful of roles, each with specific permissions for viewing, editing, or managing customer data.
Simple CRUD applications: RBAC excels in managing access to basic data operations like create, read, update, and delete. Consider a blog platform where users have clearly defined roles (author, editor, reader) with corresponding permissions for managing content.
In these kinds of applications, many users perform the same function, and their responsibilities rarely change. As such, only a handful of roles are needed, which can be assigned to as many users. In this case, RBAC effectively restricts system access and enforces the necessary level of control without imposing excessive administrative burdens.
You should choose PBAC if……
For organizations looking to move beyond the limitations of RBAC without dealing with the full complexity of ABAC, PBAC can be a strategic middle ground. It offers more granular control than static RBAC roles while remaining less resource-intensive and complex than ABAC’s dynamic attributes. Here are scenarios where PBAC excels:
Transitioning from RBAC to ABAC: If your organization has outgrown RBAC’s rigidity but lacks the resources or infrastructure for a full-fledged ABAC implementation, PBAC can serve as a stepping stone. You can leverage existing RBAC roles as a foundation and add PBAC policies for finer-grained access control based on predefined conditions, such as time of day, location, or specific actions. This hybrid approach allows you to gradually evolve your access control without a complete overhaul.
Addressing specific limitations in RBAC: Perhaps you need more nuanced access control within specific areas of your system, say controlling access to sensitive data. You can address these limitations without modifying your entire RBAC structure by implementing PBAC policies alongside your existing RBAC roles. For example, you can create PBAC policies that require additional authorization for accessing highly confidential files, even for users within specific RBAC roles.
You should choose ABAC if……
For organizations that require dynamic and context-aware access control mechanisms beyond traditional policies or roles, ABAC is the most suitable approach. Unlike RBAC’s static roles and PBAC’s pre-defined rules, ABAC leverages dynamic attributes and conditions to identify every single request. Here are scenarios where ABAC excels:
Dynamic business models and environments: Organizations adopting cloud deployments, microservices architectures, or multi-tenancy encounter highly dynamic access control challenges. However, ABAC’s flexibility empowers these organizations to seamlessly manage access control across diverse systems, dynamically determining access permissions based on set policies and evolving business requirements.
Complex compliance requirements: In heavily regulated industries like healthcare or government, stringent data access regulations demand granular control. ABAC excels in meeting these requirements by leveraging attributes like user certifications, data classification, and even device location to enforce fine-grained access policies.
Implementing RBAC using Stytch
Contrary to popular misconceptions, RBAC, ABAC, and PBAC aren’t features of any particular identity provider (IDP). Rather, they are distinct architectural patterns for governing access to system resources.
For multi-tenant Saas applications that require dynamic RBAC, our robust B2B authentication product has been designed to effortlessly handle diverse multi-tenancy requirements, including per-organization settings, memberships, and both self-serve and enterprise onboarding.
With Stytch, you gain precise control and customization capabilities. You can conveniently store application-specific or business-specific attributes within both the organization and member objects. This empowers you to tailor the authentication experience to your unique requirements, ensuring a seamless and personalized journey for your customers and their end users.
To learn more about RBAC using Stytch, check out our documentation and sign up for a free developer account to start building with our robust APIs. If you have any questions, please reach out to an auth expert to start a conversation or send us a message at support@stytch.com.
SHARE
