Shulou(Shulou.com)06/01 Report--

This article focuses on "role-based access control model RBAC instance analysis", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Now let the editor to take you to learn "role-based access control model RBAC instance analysis"!

1. Brief introduction of RBAC permission model

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

User: operator of system interface and access

Permission: the authorization to access an interface or to do an operation

Role: a general term for a user with the same type of operation permissions

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 the user's permissions from the permissions of the role

Second, the evolution process of RBAC is 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 in which users are directly associated with permissions, which is simply: a user has certain permissions. As shown in the figure:

Zhang San has the authority to create and delete users, so he may have system maintenance personnel.

Li Si has the authority of product record management and sales record management, so he may be a business salesperson.

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 if Zhang San or Li Si quit, they need to reclaim multiple permissions for each user.

2.2. A user has a role

In the actual group business, users can be classified. For example, for salary management systems, they are usually classified by level: manager, senior engineer, intermediate engineer, junior engineer. That is, according to a certain role classification, usually users with the same role have the same permissions. After this change, user-specific empowerment can be converted to role-specific empowerment.

A user has a role

A role has multiple action (menu) permissions

One operation permission can belong to multiple roles

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

2.3 one or more roles per user

However, in the actual application system, one user and one role is far from meeting the needs. If we want a user to play both a sales role and a temporary vice president role. What should I 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

One permission belongs to multiple roles

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

III. Page access and operation permissions

Page access: all systems are composed of pages, and the pages are composed of modules. Whether users can see the menu of this page and whether they can enter this page is called page access rights.

Operation authority: any action or interaction in the operating system requires operation rights, such as additions, deletions, modifications, queries, etc. For example: a button, whether a hyperlink user can click, whether it should see the permission.

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

IV. Data permissions

Data permissions are easy to understand, that is, what data a user can access and manipulate.

Typically, 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 department can only look at the production data of its own department; the sales department can only look at the sales data, not the data of the financial department. The general manager of the company can look at all the data.

In actual business systems, data permissions are 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, plan, and so on.

Therefore, in order to face the complex requirements, the control of data permissions is usually written by programmers to limit the scope of data by personalized SQL, rather than by the permission model or Spring Security or shiro. Of course, this problem can also be solved from the perspective of permission model or permission framework, but the applicability is limited.

At this point, I believe you have a deeper understanding of "role-based access control model RBAC instance analysis". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.