1. Introduction

Welcome to Spring Security’s hands-on dry goods series. As of last article, we have been able to achieve simple user principal authentication to the interface access control, but still not meet the actual production needs. If we need a complete permission management system, we must understand the RBAC (role-based Access Control) permission Control model.

2. Why is RBAC needed?

Before we formally discuss the RBAC model, we need to consider the question, why do we do a role permissions system? The obvious answer is that a system must have users with different access rights. For example, if you are a member of QQ Music, you can listen to high-pitched songs. If you are not a member of QQ Music, you cannot enjoy some convenient and high-quality services. So is this set in stone? At other times, in order to increase traffic or generate new demand, we may be able to charge for some services to free users. If you have a membership level then it is more complicated, and the functions of VIP1 and VIP2 must be different again. The mainstream rights management system is the transformation and application of RBAC model, but according to different business and design scheme, present different display effects. The following diagram shows a simple relationship between users and roles and resources:

Why not just assign permissions to users and add roles? Of course, it is not impossible to directly give users specific resource access control rights. It’s just that there’s one less layer of relationship and it’s much less scalable. If your system is simple enough, don’t mess with RBAC, just play with it. RBAC must be considered if your system needs to consider extensibility and diversity of permission controls. If you have multiple users with the same permissions, you will need to repeatedly Query and Add permissions for the user when reassigning permissions. If you want to modify, for example, to Add a Cool function to VIP1, you will need to iterate over the VIP1 user to modify it. After a role is created, you only need to set permissions for the role and assign users with the same permissions to the same role, facilitating rights management. For batch user rights adjustment, you only need to adjust the rights of the role associated with the user without traversal. This greatly improves the efficiency of rights adjustment and reduces the probability of permission omission. This uncoupling of user and resource permissions is the strength of the RBAC model.

3. Classification of RBAC model

RBAC models can be divided into four types: RBAC0, RBAC1, RBAC2 and RBAC3. RBAC0 is the base, and the other three varieties are based on RBAC0. In most cases, the RBAC0 model will suffice for a normal permission management system design. But don’t get stuck in a model. Take business needs as the lead. The following is a brief introduction to the four models.

3.1 RBAC0

RBAC0 is the foundation, which defines the minimum set that can constitute the RBAC permission control system. RBAC0 consists of four parts:

  • User Indicates the User of the permission
  • Roles contain collections of permissions
  • Session is an intermediate channel that binds user and role relationship mapping. And the user must pass the session to set the role for the user.
  • Pemission A specific permission to access a specific resource.

3.2 RBAC1

RBAC1 introduces the concept of role inheritance on the basis of RBAC0. With inheritance, a role has a subordinate or hierarchical relationship. The parent role has all the permissions of its children. Colloquy is to say: if you are capable, your leader must be capable, and vice versa.

3.3 RBAC2

In sports, you cannot be both a player and a referee!

This is a famous saying. It reflects a kind of job (or role) conflict that we often have. Some roles are created for historical reasons to check another role, and referees are created to check players so that they play according to the rules. If a person concurrently holds these two roles, the competition is bound to be prone to injustice and thus violate the rules of fairness. What’s more, each of us will play different roles in different scenarios. In a company, you are an employee of a specific position, and in a family, you are a family member. As the scene changes, so do our characters. Therefore, RBAC2 introduces two constraint concepts of Static Separation of Duty (SSD) and Dynamic Separation of Duty (DSD) on the basis of RBAC0. The life cycles of the two are different;

  • SSDS are used to constrain users and bind roles. 1. Mutually exclusive characters: As in the example above, you can’t be both A and B; mutually exclusive characters can only be one of the two; 2. Quantity constraint: The number of roles of a user is limited and cannot exceed a certain cardinality. 3. Conditional: A role can be played only if a certain condition is met. Often used in the user rating system, only you pay to become a VIP can buy 999.
  • DSD applies to sessions and role interactions. When a user has multiple roles, conditions are imposed when the user activates the role through the session, and different policies are implemented according to different conditions.

I’m not going to draw it because I’m adding these two constraints to RBAC0.

3.4 RBAC3

I want them all!

RBAC1 and RBAC2 each have powers. When you present both proposals to the product manager, he gives you a determined look: I want both! That’s where RBAC3 comes in. So RBAC3 is equal to RBAC1 plus RBAC2.

4. Understanding of some concepts in RBAC

With the four models finished, let’s briefly understand some of the concepts.

4.1 User (User)

The understanding of a User should not be limited to a single User, but can also be a User Group (like a Linux User Group), and perhaps other names such as a department or company. It can also be a virtual account, a customer, or even a third-party application. Therefore, the understanding of users should be broader, as long as the subject with access to resources can be included in the category of users.

4.2 Roles

A role is a collection and carrier of a particular license. A role can contain multiple users, and a user can also belong to multiple roles. A role can contain multiple user groups, and a user group can have multiple roles. Therefore, the relationship between roles and users is many-to-many. Roles can be subdivided, that is, inherited and grouped.

4.3 Permission

Permissions are commonly referred to as permissions. We generally refer to the objects accessed as resources, whether they are data or static resources. We access resources basically through API interfaces. Therefore, common permissions are reflected in the control of interfaces. Further subdivided, I will divide it into menu control, specific data add, delete, change and check function control (reflected in front of the button). In addition, the license is atomic and non-divisible. The smallest unit of granularity is when we grant permission to roles.

5. To summarize

Role-based access control (RBAC) has become one of the main methods of advanced access control. With RBAC, you can control what end users can do at both the broad and subtle levels. You can specify whether users are administrators, expert users, or end users, and align roles and access rights with the positions of employees in the organization. Assign permissions only as needed to give employees enough access to complete their work. Through the introduction of the above I believe that you will gain. For my next Spring Security actual combat dry goods integration RBAC is also a preview. No matter what security framework you use, RBAC is a must. If you have any questions, please leave a comment. You can also contact me at the following public account Felordcn.

Follow our public id: Felordcn for more information

Personal blog: https://felord.cn