RBAC-based permission design-3

1 RBAC model
Resource Access control is a defense against unauthorized use of resources. The basic goal is to restrict the access permissions of the access subject (users, processes, services, etc.) to the Access Object (files, systems, etc.), so that the computer system can be used within the legal scope; determine what a user can do and what a program that represents a certain user interest can do [1].
There are generally three access control policies in the enterprise environment: autonomous access control method, forced access control method, and Role-Based Access Control Method (RBAC ). The autonomy is too weak and the force is too strong. The two have a large workload and are not easy to manage [1]. The role-based access control method is currently recognized as an effective solution to centralized resource access control for large enterprises. The two notable features are: 1. reduce the complexity of authorization management and management overhead; 2. it flexibly supports enterprise security policies and provides great scalability for enterprise changes.
The National Institute of Standards and Technology (NIST) Standard RBAC model consists of four component models, the four component models are the basic model rbac0 (core RBAC), The Role classification model rbac1 (hierarchal RBAC), The Role restriction model rbac2 (constraint RBAC), and the unified model rbac3 (combines RBAC) [1]. Rbac0 Model 1 is shown.
A. 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, permissions are granted to a role rather than a user. When a role is assigned to a user, the user has the permissions contained in the role. Session sessions is the ing between the user and the activated role set. The difference between rbac0 and traditional access control is that adding an indirect layer brings flexibility. rbac1, rbac2, and rbac3 are successively extended on rbac0.
B. rbac1 introduces the inheritance relationships between roles. The Inheritance relationships between roles can be divided into general inheritance relationships and restricted inheritance relationships. Generally, the inheritance relationship only requires that the role inheritance relationship is an absolute partial-order relationship, allowing multi-inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure.
C. 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.
D. rbac3 contains rbac1 and rbac2, which provide both the inheritance relationship between roles and the separation of responsibilities.

2. Core Object Model Design

The core object model of the permission management system is established based on the permission Design Concept of the RBAC model. the object model contains the following basic elements: user (users), user group (group), role (role), target (objects), and access mode) and operator ). The main relationships include: assigning role permissions PA (permission assignment) and assigning user roles UA (users assignmen). The descriptions are as follows:

A. control object: it is the resource to be protected by the system and can be accessed. Pay attention to the following two issues when defining resources:
1. Resources have hierarchical and inclusive relationships. For example, a webpage is a resource, and objects such as buttons and text boxes on a webpage are also resources. It is a subnode of a webpage node. If buttons can be accessed, the webpage must be accessible.
2. The resource concept mentioned here refers to the Resource class, not the instance of a specific resource ). The distinction between resource categories, resource instances, and resource granularity is conducive to determining the management boundaries between the permission management system and the application system, the permission management system needs to manage permissions for resource categories, and the application system needs to manage permissions for instances of specific resources. The distinction between the two is mainly based on the following two considerations:
On the one hand, the permissions of resource instances are often related to resources. That is, the instance permission of a resource can be determined based on the association between the resource instance and the resource access subject. For example, in the management information system, customers in different departments need to be divided according to the business region. Both Zone A and Zone B have the controlled resource of modifying customer information, here, "customer archives" belong to the category of resources. If it is required that only the customer data managed by zone A can be modified, the ownership of the data must be distinguished. The resources here belong to the category of resource instances. Customer archives (resources) should have user information (customer data may contain the business region attribute) in order to differentiate instance operations for specific resources, you can modify the information content under your jurisdiction.
On the other hand, the instance permissions of resources often have considerable business logic relevance. Different business logics often mean completely different permission judgment principles and policies.
B. Permission: access permission for protected resource operations is bound to a specific resource instance. Correspondingly, the access strategy is related to the resource category. Different resource categories may adopt different access modes ). For example, a page has an access mode that can be opened or cannot be opened, a button has an available and unavailable access mode, and a text editing box has an editable and uneditable access mode. Access policies of the same resource may have exclusion and inclusion relationships. For example, the modifiable access mode of a dataset contains the queryable access mode.
C. User: The owner or subject of the permission. Users and permissions are separated and bound through authorization management.
D. User Group: a set of users. In the judgment of business logic, the individual identity or group identity can be used for judgment. The system weakens the concept of user groups and mainly Implements user (personal identity.
E. Role: the unit and carrier of permission allocation. Roles support hierarchical permissions through inheritance relationships. For example, the section chief role also has the section chief role and different business personnel roles in the Section.
F. Operation: bind the resource category and access policy.
G. Assign role permission PA: ing the association between operations and roles.
H. Assign User Role UA: ing between users and roles.

The object model converts the access control model into an Access Matrix. The rows in the Access Matrix correspond to users, and the columns correspond to Operations. Each matrix element specifies the corresponding roles and corresponds to the authorized access permission and implementation behavior of the target. The content of the access capability table Cl (access capabilities) is viewed by rows in the access matrix, and the content of the access control table ACL (access control lists) is viewed by columns in the Access Matrix.
The data model diagram is as follows:

1 RBAC model
Resource Access control is a defense against unauthorized use of resources. The basic goal is to restrict the access permissions of the access subject (users, processes, services, etc.) to the Access Object (files, systems, etc.), so that the computer system can be used within the legal scope; determine what a user can do and what a program that represents a certain user interest can do [1].
There are generally three access control policies in the enterprise environment: autonomous access control method, forced access control method, and Role-Based Access Control Method (RBAC ). The autonomy is too weak and the force is too strong. The two have a large workload and are not easy to manage [1]. The role-based access control method is currently recognized as an effective solution to centralized resource access control for large enterprises. The two notable features are: 1. reduce the complexity of authorization management and management overhead; 2. it flexibly supports enterprise security policies and provides great scalability for enterprise changes.
The National Institute of Standards and Technology (NIST) Standard RBAC model consists of four component models, the four component models are the basic model rbac0 (core RBAC), The Role classification model rbac1 (hierarchal RBAC), The Role restriction model rbac2 (constraint RBAC), and the unified model rbac3 (combines RBAC) [1]. Rbac0 Model 1 is shown.
A. 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, permissions are granted to a role rather than a user. When a role is assigned to a user, the user has the permissions contained in the role. Session sessions is the ing between the user and the activated role set. The difference between rbac0 and traditional access control is that adding an indirect layer brings flexibility. rbac1, rbac2, and rbac3 are successively extended on rbac0.
B. rbac1 introduces the inheritance relationships between roles. The Inheritance relationships between roles can be divided into general inheritance relationships and restricted inheritance relationships. Generally, the inheritance relationship only requires that the role inheritance relationship is an absolute partial-order relationship, allowing multi-inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure.
C. 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.
D. rbac3 contains rbac1 and rbac2, which provide both the inheritance relationship between roles and the separation of responsibilities.

2. Core Object Model Design

The core object model of the permission management system is established based on the permission Design Concept of the RBAC model. the object model contains the following basic elements: user (users), user group (group), role (role), target (objects), and access mode) and operator ). The main relationships include: assigning role permissions PA (permission assignment) and assigning user roles UA (users assignmen). The descriptions are as follows:

A. control object: it is the resource to be protected by the system and can be accessed. Pay attention to the following two issues when defining resources:
1. Resources have hierarchical and inclusive relationships. For example, a webpage is a resource, and objects such as buttons and text boxes on a webpage are also resources. It is a subnode of a webpage node. If buttons can be accessed, the webpage must be accessible.
2. The resource concept mentioned here refers to the Resource class, not the instance of a specific resource ). The distinction between resource categories, resource instances, and resource granularity is conducive to determining the management boundaries between the permission management system and the application system, the permission management system needs to manage permissions for resource categories, and the application system needs to manage permissions for instances of specific resources. The distinction between the two is mainly based on the following two considerations:
On the one hand, the permissions of resource instances are often related to resources. That is, the instance permission of a resource can be determined based on the association between the resource instance and the resource access subject. For example, in the management information system, customers in different departments need to be divided according to the business region. Both Zone A and Zone B have the controlled resource of modifying customer information, here, "customer archives" belong to the category of resources. If it is required that only the customer data managed by zone A can be modified, the ownership of the data must be distinguished. The resources here belong to the category of resource instances. Customer archives (resources) should have user information (customer data may contain the business region attribute) in order to differentiate instance operations for specific resources, you can modify the information content under your jurisdiction.
On the other hand, the instance permissions of resources often have considerable business logic relevance. Different business logics often mean completely different permission judgment principles and policies.
B. Permission: access permission for protected resource operations is bound to a specific resource instance. Correspondingly, the access strategy is related to the resource category. Different resource categories may adopt different access modes ). For example, a page has an access mode that can be opened or cannot be opened, a button has an available and unavailable access mode, and a text editing box has an editable and uneditable access mode. Access policies of the same resource may have exclusion and inclusion relationships. For example, the modifiable access mode of a dataset contains the queryable access mode.
C. User: The owner or subject of the permission. Users and permissions are separated and bound through authorization management.
D. User Group: a set of users. In the judgment of business logic, the individual identity or group identity can be used for judgment. The system weakens the concept of user groups and mainly Implements user (personal identity.
E. Role: the unit and carrier of permission allocation. Roles support hierarchical permissions through inheritance relationships. For example, the section chief role also has the section chief role and different business personnel roles in the Section.
F. Operation: bind the resource category and access policy.
G. Assign role permission PA: ing the association between operations and roles.
H. Assign User Role UA: ing between users and roles.

The object model converts the access control model into an Access Matrix. The rows in the Access Matrix correspond to users, and the columns correspond to Operations. Each matrix element specifies the corresponding roles and corresponds to the authorized access permission and implementation behavior of the target. The content of the access capability table Cl (access capabilities) is viewed by rows in the access matrix, and the content of the access control table ACL (access control lists) is viewed by columns in the Access Matrix.
The data model diagram is as follows: