MAC, DAC, RBAC, and FGA: A Journey Through Access Control

Identity Access Management (IAM) is a complex field, and it’s easy to get lost in the terminology. Over the years, some key terms have been coined to discuss various strategies and approaches to access control, all of which are interconnected and constantly evolving. In this blog, we will guide you through these terms, mainly DAC, MAC, RBAC, and FGA, from their origin to the present and see how they fit into your application’s access control.

We’ll start our journey with MAC and DAC, two fundamental access-control strategies:

• Mandatory Access Control (MAC) is an access control strategy in which access control decisions are limited directly to software developers or system administrators, ensuring strict, system-level control.
• Discretionary Access Control (MAC) is an access control strategy in which users have direct influence over access control decisions regarding their own data.

Then, we’ll explore how more modern terms to discuss access control have evolved, emphasizing modeling rather than strategy. Namely, RBAC and FGA:

• Role-Based Access Control (RBAC) is an access control model in which permissions are determined based on a user’s role.
• Fine-Grained Authorization (FGA) is a more advanced access control model that considers multiple attributes of users, actions, and resources to make authorization decisions.

Finally, we’ll see how all these terms, MAC and DAC and RBAC and FGA, can be combined together in a way that fits the authorization and access control requirements of modern applications.

Let’s begin!

MAC and DAC - a Brief History

Way before the internet era, when operating systems managed different users and permissions without the need for online collaboration, MAC and DAC became fundamental in defining how users and processes access applications.

Mandatory Access Control (MAC) was traditionally designed for processes and administrative systems. It limits access control decisions to software developers or system administrators, ensuring strict, system-level control. This model was particularly useful in scenarios where security needed to be tightly regulated. In such environments, no user or process could override the predefined access policies set by the system administrators.

Discretionary Access Control (DAC), on the other hand, allows users to have control over their own data. Users can decide who can access their data and what permissions others have. This model became popular with the rise of user-centric applications, such as social networks and Web 2.0, where flexibility and user control over data are essential.

These two approaches, which are still relevant today, have their limits when describing the intricate access control systems required by today's applications. Let’s see why:

Why MAC and DAC Just Aren’t Enough

The strict definitions of MAC and DAC face significant challenges based on the evolving nature of modern Internet applications, data, and user expectations. In short, the abstract nature of these access control strategies only gives a very partial answer to the question of “How and what type of access control should I implement in my application?”.

While the MAC and DAC strategies answer the question of “Who should have the agency of controlling my access control policies?” the importance of which should not be understated, designing the access control of modern applications requires handling new, more complex challenges.

The black-and-white approach of MAC vs. DAC just doesn't work anymore. Applications are distributed across multiple microservices, creating complexities that rigid MAC controls cannot accommodate without harming flexibility and user management. Conversely, DAC's user-defined controls can lead to a chaotic and difficult-to-manage backend. The vast and unpredictable amounts of data generated today challenge both MAC and DAC systems, as predefined policies struggle to account for all data types and interactions, and anticipating usage in DAC becomes nearly impossible. Additionally, while MAC reassures users about data privacy, it can hinder their control, whereas DAC aligns with users' desire for flexibility but risks misconfigured permissions and security breaches.

The need to extend upon the MAC and DAC approach brought about the rise of access control models.

The Rise of Authorization Models - RBAC and FGA

Out of these challenges, evolved a new, more practical way of looking at access control. One that does so through the use of models. These models focus on answering the question, “Who can access what data in our application, based on what, and under what circumstances” - a basic requirement for any modern application, the answer to which we need to be able to audit and maintain.

This need has brought about the integration of access control models, such as Role-Based Access Control (RBAC) and, later on, Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC).

In the next section, we will explain how these models work and, later, their correlation with MAC and DAC.

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is an access control model that simplifies the management of permissions by assigning users to roles based on their responsibilities within an organization. Each role is associated with a set of permissions that define what actions users in that role can perform. This model emphasizes the principle of least privilege by ensuring that users only have the access necessary to perform their duties.

Implementation and Examples:

RBAC is widely used in applications where users and the actions they should be allowed to perform can be separated into roles. It’s easy to understand RBAC by looking at a table of permissions corresponding to different roles within an application.

Take an e-commerce platform for instance. The rules here might define distinct roles like 'Customer,' 'Sales Manager,' and 'System Administrator,' each with varying levels of access. A 'Customer' may only view and purchase products, whereas a 'Sales Manager' could have access to sales data and inventory management tools. The 'System Administrator' role, on the other hand, would have broad permissions, including the ability to modify user roles and access rights.

If we break it down:

• Customer: Can view products and make purchases.
• Sales Manager: Can view and edit product listings, access sales reports, and manage customer orders.
• System Administrator: Has full access, including user management, system settings, and access to all data.

Visual representation of an RBAC policy in Permit.io’s dashboard

Strengths and Limitations:

Strengths:

• Simplifies Management: By grouping users into roles, RBAC reduces the complexity of managing individual permissions.
• Enhances Security: Ensures users have only the permissions they need based on pre-defined roles, minimizing the risk of unauthorized access.
• Scalability: As there is no need to manage access policies for each individual user, RBAC is much more suitable for large organizations with many users and roles.

Limitations:

• Role Explosion: RBAC's scalability has its limitations. While more scalable than older counterparts, RBAC can still result in a “Role Explosion” when a separate role is created for every use case lacking appropriate alternatives.
• Static Roles: RBAC may not be flexible enough to handle dynamic access needs without frequent updates to roles and permissions.

When is RBAC Wasn’t Enough

As simple and straightforward as RBAC might be, its simplicity comes with a price. Most modern applications have evolved beyond simple roles. RBAC’s focus on roles means that the user is the only dynamic component of our access control policy. When it comes to attributes and relationships, RBAC just doesn’t cut it anymore. Consequently, more granular access models have emerged - that’s where FGA comes in.

Fine-Grained Authorization (FGA)

Fine-Grained Authorization (FGA) is an advanced access control model that provides detailed and precise control over what users can do within an application. Unlike RBAC, FGA considers multiple attributes of users, actions, and resources to make authorization decisions. This model enables a nuanced approach, ensuring that access is granted based on specific conditions and contexts.

Relationship-Based vs. Condition-Based Authorization:

FGA can be implemented using two primary approaches: relationship-based and condition-based authorization. Relationship-based (ReBAC) authorization defines access rules based on the connections between users and resources. For instance, if a user owns a project, they might have implicit permission to edit all documents within that project.

Condition-based authorization, also known as Attribute-Based Access Control (ABAC), uses attributes of subjects, actions, and resources to create dynamic rules. For example, a policy might state that a manager can approve expense reports only if the amount is below $5,000.

Implementation and Examples:

FGA is implemented by defining policies that consider specific attributes of users, actions, and resources. Let’s look at a simple ABAC scenario:

Say we want to define the following policy -

Employees based within the European Union can Edit Documents that are GDPR Protected.

In this example:

• “Employee” is a Role
• The location of the employee in the European Union is a User Attribute
• “Edit” is an Action
• “Document” is a Resource
• “GDPR Protected” is a Resource Attribute

Here's what such a policy would look like, represented in a table:

ABAC’s use of attributes allows the creation of very fine-grained authorization policies. Common attributes include (but are not limited to) Time, Location, Billing Status, and many more—all depending on your application's specific needs.

Strengths and Limitations:

Strengths:

• Increased Precision: Allows for detailed control over user actions and resources, reducing the risk of unauthorized access.
• Flexibility: Adapts to changing business requirements and complex scenarios, making it easier to implement dynamic access policies.
• Enhanced Security: Detailed access control minimizes the chances of over-privileged users, enhancing overall security.

Limitations:

• Complexity: Managing and implementing fine-grained policies can be complex and may require appropriate tools and interfaces.
• Performance Impact: Detailed authorization checks can impact performance, especially in large-scale applications.

FGA’s nuanced approach to access control makes it a powerful solution for modern applications that require dynamic and context-aware authorization. In this context, Permit.io was created to allow developers to take advantage of both RBAC and FGA without having to build this layer from scratch, providing infrastructure, backoffice tools, and pre-built interfaces to streamline the implementation process.

RBAC vs. FGA

Combining Models and Strategies

While examining access control exclusively through the prism of MAC and DAC is no longer sufficient, that doesn’t mean the concept itself is irrelevant. MAC and DAC strategies aren’t mutually exclusive from modern policy models such as RBAC and FGA, and the two can be combined to suit your application's access control needs. Here’s how:

DAC and RBAC

When RBAC is combined with DAC, users have more flexibility. An admin user can assign roles to other users, and users can create new roles and define specific actions that users with those roles can perform, allowing for a more dynamic and user-driven approach to access control.

MAC and RBAC

Conversely, with RBAC and MAC, the application developer or system administrator defines all policies and assigns roles in advance, ensuring strict control over user access. Users cannot assign roles to themselves, and all data in the application follows the same strict access levels. Developers are responsible for managing permissions for every user and action.

Similarly, Fine-Grained Authorization (FGA) can also be integrated with both MAC and DAC.

DAC and FGA

Under DAC, users manage permissions at a granular level, allowing for personalized and flexible access control.

MAC and FGA

In a MAC context, developers define detailed permissions based on user attributes and conditions, maintaining strict control.

At the end of the day, authorization models and strategies are more thinking tools than concrete guidelines, and most applications end up mixing between them (especially as time passes and the applications evolve). The most important thing is how you implement them so that they're flexible, scalable, and continue to evolve along with your application's needs.

Combining MAC and DAC:

As far as MAC and DAC go, the most effective way is to integrate both models into different parts of your application:

• Use MAC to enforce strict access control for critical application components where security is non-negotiable. This includes database access, inter-service communication, and other backend operations where precise control is essential.
• Implement DAC in areas where user flexibility and control are key. This includes front-end interactions, user-generated content, and any features that require users to manage their own permissions and data-sharing preferences.

DAC, MAC, RBAC, and FGA in Modern Access Control

Understanding the foundational concepts of MAC and DAC is crucial to navigating the intricate field of identity access management (IAM), but modern applications require more nuanced approaches. While the rigid, binary nature of MAC and DAC strategies is still relevant, it falls short in addressing the dynamic and complex requirements of today's applications. This gap is bridged by looking at access control through the prism of models like Role-Based Access Control (RBAC) and Fine-Grained Authorization (FGA), which offer greater flexibility, precision, and adaptability.

RBAC's structured approach simplifies permission management through predefined roles, yet its limitations become apparent in more complex scenarios where the need for dynamic and context-aware access controls arises. That’s where FGA comes in, providing the granularity needed to cater to specific conditions and relationships, thereby enhancing security and user experience.

Combining these models and strategies allows for a more tailored approach to access control. By integrating the principles of MAC and DAC with RBAC and FGA, you can create access control systems fit for modern applications, balancing strict control with user flexibility. This hybrid approach ensures that as applications grow and evolve, their access control mechanisms remain scalable, secure, and adaptable to new challenges.

DAC, MAC, RBAC, FGA and Permit.io

Ultimately, the key to effective IAM lies in the thoughtful implementation of these models and strategies. By leveraging each model's strengths and mitigating its weaknesses, you can develop an access control system that not only meets current needs but also scales with the ongoing evolution of your applications.

Permit.io provides a framework for implementing FGA by offering a centralized control panel, SDKs, APIs, and microservices for authorization, as well as no-code interfaces and pre-built UI components that allow you to take full advantage of these models and strategies.

Want to learn more about Authorization and Permit? Join our Slack community, where there are hundreds of devs building and implementing authorization.