1. What is the RBAC model?

RBAC is the abbreviation of Role-Based Access Control, which means: role-based permission control. Associating users with roles, and indirectly granting user permissions by associating roles with permissions.

As shown below:

Why not directly assign permissions to users and add roles as a unnecessary step?

In fact, it is possible to directly assign permissions to users, but by directly assigning permissions to users, there is one less layer of relationship, and the scalability is much weaker. It is suitable for platforms with a small number of users and a small number of role types.

For ordinary systems, for example, if there are multiple users with the same permissions, the same permissions must be specified for these users when assigning, and the permissions of these users must be modified one by one when modifying. After having the role, we only need to set the permissions for the role and assign users with the same permissions to the same role to facilitate permission management.

For batch user permission adjustments, only the role permissions associated with the user need to be adjusted, without the need to adjust permissions for each user. This not only greatly improves the efficiency of permission adjustment, but also reduces the probability of missing permission adjustments.

2. Classification of RBAC models

RBAC models can be divided into four types: RBAC0, RBAC1, RBAC2, and RBAC3 . Among them, RBAC0 is the foundation and the simplest, equivalent to the underlying logic. RBAC1, RBAC2, and RBAC3 are all upgrades based on RBAC0.

Under normal circumstances, the use of the RBAC0 model can meet the design of conventional rights management systems.

2.1 RBAC0 model

The simplest user, role, and permission model. This includes 2 more types:

There is a many-to-one relationship between users and roles, that is, one user can only play one role, and one role can be played by multiple users.

There is a many-to-many relationship between users and roles, that is, one user can play multiple roles at the same time, and one role can be played by multiple users.

So, when should we use a many-to-one permission system, and when should we use a many-to-many permission system?

If the system function is relatively single, there are few users, the position permissions are relatively clear and it is ensured that there will be no concurrent posts, then you can consider using a many-to-one permission system. In other cases, try to use a many-to-many permission system to ensure the scalability of the system. For example: Zhang San is both administrative and financial. Then Zhang San has the authority of both administrative and financial roles.

2.2 RBAC1 model

Compared with the RBAC0 model, sub-roles are added and the concept of inheritance is introduced, that is, sub-roles can inherit all permissions of the parent role.

Usage scenario: For example, a business department has managers, supervisors, and specialists. The supervisor's authority cannot be greater than that of the manager, and the specialist's authority cannot be greater than that of the supervisor. If the RBAC0 model is used as a authority system, errors in allocating authority will most likely occur, and eventually the supervisor will have authority that even the manager does not have.

The RBAC1 model solves this problem very well. After the manager role is created and the permissions are configured, the permissions of the supervisor role inherit the permissions of the manager role, and it supports deleting supervisor permissions from the manager permissions.

2.3 RBAC2 model

Based on the RBAC0 model, some restrictions on roles are added : role mutual exclusion, cardinality constraints, prerequisite roles, etc.

Mutually exclusive roles: The same user cannot be assigned to multiple roles in a set of mutually exclusive roles. Mutually exclusive roles refer to two roles whose permissions restrict each other. Case: A user in the financial system cannot be assigned to the accounting role and the auditor role at the same time.

Cardinality constraint: The number of users assigned to a role is limited, which refers to how many users can have this role. For example: if a role is created specifically for the CEO of a company, then the number of this role is limited.

Prerequisite role: In order to obtain higher permissions, you must first have lower-level permissions. For example: you must first have deputy general manager authority before you can have general manager authority.

Runtime mutual exclusion: For example, a user is allowed to have membership in two roles, but not both roles can be activated simultaneously at runtime.

2.4 RBAC3 model

Called the unified model, it includes RBAC1 and RBAC2, and uses transitivity to also include RBAC0, integrating all the characteristics of RBAC0, RBAC1, and RBAC2.

Here is a brief description based on my opinions.

RBAC0: It is the core idea of RBAC.

RBAC1: It is a hierarchical model of the role of RBAC.

RBAC2: Added RBAC constraint model.

RBAC3: Actually RBAC2 + RBAC1.

3. How to use the RBAC model to design the permission system?

We already know what the RBAC model is. Before analyzing how to design a permission system based on this model, let's break down the elements of this model.

The first is: users, roles, permissions .

Permissions, specific to a certain software, actually include two aspects. One is the menu permission and the other is the data permission.

Different industries will have different usage scenarios, and the user role permission model will also change to varying degrees.

You can take a look at this article for related data table design: Designing a Permission System-RBAC - Jianshu (jianshu.com)

4. Take a look at ABAC and imagine the future permission model

At this point, we can understand that the RBAC model can actually solve most permission design problems.

So, what exactly is ABAC? What is the meaning of its existence? What inspiration can it give us about future permission design trends?

With these questions, let's first take a look at what exactly the ABAC model is.

ABAC, Attribute-based Access Control. Attribute-based access control. Generally speaking, there are three categories of attributes: user attributes, system or application accessed attributes (data and operations), and environment attributes.

In other words, the system dynamically controls who can access which functional data and operations based on whether one or more sets of attributes meet preset rules. The RBAC model can actually be regarded as a static, single-set attribute ABAC model.

An example to understand this model is: Only when the user role is Admin, during working hours, and in Laboratory B of Building C, can the D file be accessed.

In fact, ABAC is a model that can manage permissions at the finest granularity . It allows designers to use any user attribute, environment attribute, or the intersection or union of multiple attributes to combine dynamic permission judgment logic.

ABAC’s solution to access control in complex scenarios.

The difference between RBAC and ABAC

The main difference between RBAC and ABAC is the way access is granted to methods. RBAC grants access permissions based on roles, and ABAC can determine access permissions based on user characteristics, object characteristics, operation types and other attributes.

RBAC advantages and disadvantages:

advantage:

The RBAC model is simpler to build. For small and medium-sized organizations, the workload of maintaining roles and authorization relationships is not large. On the contrary, it is relatively troublesome to customize various policies, making it easier to accept the RBAC authorization model.

shortcoming:

For large organizations, the RBCA-based control model needs to maintain a large number of roles and authorization relationships, and cannot achieve fine-grained authorization of resources.

ABAC advantages and disadvantages:

advantage:

For large organizations, a control model based on RBCA needs to maintain a large number of roles and authorization relationships. In comparison, ABAC is more flexible.
When adding new resources, ABAC only needs to maintain fewer resources, while RBAC needs to maintain all related roles. ABAC is more scalable and more convenient.
ABAC has more fine-grained control and dynamic execution based on context, while RBAC can only make judgments based on static parameters.

shortcoming