E-commerce Subject: RBAC permission Control

@ Zheng yu Summary Glossary: RBAC: Role-Based Access Control, Role-Based Access Control   Keywords: RBAC, Java Shiro, spring security, 1. Common Problems to be Solved by RBAC Question 1: Only some special permissions are granted to a user. Description: you do not want to expand the permissions of a role or create many fragmented roles that only exist for one user. Question 2: Performance problems Description: menus, pages, page elements, and dataset columns under B/S. These layers of permission judgment are too complex and easy to cause slow system access. Question 3: How to Reduce hardcode) Description: Question 4: After the system goes online, a new HTML control or dataset is added to a page. How can this fine-grained permission control be added as quickly as possible? Description: How to quickly add definitions for a resource's privilege? How to quickly assign permissions? How to Control pages? Question 5: After the system is launched, a new fine-grained permission control is added. How can the Operation Department quickly apply it to existing roles and accounts? Description: How can the administrator of an operation department assign this permission to hundreds of roles, thousands of accounts, or even countless user groups in the system at the minimum cost through the interface. 2. Design Principle of cutting between Permission Logic and business logic . Fine-grained permission system scope Two concepts are explained first:

• Coarse granularity: Indicates the category level. That is, only the object category is taken into account, not a specific instance of the object. For example, in user management, add, delete, modify, and query operations are treated equally to all users without distinguishing specific object instances for operations.
• Fine Granularity: Indicates the instance level. That is, you need to consider the instance of a specific object. Of course, the fine granularity is to consider the specific instance only after considering the coarse granularity object category. For example, to list and delete a contract, you must determine whether the contract instance is created by the current user.

The permission logic works with the business logic. For example, the demand side provides a scenario: "A contract resource can only be deleted by its creator, users in the same group as the creator can modify it, and all users can browse it ." It can be considered as a fine-grained permission issue or a business logic issue. . If you think this is a business logic problem, you do not need to consider this scenario too much when designing a permission system. Of course, the permission system must also support such control judgment, or the permission system provides sufficient but not full control capabilities. At this time, the design principle is:" The system only provides coarse-grained permissions. fine-grained permissions are considered to be the responsibility of business logic. ". This is also a simple idea for complex problems. These fine-grained permissions for specific resource instances are left to the business logic to solve. These considerations are based on the following two points:

1. Fine-grained permission judgment can be achieved only by modeling the support information for permission allocation on resources. In this way, the owner concept is introduced.

• For example, if the creator and the common user are required to see different information content, the resource itself should have the information of its creator. Every file (Resource) in UNIX defines different operation attributes for owner, group, and all.

Fine-grained permissions often have considerable business logic relevance.

• Different business logics often mean completely different permission judgment principles and policies.In contrast, coarse-grained permissions are more universal and can be implemented as an architecture with more reuse value.The implementation of fine-grained permission judgment as an architecture level is cumbersome and not so necessary.CodeIt is more concise and flexible.

Of course, Zheng Yu said that permission systems cannot be universally used and must be case-based. Therefore, during design, the permission system still takes care of both coarse granularity and fine granularity. Here is a one-size-fits-all idea. . Does the column permission of the dataset count as the permission system category?

If a dataset is to be displayed on the page, do you need to put the display, readable, and writable control of certain columns in the permission system?

The answer is: In order to simplify and avoid excessive intrusion into the business logic, column permissions are not within the permission system scope. Iii. What is RBAC? RBAC The permission authorization is actually Who , What , How Can be simply expressed: Determine whether the logical expression "who performs how operations on what (which)" is true . RBAC involves the following concepts:

• Who: The owner or subject of the permission (for exampleUser,Group,Role);
• What: Target object or resource (Resource,Class);
• How: Specific permissions (Privilege).
• Forward authorization assumes that the subject does not have any permissions at the beginning, and then grants permissions as needed, suitable for systems with strict permission requirements.
• Negative authorization assumes that the subject has all permissions at the beginning, and then revokes some special permissions.
• Operator: Operation. IndicatesWhatOfHowOperation.
• That isPrivilege + resource;
• Note that the resource here only includes the resource type and does not represent the resource instance;
• The reason why we bind what and how together as an operator concept, instead of separately modeling and then establishing association, is because a lot of how makes sense for a specific thing. For example, publishing is meaningful to news objects and meaningless to user objects.
• Role: Role, a set of a certain number of permissions. The unit and carrier of permission allocation, with the aim of isolationUserAndPrivilege;
• Group: User group, unit and carrier of permission allocation. Permissions are assigned to the Group Regardless of specific users. A group can contain groups.(To Inherit Permissions)And can also contain the permissions of users in the group that inherit the group.UserAndGroupIs a many-to-many relationship.GroupIt can be hierarchical to meet the requirements of permission control at different levels.
• Session: A session is a ing between a user and an activated role set. Each session is associated with a single user. Each user can be associated with one or more sessions.

RBACThree Security principles are supported:

1. Minimum permission principle (fine-grained Control Principle ):

• RBACYou can configure its role as the minimum permission set required to complete the task;

Separation of Responsibility Principle

• Calls mutually independent and mutually exclusive roles to jointly complete sensitive tasks. For example, a clerk and the financial administrator are required to participate in the same posting;

Data abstraction principles

• Permission abstraction is used to reflect abstract permissions, such as borrowing and deposit for financial operations.

  Iv. Standard RBAC model NIST (US National Institute of Standards and Technology) StandardsRBACModel4Component models, which are basic modelsRbac0(Core RBAC), Role classification modelRbac1(Hierarchal RBAC), Role restriction ModelRbac2(Constraint RBAC) And Unified ModelRbac3(Combines RBAC). Rbac0Model1As shown in:

Figure 1 RBAC 0 Model

Rbac0 defines the smallest element set that can constitute an RBAC control system:

• RBAC defines five basic data elements:

1. User Users (users)
2. Role roles (roles)
3. Target objects (OBS)
4. Operations (OPS)
5. Permission permissions (PRMS)

Rbac0 business rules include:

• One user can correspond to multiple roles, and one role can also be assigned to multiple users;
• One role can have multiple permissions, and one permission can only correspond to one role;
• You can initiate a session and activate multiple roles in the session to obtain the permission;
• Users, roles, and permissions are all created and assigned by the super administrator;
• When a user has multiple roles, the higher-priority role permissions cover the lower-priority role permissions.

Rbac1 (introducing the role inheritance relationship), rbac2 (introducing the responsibility separation relationship), and rbac3 (role inheritance + responsibility separation) are all successively extended on rbac0. V. RBAC core Object Model Authorization Model: user-role-Permission Core Action:

• Create Permissions
• Assign Permissions
• Permission

Main participants of core actions:

• Creator creates Permissions: The object declaration of privilege and resource is completed here;
• Administrator assigns Permissions: Actually associates privilege with resource instance, and generates the operator (privilege instance ). The Administrator uses operator as a basic element to create an ideal permission model, such as creating roles, user groups, assigning users to user groups, and associating user groups with roles;
• User permission

References:

1) iteye editing summary, permission control discussion; 2) permission management system design and implementation based on RBAC model 3) jackyz @ jdon, 2002, permission system design