How to Choose the Right Access Control Security Model: ACL vs RBAC vs ABAC

Having extensive expertise in software development, we, at MobiDev, know that creating a security strategy for your software product is crucial. Robust access control systems secure sensitive data by making it hard for hackers to gain access. Access control systems prevent malicious actors from using your system and allow legitimate users to utilize tools and services safely.

In this article, I will answer these  questions: 

• What are the main types of access control?
• What are their strengths and weaknesses? 
• What are their potential use cases? 

Additionally, you will find general guidance on the implementation of these models based on MobiDev’s more than 14 years of experience in this regard. The MobiDev team can both meet the defined requirements and suggest a solution that best matches the specifics of the product. We don’t focus on a particular model, but on the results clients want to achieve in a long-term perspective.

Top 3 Access Control Model Types

There are several classifications of access control models, depending on various factors, but the most common models include ACL, RBAC, and ABAC. We will discuss them in more detail since they can cover most of the organizations’ needs. However, each model has its strengths and limitations and the final choice usually depends on your security strategy.  You can see a basic comparison of ACL, RBAC, and ABAC in the table below.

1. Access Control Lists (ACL)

Access Control Lists (ACLs) are lists that define who can access a resource and what actions they can perform on that resource. They are often used in file systems or network devices, where permissions are associated with individual resources.

ACLs provide a basic mechanism for specifying access permissions by associating access control entries (ACEs) with individual resources. Each ACE typically includes a subject (user or group) and a set of permissions (e.g., read, write, execute) that determine the subject’s actions on the resource. ACLs are often implemented at the file system level or for network devices.

There are two main types of ACLs:

1. File system ACLs manage access to files and directories. They provide the instructions for the OSes that specify user access permissions for the system and their rights on the system.
2. Networking ACLs control network access by giving instructions to network switches and routers that determine the types of traffic that are allowed to interface with the network. These ACLs also establish user permissions in the network. The network administrator predefines the networking ACL restrictions. 

ACLs can also be divided by the way they identify traffic:

• Standard ACLs block or allow an entire protocol suite utilizing source IP addresses.
• Extended ACLs block or allow network traffic based on a more differentiated set of features including source and destination IP addresses and port numbers.

Advantages of ACLs

Utilizing Access Control Lists (ACLs) offers various advantages, including:

1. Simplified User Identification

ACLs facilitate user identification, ensuring that only authorized users and traffic gain access to a system.

 2. Performance

ACLs deliver performance benefits compared to alternative technologies with similar functions. Configured directly on the forwarding hardware of routing devices, they don’t impact device performance negatively. In contrast, other inspection firewalls, as separate software elements, may cause a decrease in performance. The control over network traffic improves overall network efficiency.

3. Control

ACLs give administrators fine-grained control over user and traffic permissions throughout the network. They are essential in managing access to network endpoints and regulating traffic flow between internal networks. This level of control is crucial for achieving improved network security and operational management.

Limitations of ACLs

On the other hand, ACLs have some disadvantages as well. Here are some of them: 

1. A lack of efficiency

ACLs might demonstrate inefficiency in some cases as they work with explicitly defined access controls. For example, if a user possesses specific access or permissions due to simultaneous membership in both the IT department and a managerial role, this upgraded level of access must be specified rather than automatically extrapolated from group memberships.

2. Scalability issues

This limitation is connected with the previous one. The necessity for an explicit declaration of access controls negatively affects scalability. As the number of users, user groups, and resources increases, the ACL and the time necessary to define the level of access given to a particular user increases.

3. Blurred visibility 

ACLs come with multiple, autonomous lists with a user’s permissions and levels of access. As a result, checking, changing, or revoking access requires a review of every ACL in the business environment to apply the new permissions.

How to implement ACL

To implement an Access Control List (ACL), network administrators require an exhaustive understanding of the inbound and outbound traffic within the network, along with the character of the resources requiring protection. Next, administrators should organize and govern IT assets hierarchically, assigning particular rights to users based on these categories. This structured approach ensures the effectiveness of ACL implementation in protecting network resources.

A standard ACL is typically implemented the closest to the destination it aims to protect. However, access control lists can be positioned on any security or routing device, and maintaining multiple ACLs in different parts of the network can be advantageous. ACLs should be adopted for network endpoints like applications or servers as they require high security as well as performance and speed.

Based on differences in network architecture, ACLs must be configured differently. This incorporates differences between on-premises, physical networks, and cloud networks.

2. Role-Based Access Control (RBAC)

RBAC allocates permissions to users based on their roles within an organization. Users are assigned roles, and permissions are linked with those roles. RBAC simplifies administration by grouping users depending on their functions or responsibilities. This model is commonly used in enterprise systems of different levels such as ERP, CRM, healthcare and financial systems, eCommerce platforms, etc. 

The most typical case is when we have well-defined user groups with similar functionality. The best scenario is when the functionality of these groups doesn’t overlap. 

For example, we have three business rules: 

• only an administrator can manage the company
• only an accountant can conduct financial activities 
• only a manager can manage orders 2 ADMINIST

Types of RBAC

When it comes to the RBAC model, we can define three types: core, hierarchical, and constrained.

• Core RBAC

The core model includes the key elements of a role-based access control system. Although the core RBAC can be an independent form of access control, it also is a foundation for both the hierarchical and constrained models.

The core RBAC  model, as well as the other two ones, should meet the following rules:

1. Role assignment: A user can get and utilize permission only if the user has selected or been assigned a role.
2. Role authorization: A user’s active role must be authorized.
3. Permission authorization: A permission should be authorized for the user’s active role.

• Hierarchical RBAC

Hierarchical RBAC models allow organizations to define role hierarchies. These hierarchies can be presented as organizational trees. Hierarchical RBAC systems make role-based access control easier by decreasing the number of unique roles an organization must manage. 

• Constrained RBAC

The constrained RBAC model introduces the separation of duties to the core RBAC model. Separation of duty relations can be divided into two types: static and dynamic.

1. In the Static Separation of Duty (SSD) model, a single user cannot hold mutually exclusive roles (as defined by the organization). 
2. In the Dynamic Separation of Duty (DSD) model, a user can be a member of conflicting roles. At the same time, the user mayn’t execute both roles during the same session. 

If you don’t know whether RBAC is for your business, our tech specialists can help you make the better choice for your organization and then assist in the implementing the RBAC model into your operation model.

Advantages of RBAC

Role-based access control offers clear benefits, including: 

1. Simplified management

RBAC simplifies the management of access control by organizing permissions based on roles. This makes it easier to add or remove users and assign or annul permissions. With RBAC, businesses can spread consistent access policies across their organizations. 

2. Scalability and flexibility

RBAC is quite scalable, making it suitable for organizations of varying sizes. As the organization grows, new roles can be added without seriously increasing administrative workload. Levels of responsibility, separation of duties, and other rules can be incorporated into the role and permission definitions.

3. Ease of maintenance

RBAC allows organizations to automate permission assignments and reduce administrative burdens. Administrators can add new users quickly and effectively through simple interfaces. Any changes to roles or permissions automatically apply to all users with those roles.

4. Policy management

RBAC facilitates centralized policy management. Security policies are associated with roles, and changes to policies can be applied uniformly to all users within a specific role.

5. Enhanced security and compliance 

RBAC improves security by ensuring that users have only the necessary permissions for their roles. This minimizes the risk of unauthorized access and reduces the attack surface. Such systems often provide comprehensive audit trails, allowing organizations to track user activities and changes in access permissions. This is beneficial for compliance purposes.

Limitations of RBAC

Although RBAC has numerous advantages, there are also some limitations to consider: 

1. Complex implementation

Implementing RBAC can be complex, especially in large organizations with diverse roles and responsibilities. Being time-consuming, it may require a thorough analysis of organizational structure and processes.

2. Excess number of roles 

In some cases, the number of roles can become overwhelming, leading to a phenomenon known as “role explosion”. This occurs when a large number of roles are needed to sufficiently align with the diverse set of permissions required by different users.

3. Dynamic environments

RBAC may face challenges in dynamic environments where user roles and responsibilities frequently change. Adapting the RBAC model to rapidly changing organizational structures can be challenging.

How to implement RBAC

To implement RBAC, start with the RBAC strategy by performing a comprehensive assessment of your current situation. 

1. Identify the systems, data, and processes within your organization that could benefit from access control. It is necessary to consider job functions, technologies, and business operations, initially using a broad context and refining the subject of your research progressively.
2. Define your desired situation. Determine if RBAC will be utilized for automating provisioning or enhancing access control for applications containing sensitive data. Clearly articulate the outcomes you expect from implementing this process.
3. Identify any existing gaps that need addressing. Assess the consistency of authentication and authorization models across the organization. Ensure compliance with regulatory requirements and consider whether any security incidents necessitate a shift to RBAC.

Once your strategy is designed, it’s time to dive into the details.

1. Organize your systems

Compile a comprehensive list of resources and services requiring access control, varying from email and cloud apps to customer databases and shared folders on file servers.

2. Evaluate your human resources 

Conduct a collaborative role and access discovery process involving IT, HR, and executive managers. Group the workforce into roles based on shared access needs, encompassing both current and planned departments. Be careful about defining too many roles, maintaining a balance between security and simplicity

For larger organizations, adopt a two-pronged approach to role creation. Start with a top-down analysis where business managers design roles aligning with company goals. At the same time, IT specialists should conduct a bottoms-up analysis, suggesting roles based on user-system interactions.

3. Create and define roles

Adjust the results of workforce analysis with the resources from your inventory, sticking to the principle of least privilege. Define roles, such as Basic User, Hiring Manager, or Employee Database Administrator, and allocate specific access rights accordingly.

4. Designate a structure

Beyond defining roles, create a governance structure responsible for maintaining them. This includes documenting project priorities and standards, implementing performance standards, risk-management strategies, role re-evaluation guidelines, and plans for policy updates. Policy-based access control prevents role proliferation and ensures ongoing alignment with organizational interests.

4. Assign users to roles

With the preparation work finished, implement RBAC by assigning roles to employees based on the inventory and workforce analysis. In larger organizations, it’s better to implement a staged rollout with a group of users to collect feedback, make changes, and then expand. This approach minimizes troubleshooting and helps to demonstrate the real value of the role-based access control model.

At MobiDev, we implement the RBAC model for our client’s projects more often. For example, while developing a Node.js-based employee management system four user roles: Employee, HR Manager, Administration Manager, and Super Administrator. This allowed our team to organize a simple but safe access hierarchy for various system modules. 

3. Attribute-based access control (ABAC)

A widely used solution is good for setting up and managing user roles. However, it can eventually lead to a dead end, when the functionality of user roles overlaps multiple times. In fact, it is not uncommon among enterprises with ever-growing role functionality to reach the point when the quantity of possible roles surpasses the quantity of actual users. Here is where ABAC comes to help. 

ABAC is considered a next-gen authorization model since it enables dynamic, context-specific, and risk-managing access to resources that can be adapted to different access control policies. The primary difference is that each situation revolves not around users or actions, but rather around their attributes. Every business rule can be presented as a set of conditions, where attributes must comply with specified requirements. An attribute is always part of an object, so we need to single out several entities for a proper description of business rules and logic. Any business logic operates four entities: Subject, Object, Action, and Environment. Or, to be more precise, a Subject (in our case User) performs an Action on an Object (in our case, a Resource) in a specific Environment.

The main characteristic of ABAC is that the addition of new attributes does not alter business rules, since access conditions are independent. This solves the problem of changing business rules over time. It is enough to have a mechanism that resets rules in an application to match resource access rules with the changing business rules. Moreover, there is no need to change the code.

Overall, with the use of multiple attributes for authorization, ABAC allows to ensure a more granular approach to access control.

The typical process unfolds as follows:

1. Users initiate access requests.
2. The Attribute-Based Access Control tool scans attributes to verify alignment with established policies.
3. Depending on the outcome of the ABAC tool’s analysis, the system either grants or denies permission.

Advantages of ABAC

The ABAC model has unique capabilities that may provide significant benefits to businesses, including the following: 

1. Flexibility and a wide arrange of policies

ABAC’s flexibility lies in its attribute system that provides high context and granular access. Almost any kind of policy can be created in ABAC with the only limitations that include the attributes and the conditions of the computational language.

2. Dynamic authorization and easy onboarding 

Since ABAC is attribute-based, it allows authorization for data or applications to be dynamically assigned or revoked in real-time. Plus, the onboarding of new employees is simple as administrators and object owners can easily create policies and assign attributes that grant new users access to resources.

3. Encapsulation

ABAC uses encapsulation to hide technical permissions in plain sight. Access decisions are changed just by modifying attribute values without the hassle of changing the underlying subject/object relationship.

4. Smart access restriction

ABAC helps policymakers implement smart restrictions with intelligent context for privacy and security. In addition, it can ensure users or user groups have access to only certain kinds of resources or operations, depending on the application, location, or time of day.

5. Regulatory compliance

 ABAC’s granular permissions and controls make it easier to satisfy various compliance regulations (HIPAA, GDPR, PCI DSS), for protecting personally identifiable information (PII) and other sensitive data.

6. Scalability 

ABAC demonstrates high scalability capabilities. Once ABAC has been set up, administrators can copy and reuse attributes for other components and user positions, which makes policy maintenance and new user onboarding faster.

Limitations of ABAC

While ABAC strengthens organizations with immense capabilities and advantages, it also comes with several cons, so you must be aware of its limitations.

1. Complexity while implementing

While ABAC is easy to use and maintain, administrators have to work with the increased complexity during the design and implementation of ABAC. These processes are time-consuming and require resources to thoroughly define and assign the attributes, as well as design the accompanying policies. However, the investment during the first stages of ABAC implementation usually pays off. 

2. Risk exposure 

It can be difficult or even impossible to define the risk exposure for a particular employee or organizational role.Therefore, we need to take this into account. 

3. Data challenges 

If the business has data dispersed across several data stores, warehouses, and lakes, the complexity of adopting ABAC rises. For example, each location may require different implementation approaches, adding vagueness and complexity.

How to implement ABAC

ABAC utilizes application and system attributes to establish rules and policies for governing the behavior of subjects and the actions they can perform on resources.

1. To implement a functional ABAC system, the initial step involves assessing how attributes (user/subject, resource/object, action, and environment) interact within the IT environment.
2. Following this evaluation, administrators create rules to manage these attribute interactions.
3. System and information security administrators then define specific attributes aligning with the company’s business needs and regulatory obligations. ABAC, in turn, oversees access to system objects by assessing rules against access control lists, considering the attributes of the entities involved.
4. When a request is initiated, the software tool implementing attribute-based control scrutinizes the subject’s attributes to determine their accordance with existing policies for the requested action.
5. Access is granted to a subject or user upon meeting specific rules or requirements. Therefore, the system can approve or reject requests based on user and object attributes.

Combining RBAC and ABAC

In some scenarios, organizations choose to combine RBAC and ABAC to create a more flexible and fine-grained access control system, as this allows organizations to take the best from both worlds and get rid of some limitations.

Implementing RBAC-A in an organization can be achieved through various methods:

1. Embedding the RBAC role within ABAC as one of the user attributes. The “role” attribute then signifies a predefined set of attributes necessary for that particular organizational role.
2. Introducing attributes to limit roles, allows RBAC to establish fundamental access control rules, while ABAC refines permissions based on specific criteria, thereby restricting user access.
3. Establishing dynamic roles by determining the RBAC role through other attributes defined in ABAC. For instance, a user’s current location or the current time can dynamically influence their inclusion or exclusion from a particular role.

RBAC can be utilized to reduce high exposure risks, while ABAC can manage access at a more detailed level. Opting for an initial implementation of RBAC, followed by a gradual integration of ABAC, may help reduce the complexity associated with the initial ABAC setup. On the flip side, ABAC introduces finer-grained filtering capabilities to RBAC.

These strategies offer organizations flexibility in tailoring access controls, combining the strengths of both RBAC and ABAC to achieve a more nuanced and context-aware security framework.

How to Choose the Right Access Control Strategy for Your Product

When choosing the right access control strategy for a software product, several factors should be considered. These factors can vary depending on the specific requirements and characteristics of the project:

• Security Requirements: Take into account the sensitivity of the data or resources being protected, compliance requirements, and any industry-specific regulations that may apply. Higher-security environments may require more robust and stringent access control models.
• Complexity and Scale: Determine the number of users, resources, and the level of granularity needed for access control. Projects with a large number of users or resources may benefit from more scalable and flexible access control models.
• Flexibility and Dynamic Access Control: Determine if the access control requirements are relatively static or if they need to be dynamic and adaptable based on changing conditions. 
• Administration and Maintenance: Consider the complexity of managing user permissions, adding or removing users, and updating access control policies. Choose a model that aligns with the available administrative resources and the desired level of administrative effort.
• Integration with Existing Systems: Determine if the software product needs to integrate with existing systems or frameworks that have their own access control mechanisms. 
• Future Scalability and Extensibility: Consider whether the chosen access control strategy can accommodate future expansion, additional functionalities, or changes in user roles and responsibilities.

Here, at MobiDev, we have multi-year experience with all access control models and can advise you on the right approach for your web or mobile product. After analyzing your requirements and the current infrastructure, our engineers will select the best solution for your business and implement it following the best security practices.