RBAC permission model _ dynamic node Java school arrangement, rbacjava

RBAC permission model _ dynamic node Java school arrangement, rbacjava

Permission System and RBAC model Overview

Role-Based Access Control (RBAC.

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

RBAC considers that the process of permission can be abstracted into a process of determining whether the logical expression value of [Who can perform How access operations (Operator)] is True.

Converts the permission issue to Who, What, and How. Who, what, and how constitute three access permissions.

RBAC supports the accepted Security Principles: Minimum privilege principle, responsibility separation principle, and data abstraction principle.

• The principle of least privilege is supported because the RBAC model can limit the number and size of permissions assigned to a role, the permissions assigned to a user's role cannot exceed the user's need to complete the task.
• The responsibility separation principle is implemented because the RBAC model can assign two mutually constrained roles to complete sensitive tasks. For example, when checking accounts, you only need to set the Finance Administrator and accounting roles to participate.
• Data abstraction is implemented by the concept of abstract permission. For example, in an account management activity, abstract permission such as credit and debit can be used, instead of using the read, write, and execute permissions provided by the operating system. However, RBAC does not force these principles to be implemented. The security administrator can configure the RBAC model so that it does not support these principles. Therefore, the degree to which RBAC supports data abstraction is related to the implementation details of the RBAC model.

RBAC96 is a model family, including RBAC0 ~ Four conceptual models of rbac3.

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

2. RBAC1 and RBAC2 both contain RBAC0, but each of them has an independent feature. They are called advanced models.

RBAC1 adds the concept of role hierarchy. A role can inherit permissions from another role.

RBAC2 adds some restrictions, emphasizing some configuration restrictions in different RBAC components.

3. RBAC3 is called a unified model. It contains RBAC1 and RBAC2. RBAC0 is also included in the pass-through model. These models constitute the RBAC96 model family.

RBAC model Overview

RBAC0The model includes three entity sets: user (U), role (R), and permission (P.

The core part of RABC0 permission management. Other versions are based on 0. Let's take a look at the class diagram:

RBAC0 defines the smallest element set that can constitute an RBAC control system.

RBAC contains five basic data elements: User users (USERS), role roles (ROLES), target objects (OBS), Operation operations (OPS), and permission permissions (PRMS, this model specifies the relationship between users, roles, access permissions, and sessions.

Each role must have at least one permission, and each user must assume at least one role. You can assign identical access permissions to two completely different roles. sessions are controlled by users, A user can create a session and activate multiple user roles to obtain the corresponding access permissions. the user can change the activation role in the session, and the user can take the initiative to end a session.

The relationship between a user and a role is many-to-many, 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 assigned to multiple users. For example, a project contains multiple team leaders and multiple team members.

Here, we need to propose that the separation of users and licenses is independent of each other, making the authorization and authentication of permissions more flexible.

Roles and permissions are many-to-many relationships, indicating that a role can have multiple sub-rights. It is easy to understand that a single permission can be granted to multiple roles, in the case of different levels of authority, this model is actually an abstraction of permissions, and it is very easy to understand with life.

RBAC1,Based on the RBAC0 model, the inheritance relationships between roles are introduced, that is, there is a difference between the upper and lower levels of roles. The Inheritance relationships between roles can be divided into general inheritance relationships and restricted inheritance relationships. Generally, only the inherited relationship of a role must be an absolute one.Partial Order relationshipAllows multi-inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure to implement Single inheritance between roles.

This model is suitable for clear layers between roles, including clear.

RBAC2Based on the RBAC0 model, role access control is implemented.

The responsibility separation relationship is added to the RBAC2 model. RBAC2 constraints specify the mandatory rules to be followed when a role is granted or a role is granted to a user and when a user activates a role at a certain time. Separation of duties includes static and dynamic separation of responsibilities. The relationship between constraints and user-role-Permission determines the access permission of users in the RBAC2 model. There are multiple constraints.

• Mutually exclusive role : A single user can only be assigned to one role in a set of mutex roles. The principle of separation of responsibilities is supported. Mutually exclusive roles refer to the two roles with mutual permissions. For such roles, a user can only be assigned one of the roles in a certain activity, and cannot obtain the right to use both roles at the same time. For example, in an audit activity, a role cannot be assigned to both the accounting role and the auditor role.
• Base Constraint : The number of users assigned to a role is limited; the number of roles that a user can own is limited; the number of access permissions for a role should also be limited to control the allocation of advanced permissions in the system. For example, the company's leaders are limited;
• Prerequisite role : You can assign a role to a user only when 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 permission. To obtain higher permissions, you must first have lower-level permissions. Just as in our lives, the president of the country elected from the Vice-Chairman.
• Mutex during running For example, a user is allowed to have two roles, but the two roles cannot be activated simultaneously during running.

RBAC3, That is, the most comprehensive level of permission management, which is based on RBAC0, RBAC1 and RBAC2 are integrated, the first and most complex:

To sum up the introduction of the permission management model, in fact, permission management modules are involved in any system. Regardless of the complexity and simplicity, we can use the RBAC model as the basis, to solve our problems.

Advantages and disadvantages of RBAC

The RBAC model does not provide an operation sequence control mechanism. This defect makes it difficult for RBAC models to apply entity systems that require strict operation orders.

For example, the shopping control system requires the system to control the purchase process and should not allow the customer to take the goods without payment. RBAC model requires that this control mechanism be put into the model

2. Database Modeling of the practical RBAC model

1. Design Scheme for extending RBAC User Role Permissions

Role-Based Access Control (RBAC) is used to associate users with permissions through roles. Simply put, 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, the relationship between users and roles and between roles and permissions is usually many-to-many. (For example)

 

What is a role? It can be understood as a set of a certain number of permissions and the carrier of permissions. For example, in a forum system, "Super administrator" and "moderator" are all roles. The moderator can manage the posts in the version and users in the version. These are permissions. To grant these permissions to a user, you do not need to directly grant the permissions to the user. You can assign the "moderator" role to the user.

When the number of users is very large, it is very cumbersome to authorize (assign roles) each user in the system one by one. In this case, you need to group users. Each user group has multiple users. In addition to user authorization, you can also grant permissions to user groups. In this way, all the permissions of the user are the sum of the permissions of the user's personal permissions and the permissions of the user's user group. (Relationship between user groups, users, and roles)

 

In the application system, what are the permissions displayed? Operations on functional modules, deletion and modification of uploaded files, Menu access, and even visibility control of a button or image on the page can all belong to the scope of permissions. Some permissions are designed to take functional operations as one type, and files, menus, and page elements as the other type, thus forming the "user-role-permission-resource" Authorization Model. When modeling a data table, you can manage both functional operations and resources in a unified manner, that is, directly associate the data table with the permission table, which may be more convenient and scalable. (See)

Please note that the permission table has a column "permission type". We can identify the type of permission based on its values, for example, "MENU" indicates the MENU access permission, "OPERATION" indicates the OPERATION permission of the function module, "FILE" indicates the FILE modification permission, and "ELEMENT" indicates the page ELEMENT visibility control. 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 between them, such as menus. Do you think of them as resources or functional module permissions ?). Second, it is easy to expand. When the system wants to control permissions for new items, I only need to create a new association table "permission XX Association table ", and determine the permission type string for this type of permission.

Note that the permission table and permission menu Association Table, permission menu Association table, and menu table are one-to-one relationships. (File, page permission, and function operations are the same ). That is, each time you add a menu, you have to insert a record to each of the three tables at the same time. In this way, you do not need to associate the permission menu with a table, so that the permission table can be directly associated with the menu table. In this case, you must add a new column in the permission table to save the menu ID, the permission table uses the "permission type" and the ID to identify which record is of the type.

The complete extension model of the RBAC permission model is shown below:

 

As the system grows, to facilitate management, you can introduce role groups to manage roles by category. Different from user groups, role groups do not participate in authorization. For example, in the permission management module of a power grid system, the role is attached to the local authority, where the local authority can be used as a role group and does not participate in permission allocation. In addition, the tree structure, such as the menu tree and function tree, can be used to facilitate the management and search of the above main tables. Of course, these do not need to be involved in permission allocation.

2. models shown in Baidu encyclopedia