Shulou(Shulou.com)05/31 Report--

Editor to share with you the example analysis of the RBAC permission model, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Overview of privilege system and RBAC Model

RBAC (Role-Based Access Control) role-based access control.

During the 1990s, a large number of experts and scholars and specialized research units conducted in-depth research on the concept of RBAC, and successively put forward many types of RBAC models, among which the RBAC96 model proposed by the Information Security Technology Laboratory (LIST) of George Mason University in the United States is the most systematic and widely recognized.

RBAC believes that the process of permissions can be abstracted as the process of determining whether [Who can access What with How (Operator)] whether the value of this logical expression is the solving process of True.

Convert permission issues to Who, What, and How issues. Who, what, and how constitute a triple of access rights.

RBAC supports accepted security principles: the principle of least privilege, the principle of separation of responsibilities and the principle of data abstraction.

The least privilege principle is supported because it can be achieved in the RBAC model by limiting the number and size of permissions assigned to roles, as long as the permissions assigned to the roles corresponding to a user do not exceed the user's need to complete their tasks.

The principle of separation of responsibilities is realized because in the RBAC model, it can be realized by assigning two roles that restrict each other in the process of accomplishing sensitive tasks, for example, when checking accounts, only two roles, financial administrator and accountant, need to be set up to participate.

Data abstraction is realized with the help of concepts such as abstract permissions, such as credit and debit rights in account management activities, instead of using specific permissions such as reading, writing and execution provided by the operating system. However, RBAC does not force the implementation of these principles, and security administrators can allow the RBAC model to be configured so that it does not support them. Therefore, the extent to which RBAC supports data abstraction is related to the implementation details of the RBAC model.

RBAC96 is a family of models that includes four conceptual models of RBAC0~RBAC3.

1. The basic model RBAC0 defines the minimum requirements for any system that fully supports the concept of RBAC.

2. Both RBAC1 and RBAC2 contain RBAC0, but both add independent features. They are called high-level models.

The concept of role hierarchy has been added to RBAC1, where one role can inherit permissions from another.

Some restrictions have been added to RBAC2, highlighting some of the configuration limitations in different components of RBAC.

3. RBAC3 is called the unified model, which includes RBAC1 and RBAC2. Using transitivity, RBAC0 is also included. These models make up the RBAC96 model family.

A brief introduction of RBAC Model

The model of RBAC0 includes three types of entity sets: user (U), role (R) and permission (P).

The core part of RABC0 rights management, other versions are based on 0, take a look at the class diagram:

RBAC0 defines the smallest set of elements that can make up a RBAC control system.

In RBAC, there are five basic data elements: user users (USERS), role roles (ROLES), target objects (OBS), operation operations (OPS) and permission permissions (PRMS). This model indicates the relationship among users, roles, access rights and sessions.

Each role has at least one permission, and each user plays at least one role; two completely different roles can be assigned exactly the same access rights; the session is controlled by the user, and a user can create a session and activate multiple user roles to obtain the corresponding access rights, the user can change the active role in the session, and the user can actively end a session.

There is a many-to-many relationship between users and roles, indicating that a user can have different roles in different scenarios.

For example, a project manager can also be a project architect; of course, a role can be given to multiple users, such as multiple team leaders and team members in a project.

What needs to be pointed out here is that the separation of users and licenses is independent of each other, which makes the authorization and authentication of permissions more flexible.

Role and permission (authority) is a many-to-many relationship, indicating that a role can have multiple rights, and it is very easy to understand that the same right can be granted to multiple roles. Think about the situation of different levels of authority as an official in real life. In fact, this model is an abstraction of authority, and it is very easy to contact life understanding.

RBAC1, based on the RBAC0 model, introduces the inheritance relationship between roles, that is, there is a difference between superior and subordinate roles, and the inheritance relationship between roles can be divided into general inheritance relationship and restricted inheritance relationship. The general inheritance relationship only requires that the role inheritance relationship is an absolute partial order relationship, which allows multiple inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure to realize the single inheritance between roles.

This model is suitable for a clear hierarchy and inclusion between roles.

RBAC2, based on the RBAC0 model, carries on the role access control.

The separation of responsibilities is added to the RBAC2 model. The constraints of RBAC2 specify the mandatory rules that should be followed when permissions are assigned to roles, or when roles are given to users, and when users activate a role at a certain time. The separation of responsibility includes static separation of responsibility and dynamic separation of responsibility. Together with the user-role-permission relationship, constraints determine the access permission of users in the RBAC2 model. There are many kinds of constraints.

Mutually exclusive roles: the same user can only be assigned to at most one role in a set of mutually exclusive roles, supporting the principle of separation of responsibilities. Mutually exclusive roles refer to two roles whose respective permissions restrict each other. For this kind of role, a user can only be assigned one of the roles in an activity, and can not get the right to use both roles at the same time. A common example: in an audit activity, a role cannot be assigned to both the accountant role and the auditor role.

Cardinality constraints: the number of users assigned to a role is limited; the number of roles a user can have is limited; and the number of access rights corresponding to a role should also be limited to control the allocation of advanced permissions in the system. For example, the leaders of the company are limited.

Prerequisite role: a role can be assigned to a user only if the user is already a member of another role; the corresponding access permission can be assigned to the role only if the role already has another access right. It means that if you want to get higher permissions, you must first have lower permissions. Just like in our lives, the president is elected from among the vice-presidents.

Runtime mutual exclusion: for example, a user is allowed to have membership of two roles, but both roles cannot be activated at run time.

RBAC3, the most comprehensive level of rights management, is based on RBAC0 and integrates RBAC1 and RBAC2, the foremost and most complex:

To sum up, the relevant introduction of the rights management model, in fact, in any system will involve the rights management module, whether complex or simple, we can solve our problems through flexible application based on the RBAC model.

Advantages and disadvantages of RBAC

The RBAC model does not provide a mechanism for controlling the order of operations. This defect makes it difficult for the RBAC model to apply to entity systems that require strict operation order.

For example, in the shopping control system, the system is required to control the purchase steps, and the customer should not be allowed to take the goods away before he has paid. The RBAC model requires that this control mechanism be put into the model.

two。 Database Modeling of practical RBAC Model

1. Design scheme for extending RBAC user role permissions.

RBAC (Role-Based Access Control, role-based access control) is that users are associated with permissions through roles. To put it simply, a user has several roles, and each role has several permissions. In this way, the authorization model of "user-role-permission" is constructed. In this model, there is generally a many-to-many relationship between users and roles and between roles and permissions. (as shown below)

What's the role? It can be understood as a collection of a certain number of permissions, the carrier of permissions. For example: a forum system, "Super Admin", "moderator" are roles. Moderators can manage posts within the version, users within the manageable version, and so on. These are permissions. To grant these permissions to a user, you do not need to grant permissions directly to the user, you can assign the role of moderator to that user.

When the number of users is very large, it is very cumbersome to authorize each user of the system one by one. At this point, you need to group users, and there are multiple users in each user group. In addition to authorizing users, you can also authorize user groups. In this way, all the permissions a user has is the sum of the permissions that the user has and the permissions that the user belongs to. (the following figure shows the relationship among user groups, users and roles)

What is the expression of permissions in the application system? The operation of the functional module, the deletion and modification of the uploaded file, the access to the menu, and even the visibility control of a button or picture on the page can all belong to the scope of permissions. Some permission designs take functional operations as one category and files, menus, page elements, etc., as another category, thus forming a "user-role-permission-resource" authorization model. When modeling the datasheet, the functional operations and resources can be managed uniformly, that is, they can be directly associated with the permission table, which may be more convenient and scalable. (see figure below)

Please note that there is a column of "permission type" in the permission table, and we distinguish which kind of permission according to its value, such as "MENU" represents the access permission of the menu, "OPERATION" represents the operation permission of the functional module, "FILE" represents the permission to modify the file, "ELEMENT" represents the visibility control of page elements, and so on. There are two advantages of this design. First, there is no need to distinguish between permission operations and resources. (in fact, it is sometimes difficult to distinguish, such as menus, as resources or functional module permissions. ). Second, it is easy to expand. When the system wants to control the permissions of something new, I just need to establish a new association table, "permissions XX Association Table", and determine the permission type string of this kind of permissions.

It should be noted here that there is an one-to-one relationship between the permission table and the permission menu association table, and between the permission menu association table and the menu table. (files, page limit points, functional operations, and so on). That is, for each menu you add, you have to insert a record into each of the three tables at the same time. In this way, there is no need for the permission menu association table, and the permission table can be directly associated with the menu table. At this time, a new column of ID used to save the menu must be added in the permission table. The permission table distinguishes which record under this type by "permission type" and this ID.

At this point, the complete design diagram of the extended model of the RBAC permission model is as follows:

With the increasing size of the system, in order to facilitate management, role groups can be introduced to classify and manage roles. Unlike user groups, role groups do not participate in authorization. For example, in the authority management module of a power grid system, the role is hung under the regional bureau, and the regional bureau can be regarded as a role group here, it does not participate in the allocation of permissions. In addition, in order to facilitate the management and search of the above main tables, we can use tree structure, such as menu tree, function tree, etc., of course, these do not need to participate in permission allocation.

2. The model shown in Baidu encyclopedia.

The above is all the content of this article "sample Analysis of RBAC permission Model". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.