When we develop a system, we must face the problem of authority control, that is, different users have different access, operation and data permissions. The theoretical models of authority control include: discretionary access control (DAC), mandatory access control (MAC), and ABAC (attribute based access control). The most commonly used and relatively easy-to-use and general-purpose one is RBAC permission model. This article will introduce this permission model to you.

1、 Introduction of RBAC permission model

Role based access control (RBAC) is the role-based access control. There are several key terms in the model:

  • User: operator of system interface and access
  • Or access to an interface
  • Role: the general name of users with the same operation authority

The core authorization logic of RBAC permission model is as follows:

  • What is the role of a user?
  • What permissions does a role have?
  • Deduce the user’s permission from the role’s permission

2、 Evolution of RBAC

2.1. Users are directly associated with permissions

Role based access control model RBAC

When people think of permission control, the first thing people think of must be the mode that users and permissions are directly related to. In short, a certain user has certain permissions. As shown in the figure:

  • Zhang San has the right to create and delete users, so he may be the system maintenance personnel
  • Li Si has the rights of product record management and sales record management, so he may be a sales person

This model can clearly express the relationship between users and permissions, which is simple enough. But there are also problems

  • Now the users are Zhang San and Li Si. In the future, with the increase of personnel, each user needs to be re authorized
  • Or when Zhang San and Li Si quit, they need to reclaim multiple permissions for each user

2.2. A user has a role

Users in the actual community can be classified in the business. For example, the salary management system is usually classified by level: manager, senior engineer, intermediate engineer and junior engineer. In other words, according to a certain role classification, users with the same role usually have the same permissions. After this change, the user empowerment can be converted to the role empowerment.

Role based access control model RBAC

  • A user has a role
  • A role has multiple action (menu) permissions
  • An operation permission can belong to multiple roles

We can use the database design model in the figure below to describe such a relationship.

Role based access control model RBAC

2.3 one or more roles of a user

But in the actual application system, one user and one role can not meet the requirements. If we want a user to play both a sales role and a temporary vice president role. What to do? In order to increase the applicability of system design, we usually design:

  • A user has one or more roles
  • A role contains multiple users
  • A role has multiple permissions
  • A permission belongs to multiple roles

We can use the database design model in the figure below to describe such a relationship.

Role based access control model RBAC

2、 Page access and operation rights

  • Page access rights:All systems are composed of one page, and then the page is composed of modules. Whether the user can see the menu of this page and whether he can enter the page is called page access authority.
  • Operation permission:Any action and interaction of the user in the operating system needs to have operation authority, such as adding, deleting, modifying and checking. For example: a button, a hyperlink, whether users can click, whether they should see the permissions.

Role based access control model RBAC

In order to meet this demand, we can store page resources (menus) and operation resources (buttons) in separate tables, as shown in the figure above. You can also put the two in a table and distinguish them with a field.

3、 Data permission

Data permissions are easy to understand, which data can a user access and operate.

  • In general, data permissions are determined by the organization to which the user belongs. For example, the first production department can only see the production data of its own department, and the second production department can only see the production data of its own department; the sales department can only see the sales data, but not the data of the financial department. And the general manager of the company can see all the data.
  • In the actual business system, data authority is often more complex. It is very likely that the sales department can look at the data of the production department to determine the sales strategy, arrange the plan, etc.

Therefore, in order to face the complex requirements, the control of data permissions is usually limited by the programmer writing personalized SQL, rather than by the authority model or spring security or Shiro. Of course, we can solve this problem from the perspective of permission model or authority framework, but its applicability is limited.

Looking forward to your attention

  • Recommend to you a series of documents of bloggers: “teach you to learn spring boot series by hand – 16 chapters and 97 sections”
  • This article reprints to indicate the source (must take the link, cannot only turn the text): letter brother blog.