Multi-organization collaborative software authority control method
By using two-layer role definition and decoupling platform functional permissions and organizational function roles in multi-organization collaboration software, the problem that traditional RBAC model is difficult to achieve user complex role permission control in multi-organization collaboration software is solved, and users can realize different businesses Software permission control and data isolation in application scenarios.
Patent Information
- Application Number
- CN202411674112.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-21
- Publication Date
- 2025-02-07
AI Technical Summary
In multi-organization collaboration software, traditional RBAC mode is difficult to solve the problem of permission control changes caused by user organization role switching, as well as the problem of implementing user cross-organization data permission control.
Using two-layer role definitions, decouple platform function permission definitions and organization function role definitions. By querying user-platform role-function permission relationships and project container-user-project role relationships, obtain operation permissions, and realize user complex roles based on different business applications. The software permissions of the scene are controlled according to the situation.
It supports the definition of different organizational structures and functional roles, meets the parallel application of multiple integration projects, and realizes software permission control for complex user roles in different business application scenarios, ensuring data isolation and cross-organization permission control.
Smart Images
Figure CN119397507A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of software permissions, and in particular to a multi-organization collaborative software permissions control method. Background Art
[0002] Software permission control is a basic function to achieve user access control and ensure data security. From the user's perspective, software permissions can be divided into page permissions, data permissions, and operation permissions. At present, RBAC is the most common software permission control model in the field of software permission design. The basic principle of RBAC is to associate roles with control permissions and assign appropriate roles to users to achieve user access control. In the traditional RBAC model, user permissions are the union of permissions owned by all roles of the user. As long as a role has a certain permission, the user has this permission.
[0003] For single-organization users with mature management, traditional RBAC can effectively reduce authorization complexity and management costs because the "permission-role-user" relationship is relatively stable; however, for the application scenario of integrated project teams with multi-organization collaboration, the software permission design of traditional RBAC cannot meet engineering needs. This is mainly reflected in the following two aspects: 1. In an integration project team, one person may play different roles in different organizations of the same project and have different permissions. Traditional RBAC is difficult to solve the problem of permission control changes caused by user organization role switching; 2. In a multi-level project team, users in the upper-level organization need to have data permissions for nodes in the lower-level organization, but users in the lower-level organization cannot have data permissions for nodes in the upper-level organization. Data between different organizations at the same level needs to be isolated. It is difficult to implement cross-organizational data permission control for users based on traditional RBAC.
[0004] Therefore, for the permission design of multi-organization collaborative software and to achieve effective permission control for users across organizations, it is necessary to solve the problem of complex roles taking effect according to the situation under the traditional RBAC model. Summary of the invention
[0005] In view of the defects in the prior art, the present invention provides a multi-organization collaborative software permission control method to solve the problem of complex roles of cross-organization users in multi-organization collaborative software taking effect according to the situation.
[0006] The present invention provides a multi-organization collaborative software permission control method, comprising: S1. In response to the user logging in to the software, apply for authentication; S2. Query the user-platform role-function permission relationship and obtain the function menu; S3. In response to the user selecting the function menu to enter the function page, apply for authentication; S4. Determine whether the function page selected by the user is related to the project; if the selected function page is not related to the project, proceed to S5; if so, proceed to S7; S5. According to the business data resource control criteria, determine the user attributes, obtain accessible business data, and complete data authentication; S6. Query the user-platform role-function permission relationship and obtain the operation permission; and proceed to S10; S7. Query the project container-user-project role relationship to obtain the project set; S8. Load the project data according to the project container ID selected by the user and complete data authentication; S9. Query the relationship between user-project role-platform role-function permission and obtain the operation permission; S10. User authentication is completed and business work is carried out.
[0007] It can be seen from the above technical scheme that the present invention provides a multi-organization collaborative software permission control method, which adopts a two-layer role definition, decouples the platform function permission definition and the organizational functional role definition, so that the software supports the parallel application of different organizational structures, different functional role definitions, and multiple integration projects, and meets the control needs of complex software permissions of the same person in different integration projects and different organizations of the same project, and realizes the situation-based control of software permissions of users' complex roles based on different business application scenarios.
[0008] Optionally, the step S2 specifically includes: Based on the user ID, query the user-platform role association table to obtain the platform role ID; According to the platform role ID, query the platform role-function permission association table, obtain page permissions, and complete menu authentication.
[0009] Optionally, the user-platform role association table includes at least a user ID and a platform role ID, and the specific relationship between the user ID and the platform role ID only appears once in the user-platform role association table; The platform role-function permission association table includes at least a platform role ID and a function permission ID, and the specific relationship between the platform role ID and the function permission ID only appears once in the platform role-function permission association table.
[0010] It can be seen from the above technical solution that since the user table maintenance, project organization structure tree root node creation, and platform role definition are not related to the project, it is necessary to supplement the user's non-project function permission control, and the user-platform role association table corresponds to the relationship between users and platform roles.
[0011] Optionally, the step S6 specifically includes: Based on the current user ID, query the user-platform role association table to obtain the platform role ID set; Based on the platform role ID set, query the platform role-function permission association table, obtain the function operation permission set, and complete the operation authentication.
[0012] It can be seen from the above technical solution that the platform role-functional authority association table is used to record the association relationship between the platform role and the functional authority it possesses, and the functional authority and the platform role are in a many-to-many relationship.
[0013] Optionally, the functional permissions include page permissions and button permissions, wherein the page permissions indicate whether a software functional module can be used; and the button permissions indicate whether an interactive button on a functional page can be operated. The function permission table includes at least the function permission ID, permission name, function permission parent node ID, order and permission identification attributes; The function permission parent node ID is used to characterize the subordinate relationship between page permissions and button permissions; the order is used to determine the arrangement order of the same-level function permissions; the permission identification attribute records the function permission code identifier, which is used for software control permission implementation.
[0014] Optionally, the step S7 specifically includes: Based on the user ID, query the project container-user-project role association table to obtain the main project set of the project where the user is located; Based on the project container ID of the main project set, query the project container table, recursively obtain all descendant projects, and form a descendant project set; Combine the two sets to form the final itemset.
[0015] It can be seen from the above technical solution that since users often participate in multiple projects or serve in different organizations of a project, it is necessary to first clarify the relationship between the project container and the user. The relationship between the project container and the user is many-to-many; under the premise that the user has only one project role under a specific project container, a project container-user-project role association table is established.
[0016] Optionally, the project container-user-project role association table includes at least a project container ID, a user ID and a project role ID, and the specific relationship among the project container ID, the user ID and the project role ID only appears once in the project container-user-project role association table; The project container table includes at least a project container ID, a project name and a project container parent node ID, wherein the project container parent node ID is used to characterize the subordinate relationship between project containers and to build a project organization structure tree.
[0017] It can be seen from the above technical solution that the project container is an abstraction of the physical entity of an organizational department or project package, supports team management, and can store and manage specific tag data; building a project organization structure tree based on the project structure hierarchy or organizational structure hierarchy not only intuitively reflects the organizational relationship of personnel in the real world, but also serves as the basis for software user management and permission control; the nodes of the project organization structure tree are all project containers, and the project container table is a collection of a series of project organization structure tree nodes.
[0018] Optionally, the step S9 specifically includes: Based on the current user ID and the current project container ID, query the project container-user-project role association table to obtain the project role ID; According to the project role ID, query the platform role-project role association table to obtain the corresponding platform role ID set; Based on the platform role ID set, query the platform role-function permission association table, obtain the function operation permission set, and complete the operation authentication.
[0019] Optionally, the platform role-project role association table includes at least a platform role ID and a project role ID, and the specific relationship between the platform role ID and the project role ID only appears once in the platform role-project role association table.
[0020] It can be seen from the above technical solution that starting from the work functions undertaken by the project role, the functional business modules and control permissions used by the project role in the software application are analyzed, and the platform role corresponding to the project role is matched to form a platform role-project role association table. The platform role and the project role are in a many-to-many relationship.
[0021] By adopting the above technical solution, the present application has the following beneficial effects: (1) Improve the RBAC model to adopt a two-layer role definition, decouple the platform function permission definition from the organizational function role definition, so that the software supports the parallel application of different organizational structures, different function role definitions, and multiple integration projects, and meets the control needs of complex software permissions for the same person in different integration projects and different organizations of the same project, so that the user's complex role can be controlled according to the software permissions based on different business application scenarios; (2) Based on the project container design, data isolation of different organizations in the integration project is achieved, supporting users of the upper-level organization to access the data resources of the lower-level organization without having the operation permissions of the lower-level organization data resources, thus meeting the needs of multi-organization collaboration software for cross-organization application scenarios of complex integration projects. BRIEF DESCRIPTION OF THE DRAWINGS
[0022] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for the specific embodiments or the description of the prior art. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn according to the actual scale.
[0023] Figure 1 A flow chart of a multi-organization collaborative software authority control method provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION
[0024] The following embodiments of the technical solution of the present invention are described in detail in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and are therefore only used as examples, and cannot be used to limit the protection scope of the present invention. It should be noted that, unless otherwise specified, the technical terms or scientific terms used in this application should have the common meanings understood by those skilled in the art to which the present invention belongs.
[0025] In one embodiment, Figure 1 As shown, a multi-organization collaborative software permission control method is provided to realize the situation-based control of complex roles of cross-organization users in multi-organization collaborative software. The method improves the RBAC model by combining the software containerization design concept, including: S1. In response to the user logging in to the software, apply for authentication; S2. Query the user-platform role-function permission relationship and obtain the function menu; S3. In response to the user selecting the function menu to enter the function page, apply for authentication; S4. Determine whether the function page selected by the user is related to the project; if the selected function page is not related to the project, proceed to S5; if so, proceed to S7; S5. According to the business data resource control criteria, determine the user attributes, obtain accessible business data, and complete data authentication; S6. Query the user-platform role-function permission relationship and obtain the operation permission; and proceed to S10; S7. Query the project container-user-project role relationship to obtain the project set; S8. Load the project data according to the project container ID selected by the user and complete data authentication; S9. Query the relationship between user-project role-platform role-function permission and obtain the operation permission; S10. User authentication is completed and business work is carried out.
[0026] Based on this, the improved RBAC model adopts a two-layer role definition, decoupling the platform function permission definition from the organizational functional role definition, so that the software supports the parallel application of different organizational structures, different functional role definitions, and multiple integration projects, and meets the control needs of complex software permissions for the same person in different integration projects and different organizations of the same project, so that the user's complex role can be used to control software permissions based on different business application scenarios.
[0027] In one embodiment, step S2 specifically includes: Based on the user ID, query the user-platform role association table to obtain the platform role ID; Based on the platform role ID, query the platform role-function permission association table, obtain page permissions, and complete menu authentication.
[0028] User represents the collection of software users. Based on the improved RBAC, user authority control needs to establish the relationship between users and platform roles or project roles. In this step, the platform role is determined based on the pre-established user table and user-platform role table, as well as the specific relationship between users and platform roles. The user table is shown in Table 1, and the platform role table is shown in Table 2.
[0029] Table 1 User table
[0030] Table 2 Platform role table
[0031] The platform role is an abstract definition of an organic combination of a series of functional permissions, which only considers the business logic of software functions and has nothing to do with user organizational relationships; the platform role definition needs to intuitively reflect the software function control aspect. In this embodiment, a platform role table is established to form a collection of platform roles defined by software designers or users. For example, if a platform role is defined as an operator of a certain functional module, the platform role has the page permissions related to the specified functional module and the operation permissions that affect the data.
[0032] The platform role-functional permission association table is used to record the association between platform roles and the functional permissions they possess. There is a many-to-many relationship between functional permissions and platform roles.
[0033] Table 3 User-platform role association table
[0034] In step S2, the queried user-platform role association table is shown in Table 3. Optionally, the user-platform role association table includes at least the user ID and the platform role ID, and the specific relationship between the user ID and the platform role ID only appears once in the user-platform role association table. Since the user table maintenance, the creation of the root node of the project organization structure tree, and the platform role definition are not related to the project, it is necessary to supplement the user's non-project function permission control, and the user-platform role association table corresponds to the relationship between the user and the platform role.
[0035] The platform role-functional permission association table is shown in Table 4, which includes at least the platform role ID and functional permission ID. The specific relationship between the platform role ID and functional permission ID only appears once in the platform role-functional permission association table. The platform role-functional permission association table is used to record the association relationship between the platform role and the functional permission it possesses. The functional permission and the platform role are in a many-to-many relationship.
[0036] Table 4 Platform role-function permission association table
[0037] Among them, all functional permission definitions of the software form a finite set through the functional permission table. According to the form of permission expression, functional permissions are divided into two types: page permissions and button permissions; page permissions, also known as menu permissions, represent whether the software functional modules can be used; button permissions represent whether the interactive buttons on the functional page can be operated. As shown in Table 5, the above functional permission table at least contains functional permission ID, permission name, functional permission parent node ID, order and permission identification attributes, among which the functional permission parent node ID attribute is used to represent the subordinate relationship between page permissions and button permissions; the order attribute is used to determine the arrangement order of functional permissions of the same level; the permission identification attribute records the functional permission code identifier, which is used for software control permission implementation. The permission identification paradigm is <page identifier>:<sub-page identifier>:<button identifier>. The page identifier can be expanded to multiple levels, but in general, the page identifier does not exceed two levels.
[0038] Table 5 Functional permissions table
[0039] Optionally, step S6 specifically includes: Based on the current user ID, query the user-platform role association table to obtain the platform role ID set; Based on the platform role ID set, query the platform role-function permission association table, obtain the function operation permission set, and complete the operation authentication.
[0040] Since user table maintenance, project organization structure tree node creation, and platform role definition are not related to the project, it is necessary to supplement user non-project functional permissions and establish a user-platform role association table. The user and platform roles are in a many-to-many relationship. The user-platform role association table contains at least the user ID and the platform role ID. The user-platform role association table needs to perform data uniqueness verification, that is, the specific relationship between the user ID and the platform role ID is only allowed to appear once in the table. User represents a collection of software users. Based on improved RBAC, user permission control needs to establish a relationship between users and platform roles or project roles.
[0041] Optionally, the functional permissions include page permissions and button permissions. The page permissions indicate whether the software functional module can be used; the button permissions indicate whether the interactive buttons on the functional page can be operated. The function permission table includes at least the function permission ID, permission name, function permission parent node ID, order and permission identification attributes; The function permission parent node ID is used to characterize the subordinate relationship between page permissions and button permissions; the order is used to determine the arrangement order of the same-level function permissions; the permission identification attribute records the function permission code identifier, which is used for software control permission implementation.
[0042] In one embodiment, step S7 specifically includes: Based on the user ID, query the project container-user-project role association table to obtain the main project set of the project where the user is located; Based on the project container ID of the main project set, query the project container table, recursively obtain all descendant projects, and form a descendant project set; Combine the two sets to form the final itemset.
[0043] Since users often participate in multiple projects or serve in different organizations of a project, it is necessary to first clarify the relationship between project containers and users. The relationship between project containers and users is many-to-many. Under the premise that users have only one project role in a specific project container, a project container-user-project role association table is established, as shown in Table 6.
[0044] Table 6 Project container-user-project role association table
[0045] As shown in Table 6, the project container-user-project role association table includes at least the project container ID, the user ID and the project role ID. The specific relationship among the project container ID, the user ID and the project role ID only appears once in the project container-user-project role association table. Table 7 Project container table
[0046] As shown in Table 7, the project container table includes at least a project container ID, a project name, and a project container parent node ID, wherein the project container parent node ID is used to characterize the subordinate relationship between project containers and to build a project organization structure tree.
[0047] A project container is an abstraction of the physical entity of an organizational department or project package. It supports team management and can store and manage specific tag data. Building a project organization structure tree based on the project structure hierarchy or organizational structure hierarchy not only intuitively reflects the organizational relationship of personnel in the real world, but also serves as the basis for software user management and permission control. All nodes of the project organization structure tree are project containers, and the project container table is a collection of a series of project organization structure tree nodes.
[0048] Optionally, step S9 specifically includes: Based on the current user ID and the current project container ID, query the project container-user-project role association table to obtain the project role ID; According to the project role ID, query the platform role-project role association table to obtain the corresponding platform role ID set; Based on the platform role ID set, query the platform role-function permission association table, obtain the function operation permission set, and complete the operation authentication.
[0049] The collection of organizational position roles or integrated project team roles forms a project role table, as shown in Table 8. Organizational position roles and project team roles are collectively referred to as project roles. Starting from the job functions undertaken by the project roles, the functional business modules and control permissions used by the project roles in software applications are analyzed, and the platform roles corresponding to the project roles are matched to form a platform role-project role association table. The platform roles and project roles are in a many-to-many relationship.
[0050] Table 8 Project role table
[0051] In one embodiment, the platform role-project role association table includes at least a platform role ID and a project role ID. The specific relationship between the platform role ID and the project role ID only appears once in the platform role-project role association table, as shown in Table 9.
[0052] Table 9 Platform role-project role association table
[0053] Therefore, starting from the work functions undertaken by the project role, analyze the functional business modules and control permissions used by the project role in the software application, match the platform role corresponding to the project role, and form a platform role-project role association table. The platform role and project role are in a many-to-many relationship.
[0054] The above embodiments are only used to introduce the technical solutions of the present application in detail, but the description of the above embodiments is only used to help understand the methods of the embodiments of the present invention and should not be understood as limiting the embodiments of the present invention. Any changes or substitutions that can be easily thought of by technicians in this technical field should be included in the protection scope of the embodiments of the present invention.
Claims
1. A multi-organization collaborative software permission control method, characterized in that: include: S1. In response to the user logging in to the software, apply for authentication; S2. Query the user-platform role-function permission relationship and obtain the function menu; S3. In response to the user selecting a function menu, entering the function page, and applying for authentication; S4. Determine whether the function page selected by the user is related to the project; if the selected function page is not related to the project, proceed to S5; If relevant, go to S7; S5. According to the business data resource control criteria, determine the user attributes, obtain accessible business data, and complete data authentication; S6. Query the user-platform role-function permission relationship and obtain the operation permission; and transfer to S10; S7. Query the project container-user-project role relationship to obtain the project set; S8. Load the project data according to the project container ID selected by the user and complete data authentication; S9. Query the user-project-platform role-function permission relationship to obtain operation permissions; S10. User authentication is completed and business work is carried out.
2. The method according to claim 1, characterized in that The step S2 specifically includes: Based on the user ID, query the user-platform role association table to obtain the platform role ID; According to the platform role ID, query the platform role-function permission association table, obtain page permissions, and complete menu authentication.
3. The method according to claim 2, characterized in that The user-platform role association table includes at least a user ID and a platform role ID, and the specific relationship between the user ID and the platform role ID only appears once in the user-platform role association table; The platform role-function permission association table includes at least a platform role ID and a function permission ID, and the specific relationship between the platform role ID and the function permission ID only appears once in the platform role-function permission association table.
4. The method according to claim 3, characterized in that: The step S6 specifically includes: Based on the current user ID, query the user-platform role association table to obtain the platform role ID set; Based on the platform role ID set, query the platform role-function permission association table, obtain the function operation permission set, and complete the operation authentication.
5. The method according to claim 3, characterized in that: The functional permissions include page permissions and button permissions. The page permissions indicate whether the software function module can be used; the button permissions indicate whether the interactive buttons on the function page can be operated; The function permission table includes at least function permission ID, permission name, function permission parent node ID, order and permission identification attributes; The function permission parent node ID is used to represent the subordinate relationship between page permission and button permission; The order is used to determine the order of functional permissions at the same level; The permission identification attribute records the functional permission code identifier, which is used for software control permission implementation.
6. The method according to claim 1, characterized in that The step S7 specifically includes: Based on the user ID, query the project container-user-project role association table to obtain the main project set of the project where the user is located; Based on the project container ID of the main project set, query the project container table, recursively obtain all descendant projects, and form a descendant project set; Combine the two sets to form the final itemset.
7. The method according to claim 6, characterized in that The project container-user-project role association table includes at least a project container ID, a user ID and a project role ID, and the specific relationship among the project container ID, the user ID and the project role ID only appears once in the project container-user-project role association table; The project container table includes at least a project container ID, a project name, and a project container parent node ID, wherein the project container parent node ID is used to characterize the subordinate relationship between project containers and is used to build a project organization structure tree; The nodes of the project organization structure tree are project containers; the nodes of the project organization structure tree have a hierarchical relationship, which enables the upper-level project container nodes to access the lower-level project container nodes.
8. The method according to claim 7, characterized in that The step S9 specifically includes: Based on the current user ID and the current project container ID, query the project container-user-project role association table to obtain the project role ID; According to the project role ID, query the platform role-project role association table to obtain the corresponding platform role ID set; Based on the platform role ID set, query the platform role-function permission association table, obtain the function operation permission set, and complete the operation authentication.
9. The method according to claim 8, characterized in that The platform role-project role association table includes at least a platform role ID and a project role ID. The specific relationship between the platform role ID and the project role ID only appears once in the platform role-project role association table.