Optimizing Authorization Security: A Guide to Access Control Models

Authentication is not the end of the login process. Authorization, which controls access to resources and data, almost always follows authentication. It’s a layered security approach that ensures users have the appropriate level of access, preventing any one person from having too much power or arbitrary access to information. With the user’s identity confirmed, authorization dictates what actions they can take on an application or resource.

This article focuses on common authorization models and their importance. However, before you delve into the details, it’s worth defining authentication and authorization side by side to clarify their distinct roles:

• Authentication verifies who you are, using something you know (password), something you have (passkey), something you are (biometrics), or someplace you are, or a combination of these.
• Authorization determines what you are allowed to do, granting permissions, identifying accessible resources, and defining allowed actions for users and programs.

Authentication confirms who you claim to be, while authorization ensures users have the correct permissions for their actions. This process is integral to a company’s security posture, protecting data and access to people, places, and things. Access controls put authorization policies into action, managing permissions through roles, attributes, policies, and relationships. Due to its importance, multiple models exist to control authorization. Each model determines access uniquely, and by discussing the four common models, you can address and reduce common authorization challenges.

This article explores four common authorization models, highlighting their uses and contexts. These models simplify access and reduce manual labor and errors. For example, imagine having to define permissions for each individual user. A model like Role-Based Access Control (RBAC) saves you extra work by allowing you to define roles. Similarly, instead of creating new rules and roles for every scenario, Attribute-Based Access Control (ABAC) manages permissions using attributes, providing a flexible solution. Models like Policy-Based Access Control (PBAC) centralize policy management, reducing administrative costs, while Relationship-Based Access Control (ReBAC) efficiently manages the relationships between users and resources, making it ideal for handling large volumes of data.

Each model that you will learn about, Role-Based (RBAC), Attribute-Based (ABAC), Policy-Based (PBAC), and Relationship-Based (ReBAC), serves different needs. Below is a chart summarizing their strengths and weaknesses. Let’s examine these in more detail throughout the article:

With this overview in mind, let’s explore the relationship between various access control options and their roles in authorization best practices.

Complexities of Authorization and Access Control

Authorization boils down to a basic idea: stopping any access which should not be allowed. But hey, let’s face it—mistakes happen, especially when humans are involved. Nothing is perfect. Preventing unauthorized access requires that the appropriate resources and management protocols are in place. RBAC, ABAC, PBAC and ReBAC models prevent security breaches in today’s tech-driven world.

For instance, according to the 2021 OWASP Top 10 (the most recent version), broken access controls are the most prevalent vulnerability in web security. This is still relevant in 2024, as evidenced by Splunk’s 2024 State of Security Report: “Among those who say cybersecurity is getting more difficult, 38% cite threat landscape sophistication as the reason why…They’ll also have a harder time protecting against simple human errors, like misconfigurations, which rank as this year’s top threat vector.” Misconfigurations can lead to broken access controls. Professionals can combat sophisticated threats and minimize misconfigurations with models such as RBAC, ABAC, PBAC, and ReBAC. Implementing one of these models addresses complex environments and significantly reduces the risks associated with broken access controls.

Let’s take a look at details for each of these models. To make things more concrete, let’s discuss an IT organization and focus on three employees: Moss and Roy who are regular employees, and Jen, their boss. (Yes, this is an IT Crowd reference.)

RBAC: Simplifying Access Management

Role-Based Access Control (RBAC) simplifies access management by using predefined roles aligned with company functions and responsibilities. This approach lets administrators efficiently manage permissions without adjusting them for each user. Assigning permissions to roles reduces redundancy, as users inherit permissions through their roles. This makes updates easier, streamlines onboarding and offboarding, and simplifies auditing for compliance and proper assignment

Roles in RBAC are usually defined by authority, competence and responsibility. Every role comes with a set of permissions. Common roles include administrator, specialist, or regular user—each determining the level of access to various types of information, such as health, financial, or administrative data, and defining permissible actions like reading, writing, or deleting.

Here are the roles held by Roy, Moss, and Jen, along with the permissions associated with each role:

1. Administrator Role:
   • Role Name: Administrator
   • Assigned User: Jen
   • Permissions: Manage users, read files, write files, delete files.
2. IT Specialist Role:
   • Role Name: IT Specialist
   • Assigned Users: Roy, Moss
   • Permissions: Read files, write files.
3. Compliance Officer Role:
   • Role Name: Compliance Officer
   • Assigned User: Moss
   • Permissions: Access sensitive data.

In this example, Roy, Moss, and Jen are IT specialists, so all three have access to help desk software and necessary tools. This grouping simplifies management. The IT Specialist role covers general IT tasks, while the Compliance Officer role includes additional permissions for sensitive data. Each role has different privileges: Jen, as the administrator, has the highest level of access, while Moss has specific privileges needed for his role. RBAC systems should restrict permissions based on the principle of least privilege, granting users only the access required for their jobs.

RBAC is predictable and easy to manage since roles and their permissions are consistent for everyone. It is a great fit when there is a consistent role-to-employee mapping. Although RBAC offers flexibility, increasing role complexity can lead to role proliferation, complicating access management. It’s important to routinely outline and review roles and test permissions. With careful planning and monitoring, RBAC remains a straightforward and secure access control model for authorization needs.

ABAC: Determining the Who, What, When, Where, and Why in Access Control

Attribute-Based Access Control (ABAC) establishes policies based on a combination of attributes that define what actions can be performed. It controls access based on details of a request and contextual factors, asking who can have access to what and under what conditions. Understanding how attributes are used in ABAC is crucial for distinguishing it from Policy-Based Access Control (PBAC), which is covered next. Remember that ABAC relies on a predefined list of attributes. There are four categories of attributes used to make decisions:

• Subject attributes describe the characteristics of users or entities requesting access. These attributes include their name, age, job title, department, group affiliation, and management level. A role can be a subject attribute, but, in contrast to RBAC, it won’t completely determine access. For example, Roy and Moss in the IT department require access to general IT information. While both need similar permissions, Moss is a compliance officer with additional responsibilities, while Roy is a regular user. In an ABAC system, a range of attributes beyond roles are considered. User attributes such as ‘security clearance’ and ‘special responsibilities’ play a crucial role. Moss’s higher security clearance and additional responsibilities allow him to access more sensitive information than Roy.
• Resources refer to the items that someone wants or needs access to, such as a file or a web application. Resource attributes include identifying characteristics of the resource, such as the owner, name, type, creation time, and data sensitivity. To build on the previous example, while both Roy and Moss can see the owner and name of a file, if a file contains sensitive information, only Moss can see the contents. This is because the resource attribute ‘data sensitivity’ requires higher clearance and special responsibilities, which Moss possesses.
• Action characteristics dictate how users can interact with requested resources, with common actions including viewing, reading, writing, editing, sharing, and deleting. For example, Moss can have permissions to read and write a client’s file, but the authority to delete is reserved for Jen. Instead of just giving broad access, ABAC can specify exactly what each user is allowed to do (e.g., read, write, delete) based on their attributes and the attributes of the resources.
• Environmental attributes include communication protocols, the user’s device, IP address, network details, and the time and location of the access request. For instance, under ABAC policies, Moss, Roy, and Jen can access IT software only when using their work-assigned laptops. This contextual awareness differentiates ABAC from RBAC and allows for more precise control.

This approach thrives when permissions and operational requirements demand precise control. ABAC’s detailed focus can, with the right rules, strengthen the principle of separation of duties. This principle ensures that no single individual holds excessive control, preventing potential fraud or errors. An example of this would be if Jen could approve system changes and requests but was prohibited from performing the change.

ABAC’s fine-grained control can lead to complications. It requires defining many attributes and understanding their interactions. This demands expertise and without reliable policies and procedures from experienced administrators, crafting correct permissions, auditing and tracing them can be challenging. Despite these issues, ABAC’s granularity allows for customized access control policies to meet specific security needs.

PBAC: Policies to the Center

The third authorization model is Policy-Based Access Control (PBAC), which combines elements of both RBAC and ABAC. PBAC determines access based on predefined policies that incorporate roles (like in RBAC) and attributes (similar to ABAC). Unlike ABAC, where rules are created based on attributes, PBAC involves creating policies that define relevant attributes and roles for decision-making. Access decisions are driven by these policies rather than individual attributes, making it more straightforward.

Research from Nord Security breaks it down into three steps:

1. An access request is made.
2. User attributes are checked against existing policies.
3. If the attributes match the policies, the user is granted access.

Revisiting the IT department example, suppose Jen has established a policy named Email View Policy for Associates. This policy allows Roy and Moss to access their work emails only during work hours and only while on premises. Even though time and location are attributes, these attributes must be written into the policy, and Roy and Moss must meet these conditions to gain access. Jen also created a policy called Compliance Officer Email Policy that describes the specific conditions under which Moss is granted access.

This example leads us into the advantages of PBAC. Administrators can customize and assign policies to users and groups, ensuring appropriate access. In PBAC, policies are explicitly defined, giving administrators full transparency over who has access to what. Any updates must be added to the policy manually. PBAC offers a fine-grained, flexible, and straightforward option. It simplifies the permission process through centralized management, ensuring transparency across an enterprise. Consistent policy enforcement aligned with company needs enhances compliance.

This lunch isn’t free, however. Administrators must create, maintain, and update well-defined policies in PBAC, which can be time-consuming and labor-intensive, especially in dynamic environments requiring frequent updates. Company growth can increase the need for more policies, adding to the management overhead. However, PBAC is ideal for environments needing complex authorization and high compliance. This can include Financial, Health or Educational organizations. PBAC helps companies comply with data handling standards and regulations like HIPAA, GDPR, or PCI DSS. Administrators can create policies based on these requirements, ensuring that access controls meet the necessary security and privacy guidelines.

ReBAC: “Flexibility, Scalability, and Adaptability”

Relationship-Based Access Control (ReBAC) makes authorization decisions based on the relationships between users and resources. ReBAC systems incorporate aspects of RBAC by using roles as one of the components to define relationships. ReBAC is considered a subset of ABAC because relationships are a special type of attribute. Oso’s authorization academy puts it simply: “[The blurred] line between roles and attributes [is] often best described as relationships.”

The core concept of ReBAC is based on its “Policy as a Graph model.” This model consists of nodes and edges: nodes represent key subjects like entities, resources, and users, while edges represent relationships such as member, owner, and contributor. Graphs simplify management by allowing administrators to visualize relationships, manage hierarchical structures, and efficiently trace permissions to their sources, helping to inform policy creation.

Say an IT team is managing a project, which includes various responsibilities. Here’s the breakdown:

Jen (Admin/Owner): As the creator and owner of the Office Network Upgrade Project and the Server Migration Project, Jen has an ownership relationship with these projects, granting her full permissions, including read, write, and delete. Her administrative role within the IT team also allows her to manage access for other members.

Roy (User/Contributor): Roy, a member of the IT team, has a contributor relationship with the Office Network Upgrade Project, giving him read and write access. His permissions are defined by his membership in the IT team and his role as a contributor. He has no relationship, and thus no permissions, with the Server Migration Project.

Moss (Compliance Officer/Collaborator): Moss has a special role within the IT team, extending to both the Office Network Upgrade and Server Migration Projects. As a collaborator, he can read and contribute to the Office Network Upgrade Project and make suggestions on the Server Migration Project due to the sensitive nature of the data.

Below is a graphical representation of a ReBAC model, using the IT Team.

As a graph, you can visualize the intricate relationships that ReBAC uses to determine access. In the image above, the IT Team is represented as a parent node, extending access to child nodes that represent its members. Additional relationships—such as admin, special member, and regular member—are depicted as edges (lines).

Graphs also capture nested relationships, turning complexity into something more manageable. For example, the ‘owner’ relationship can be nested within the ‘Admin’ relationship. ReBAC’s flexibility allows this structure to extend to file-level access within the Office Network Upgrade Project and the Server Migration Project, with permissions inherited and applied automatically. These inheritance features ensure consistent application of permissions–with the help of ReBAC you can trust that this IT team will succeed (especially if Jen is able to install a browser).

ReBAC’s dynamic approach excels in hierarchical relationships, data ownership, groups, and parent-child structures, enabling models that RBAC and ABAC can’t always support. It efficiently handles large data structures, making it versatile in project management, healthcare, social media, and supply chain management. However, ReBAC can be computationally demanding, especially with complex and expanding structures, and monitoring access can be challenging due to its intricate, nested relationships. Despite these challenges, its ability to adapt to evolving relationships makes it invaluable for companies where connections impact permissions. Permissions are determined not only by a person’s role but also by their relationship to a project, team, or authority

Best Practices in Authorization

Integrating access controls into an organization, such as RBAC (Role-Based Access Control), ABAC (Attribute-Based Access Control), PBAC (Policy-Based Access Control), and ReBAC (Relationship-Based Access Control) minimize the potential for unauthorized access. Regardless of the model chosen, integrating authorization is crucial to optimizing the safety, compliance and integrity of a company. Any company responsible for managing assets must ensure their confidentiality, integrity, and accessibility—collectively known as the CIA triad. These three key aspects are imperative for maintaining operational continuity.

The choice of access control model should align with the security needs of the organization, as each model addresses different aspects of security management and compliance. This alignment requires understanding of system requirements, thorough planning, and budgeting. Best practices are best understood within the framework of zero-trust. Grounded in the principle of ‘never trust, always verify,’ zero-trust emphasizes the necessity of authenticating, authorizing, and continuously validating users. Effectively implementing zero-trust not only reinforces core security principles such as the principle of least privilege and separation of duties but also helps maintain a resilient digital system and aligns with compliance demands.

Conclusion

Each access control model–RBAC, ABAC, PBAC, and ReBAC—plays a crucial role in shaping an organization’s security architecture. RBAC is fundamentally role-centric, ABAC introduces flexibility with attribute-based controls, PBAC provides centralized policy management, and ReBAC supports complexity with relationship-based permissions. Collectively, these models offer robust protection against unauthorized access. By adopting these models, organizations can safeguard their critical assets.