When we develop a system, we must face the problem of authority control, that is, different users have different access, operation and data authority. The theoretical permission Control models include Discretionary Access Control (DAC), Mandatory Access Control (MAC) and attribute-based permission verification (ABAC). Attribute-based Access Control, etc. One of the most commonly used and relatively easy to use by developers is the RBAC Role-based Access Control (ROLE-Based Access Control) model, which is introduced in this article.

1. Introduction to RBAC authority model

RBAC role-based Access Control (RBAC) is role-based Access Control. There are several key terms in the model:

  • User: The operator of the system interface and access
  • Permission: Permission to access an interface or perform an operation
  • Role: specifies a user with the same operation rights

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

  • What is the role of a user?
  • What permissions does a role have?
  • Derive user permissions from role permissions

Ii. Evolution of RBAC

2.1. Users are directly associated with permissions

When people think of permission control, the first thing that comes to mind must be the mode of direct association between users and permissions. Simply speaking, that is, a user has some permissions. As shown in figure:

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

This model is simple enough to clearly express the relationship between users and permissions. But there are also problems:

  • Now the user is Zhang SAN, Li Si, later with the increase of personnel, each user needs to be re-authorized
  • Or Zhang SAN, Li Si leave, need to carry out a variety of permissions for each user recovery

2.2. A user has a role

In real community services, users can be categorized. For example, for salary management system, usually according to the level of classification: manager, senior engineer, intermediate engineer, junior engineer. That is, users of the same role have the same rights. With this change, you can switch from user-specific to role-specific.

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

We can describe such a relationship using the database design model shown in the figure below.

2.3 One or more Roles for a User

But in the actual application system, one user and one role is far from satisfying the demand. Let’s say we want a user in both a sales role and a temporary VP role. How do you do that? 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 describe such a relationship using the database design model shown in the figure below.

Page access rights and operation rights

  • Page access: all systems are composed of a page, page and then constitute a module, whether the user can see the menu of this page, whether to enter this page is called page access.
  • Operation rights: A user must have operation rights for any action or interaction in the operating system, such as adding, deleting, modifying, and querying. For example: a certain button, a hyperlink whether the user can click, whether should see permissions.

To accommodate this requirement, we can separate page resources (menus) and action resources (buttons), as shown in the figure above. You can also put them in a table with a field to distinguish them.

3. Data permission

Data permissions are better understood as what data a user can access and manipulate.

  • In general, data permissions are determined by the organization to which the user belongs. For example, the first production unit can only look at the production data of its own department, and the second production unit can only look at the production data of its own department. The sales department can only look at the sales data, not the financial data. And the general manager of the company has access to all the data.
  • In real business systems, data permissions are often more complex. It is very likely that the sales department can look at the production department’s data to determine sales strategy, schedule, etc.

Therefore, in order to meet the complex requirements, the control of data permissions is usually restricted by the programmer writing personalized SQL, rather than handing over control to the permissions model or Spring Security or Shiro. Of course, we can also solve this problem from the perspective of authority model or authority framework, but the applicability is limited.

We look forward to your attention

  • I recommend the blogger’s series of documents: “Hand on Hand to teach you to learn SpringBoot Series – Chapter 16, Section 97”.
  • This article is reprinted with a credit (must be accompanied by a link, not only the text) : Antetokounmpo blog.