A robot extensible permission management method based on an intra-domain role access control model

Abstract

The application provides a robot extensible permission management method based on a domain role access control model, comprising the following steps: S1, defining basic attributes of a first-level entity; S2, defining basic attributes required by a second-level entity as a sovereign entity; S3, defining basic attributes required by a third-level entity as a resource entity; S4, defining a sovereign object, an authorized object, an authorized permission value and a tenant as columns of a sovereign entity permission table; S5, defining a sovereign object successor, a sovereign object and a tenant as columns of a sovereign entity inheritance relationship table; S6, defining a relationship between the second-level entity and the third-level entity according to requirements; and S7, loading all valid data of the sovereign entity permission table and the sovereign entity inheritance relationship table into the memory in the form of a key-value pair set when the permission system service is started. The application solves the problem of entity management difficulty caused by business requirements when the permission system is designed or after the permission system is put into operation.

Description

Technical Field

[0001] This invention relates to the field of robot access control technology, and in particular to a scalable access management method for robot process automation systems based on a domain role access control model. Background Technology

[0002] Access control is an essential component that must be considered when building the backend of a robotic process automation (RoMA) system, and indeed all backend systems. Its purpose is to restrict the resources that all users in the system can read and write to within a certain scope. Users can only access the functions, data, and other resources that they are legally authorized to access, thereby preventing production safety accidents caused by unauthorized operations.

[0003] The existing access control model is the RBAC (Role-Based Access Control) model. The RBAC model constrains four levels of implementation: RBAC0, RBAC1, RBAC2, and RBAC3. The RBAC0 model is the most basic and core access control model, encompassing users, roles, and permissions. Users and roles have a many-to-many relationship, as do roles and permissions. The RBAC1 model introduces the concept of role inheritance, meaning roles have hierarchical relationships. Inheritance relationships between roles can be categorized as general inheritance or restricted inheritance. The RBAC2 model further develops upon the RBAC0 model...

[0004] In terms of role-based constraint control, the RBAC2 model adds a separation of responsibilities relationship, which stipulates the mandatory rules that should be followed when permissions are assigned to roles, roles are assigned to users, and when a user activates a role at a certain time. The RBAC3 model is based on the RBAC0 model and integrates RBAC1 and RBAC2, that is, RBAC3 = RBAC1 + RBAC2.

[0005] Using the RBAC model as the access control model can meet the needs of most RPA systems and backend systems. However, there are certain prerequisites. The RBAC0 model, as a basic layer model, cannot provide the necessary capabilities for access control in RPA systems and a significant portion of backend systems. Depending on actual needs, many developers choose RBAC1 or RBAC2 layers based on RBAC0, or even RBAC3 layers integrating RBAC1 and RBAC2, to match the complexity of the system being built. However, developing and implementing models above RBAC0 is inherently challenging. Furthermore, the RBAC model defines...

[0006] The user / role / permission entities do not fully meet the actual needs of most modern systems and backend systems, and developers need to make appropriate extensions themselves.

[0007] In traditional designs, at least one association table needs to be created to store the relationship between two entities. However, as the number of entities in the system increases, the corresponding entity tables and their association tables with existing entities in the system also increase, eventually making it difficult to add, delete, modify, and query permission data. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention provides a scalable permission management method for robots based on a domain role-based access control model. This invention offers more sovereignty dimensions and extended management capabilities, while reducing development and implementation difficulty, and can meet the construction needs of the system and most backend systems.

[0009] The technical solution of this invention is: a robot scalable permission management method based on a domain role access control model, comprising the following steps:

[0010] S1) Define the basic attributes of the first-level entity and create the corresponding database table with the auto-incrementing integer id as the primary key;

[0011] S2) Define the basic attributes required for the second-level entity as the sovereign entity, and create the corresponding database table with the auto-incrementing integer id as the primary key; and define the second-level entity as the set of authoritative permission values ​​for the sovereign entity.

[0012] S3) Define the third-level entity as the basic attributes required by the resource entity, and create the corresponding database table with the auto-incrementing integer id as the primary key; at the same time, define the third-level entity as the set of authoritative permission values ​​for the resource entity;

[0013] S4) Define the sovereign object, authorized object, authorized permission value, and tenant as columns of the sovereign entity permission table, and create the corresponding database table with an auto-incrementing integer id as the primary key;

[0014] S5) Define the sovereign object inheritor, sovereign object, and tenant as columns in the sovereign entity inheritance relationship table, and create the corresponding database table with an auto-incrementing integer id as the primary key;

[0015] S6) Define the relationship between the second-level entities and the third-level entities as needed;

[0016] S7) Storage of defined permission data: The permission management system determines whether to store sovereign entity permission data or sovereign entity inherited data based on the storage interface type and sovereign object type called by the client. Sovereign entity permission data is stored in the sovereign object, authorized object, authorized permission value, and tenant columns of the sovereign entity permission table in the format of sovereign object type prefix + sovereign object id, authorized object type prefix + authorized object id, authorized permission value, and current tenant id. Then, the sovereign entity permission data is appended to the permission data key-value pair set in the permission system's memory. Sovereign entity inherited data is stored in the sovereign object inheritor, sovereign object, and tenant columns of the sovereign entity inheritance relationship table in the format of sovereign object inheritor type prefix + sovereign object inheritor id, sovereign object type prefix + sovereign object id, and current tenant id. Then, the sovereign entity inherited data is appended to the permission data key-value pair set in the permission system's memory.

[0017] S8) When the permission system service starts, it loads all valid data of the sovereign entity permission table and the sovereign entity inheritance relationship table into memory as a set of key-value pairs.

[0018] Preferably, in step S4), the defined sovereign object is a second-level entity.

[0019] Preferably, in step S4), the defined authorized object is either a second-level entity or a third-level entity.

[0020] Preferably, in step S4), the defined authorization permission value is either the set of authorization permissions that can be granted to the second-level entity or the set of authorization permissions that can be granted to the third-level entity, depending on the authorization object level.

[0021] Preferably, in step S4), the single-row entity permission table data can be represented as the authorization permission value that the sovereign object in the tenant has for the authorized object.

[0022] Preferably, in step S5), the defined sovereign object inheritor and sovereign object are set to second-level entities.

[0023] Preferably, in step S5), the single-row sovereign entity inheritance relationship table data can be represented as the authorization permission values ​​of all authorized objects owned by the sovereign object inheritor in the tenant.

[0024] As a preferred option,

[0025] Preferably, the permission data needs to be verified during storage. The verification steps for the permission data are as follows:

[0026] Step S71): The permission management system recursively searches the memory permission data key-value pair set to see if the current logged-in user directly or indirectly possesses the authorization permission value of the target authorized object inherited from other sovereign objects, based on the operation type of the interface requested by the client, the current logged-in user ID, the type of the operation target authorized object, and the operation target authorized object ID.

[0027] Step S72): If the current user has the authorization permission value of the target authorized object, continue to execute the business logic of the client request interface; if the current user does not have the authorization permission value of the target authorized object, respond to the client with the "unauthorized" result.

[0028] Preferably, when business development requires the expansion to second-level or third-level entities, steps S2) and S6) are repeated, and then the defined permission data is stored and validated; specifically as follows:

[0029] Step 101: Define the basic attributes of the new second-level or third-level entity, and create the corresponding database table with the auto-incrementing integer id as the primary key;

[0030] Step 102: Define the set of authorizable permission values ​​for the new second-level or third-level entity;

[0031] Step 103: Define the relationship between the new second-level or third-level entity and the existing second-level and third-level entities.

[0032] The beneficial effects of this invention are as follows:

[0033] 1. Based on the user / role / permission described in the RBAC model, this invention extends to tenant-sovereign entity-resource-permission, as well as tenant-sovereign entity inheritor-sovereign entity. The sovereign entity can be a user, role, user group, department, or other custom entity. Compared with the entities described in the RBAC model, it is more extensible and flexible, and has a wider range of applications.

[0034] 2. This invention can be extended to the construction of multi-table databases, reducing cross-table operations while making the data model simpler and easier to understand;

[0035] 3. This invention solves the problem of entity management difficulties caused by business needs during the design of the permission system or after the permission system goes online;

[0036] 4. This invention is based on the domain role-based access control model, which simplifies the traditional permission system's "one table, one association table" multi-association table database design, while providing more sovereignty dimensions and extended management capabilities. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the first-level entity defined in an embodiment of the present invention;

[0038] Figure 2 This is a schematic diagram of the second-level entity defined in an embodiment of the present invention;

[0039] Figure 3 This is a schematic diagram of the set of authorized permissions for a second-level entity as defined in an embodiment of the present invention;

[0040] Figure 4 This is a schematic diagram of a third-level entity as defined in an embodiment of the present invention;

[0041] Figure 5 This is a schematic diagram of the set of authorizable permissions for a third-level entity as defined in an embodiment of the present invention;

[0042] Figure 6 This is a schematic diagram of the sovereign entity authority table defined in an embodiment of the present invention;

[0043] Figure 7 This is a schematic diagram of the sovereign entity inheritance relationship table defined in an embodiment of the present invention;

[0044] Figure 8 This is a diagram showing the relationships between the various sovereign entities defined in this embodiment of the invention. Detailed Implementation

[0045] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings:

[0046] This embodiment provides a robot scalable permission management method based on a domain role access control model, including the following steps:

[0047] S1) Define the basic attributes of the first-level entity. In this embodiment, the first-level entity is the tenant, and a corresponding database table is created using an auto-incrementing integer id as the primary key; see [link to documentation]. Figure 1 As shown.

[0048] S2) Define the basic attributes required for the second-level entities to serve as the sovereign entity. In this embodiment, the second-level entities include users, user groups, departments, roles, projects, etc. A corresponding database table is created using an auto-incrementing integer id as the primary key. Simultaneously, the second-level entities are defined as the set of authoritative permission values ​​for the sovereign entity; see [link to documentation]. Figure 2 , 3 As shown.

[0049] S3) Define the basic attributes required for the third-level entity as a resource entity, and create a corresponding database table with an auto-incrementing integer id as the primary key; simultaneously define the third-level entity as the set of authoritative permission values ​​for the resource entity; wherein, the third-level entity includes menus, APIs, robots, processes, etc. See also Figure 4 , 5 As shown.

[0050] S4) Define the sovereign object, authorized object, authorized permission value, and tenant as columns in the sovereign entity's permission table, and create the corresponding database table with an auto-incrementing integer id as the primary key; see also Figure 6 As shown.

[0051] In this embodiment, the defined sovereign object is a second-level entity. The defined authorized object is either a second-level or third-level entity. The defined authorized permission value is the set of authorized permissions that can be granted to second-level entities or third-level entities, depending on the authorized object's level. A single row of entity permission table data can represent the authorized permission value that the sovereign object in the tenant possesses for the authorized object.

[0052] S5) Define the sovereign object inheritor, sovereign object, and tenant as columns in the sovereign entity inheritance relationship table, and create the corresponding database table with an auto-incrementing integer id as the primary key;

[0053] In this embodiment, the sovereign object inheritor and sovereign object are defined as second-level entities. The single-row sovereign entity inheritance table data can be represented as the sovereign object inheritor's inherited authorization permissions from all authorized objects owned by the sovereign object within the tenant, as shown in the example below. Figure 7 As shown.

[0054] S6) Define the relationship between the second-level entities and the third-level entities as needed. See [link to information on relationships between sovereign entities] for details. Figure 8 As shown;

[0055] S7) The storage of defined permission data: The permission management system determines whether to store sovereign entity permission data or sovereign entity inherited data based on the storage interface type and sovereign object type called by the client.

[0056] Sovereign entity permission data is stored in the sovereign object, authorized object, authorized permission value, and tenant columns of the sovereign entity permission table in the format of sovereign object type prefix + sovereign object id, authorized object type prefix + authorized object id, authorized permission value, and current tenant id. Then, the sovereign entity permission data is appended to the permission data key-value pair set in the permission system memory. Sovereign entity inheritance data is stored in the sovereign object inheritor, sovereign object, and tenant columns of the sovereign entity inheritance relationship table in the format of sovereign object inheritor type prefix + sovereign object inheritor id, sovereign object type prefix + sovereign object id, and current tenant id. Then, the sovereign entity inheritance data is appended to the permission data key-value pair set in the permission system memory.

[0057] S8) When the permission system service starts, it loads all valid data of the sovereign entity permission table and the sovereign entity inheritance relationship table into memory as a set of key-value pairs.

[0058] In this preferred embodiment, the permission data needs to be verified during storage. The verification steps for the permission data are as follows:

[0059] Step S71): The permission management system recursively searches the memory permission data key-value pair set to see if the current logged-in user directly or indirectly possesses the authorization permission value of the target authorized object inherited from other sovereign objects, based on the operation type of the interface requested by the client, the current logged-in user ID, the type of the operation target authorized object, and the operation target authorized object ID.

[0060] Step S72): If the current user has the authorization permission value of the target authorized object, continue to execute the business logic of the client request interface; if the current user does not have the authorization permission value of the target authorized object, respond to the client with the "unauthorized" result.

[0061] Preferably, when business development requires the expansion to second-level or third-level entities, steps S2) and S6) are repeated, and then the defined permission data is stored and validated; specifically as follows:

[0062] Step 101: Define the basic attributes of the new second-level or third-level entity, and create the corresponding database table with the auto-incrementing integer id as the primary key;

[0063] Step 102: Define the set of authorizable permission values ​​for the new second-level or third-level entity;

[0064] Step 103: Define the relationship between the new second-level or third-level entity and the existing second-level and third-level entities.

[0065] This invention extends the user / role / permission description of the RBAC model to tenant-sovereign entity-resource-permission, and tenant-sovereign entity successor-sovereign entity. The sovereign entity can be a user, role, user group, department, or other custom entity. Each tenant is independent and data is isolated; that is, a tenant cannot view the sovereign entities, resources, or other information of other tenants. Compared to the entities described in the RBAC model, this invention is more extensible, flexible, and has a wider range of applications.

[0066] The embodiments and descriptions above are merely illustrative of the principles and preferred embodiments of the present invention. Various changes and modifications may be made to the present invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed.

Claims

1. A scalable permission management method for robots based on a domain-based role-based access control model, characterized in that: Includes the following steps: S1) Define the basic attributes of the first-level entity, where the first-level entity is the tenant, and create a corresponding database table with an auto-incrementing integer id as the primary key; S2) Define the basic attributes required for the second-level entity as the sovereign entity, and create the corresponding database table with the auto-incrementing integer id as the primary key; at the same time, define the second-level entity as the set of authoritative permission values ​​for the sovereign entity; S3) Define the basic attributes required for the third-level entity as a resource entity, and create a corresponding database table with an auto-incrementing integer id as the primary key; at the same time, define the third-level entity as the set of authoritative permission values ​​for the resource entity; wherein, the third-level entity includes menu, API, robot, and process; S4) Define the sovereign object, authorized object, authorized permission value, and tenant as columns in the sovereign entity permission table, and create the corresponding database table with an auto-incrementing integer id as the primary key; the defined sovereign object is a second-level entity; the defined authorized object is a second-level entity or a third-level entity; the defined authorized permission value is the set of authorized permissions that can be granted to the second-level entity or the third-level entity, depending on the level of the authorized object; a single row of entity permission table data can be represented as the authorized permission value that the sovereign object in the tenant possesses for the authorized object; S5) Define the sovereign object inheritor, sovereign object, and tenant as columns in the sovereign entity inheritance relationship table, and create the corresponding database table with an auto-incrementing integer id as the primary key; the defined sovereign object inheritor and sovereign object are defined as second-level entities; a single row of sovereign entity inheritance relationship table data can be represented as the sovereign object inheritor in the tenant inheriting the authorization permission values ​​of all authorized objects owned by the sovereign object; S6) Define the relationship between the second-level entities and the third-level entities as needed; S7) Storage of defined permission data: The permission management system determines whether to store sovereign entity permission data or sovereign entity inherited data based on the storage interface type and sovereign object type called by the client. Sovereign entity permission data is stored in the sovereign object, authorized object, authorized permission value, and tenant columns of the sovereign entity permission table in the format of sovereign object type prefix + sovereign object id, authorized object type prefix + authorized object id, authorized permission value, and current tenant id. Then, the sovereign entity permission data is appended to the permission data key-value pair set in the permission system's memory. Sovereign entity inherited data is stored in the sovereign object inheritor type prefix + sovereign object inheritor id, sovereign object type prefix + sovereign object id, and current tenant id in the sovereign entity inheritance relationship table in the format of sovereign object inheritor, sovereign object, and tenant columns. Then, the sovereign entity inherited data is appended to the permission data key-value pair set in the permission system's memory. S8) When the permission system service starts, it loads all valid data of the sovereign entity permission table and the sovereign entity inheritance relationship table into memory as a set of key-value pairs.

2. The robot scalable permission management method based on a domain role access control model according to claim 1, characterized in that: During the storage process of the permission data mentioned in step S7, it needs to be verified. The verification steps for the permission data are as follows: Step S71): The permission management system recursively searches the memory permission data key-value pair set to see if the currently logged-in user directly or indirectly possesses the authorization permission value of the target authorized object inherited from other sovereign objects, based on the operation type of the interface requested by the client, the current logged-in user ID, the type of the operation target authorized object, and the operation target authorized object ID. Step S72): If the current user has the authorization permission value of the target authorized object, continue to execute the business logic of the client request interface; if the current user does not have the authorization permission value of the target authorized object, respond to the client with the "unauthorized" result.

3. The robot scalable permission management method based on a domain role access control model according to claim 1, characterized in that: When business development requires the expansion to second-level or third-level entities, repeat steps S2) and S6), and then store and validate the defined permission data; specifically as follows: Step 101: Define the basic attributes of the new second-level or third-level entity, and create the corresponding database table with the auto-incrementing integer id as the primary key; Step 102: Define the set of authorizable permission values ​​for the new second-level or third-level entity; Step 103: Define the relationship between the new second-level or third-level entity and the existing second-level and third-level entities.

Images