Multi-project isolation and three-level permission management and control method and system based on P-RBAC architecture

Abstract

This invention discloses a method and system for multi-project isolation and three-level permission control based on a P-RBAC architecture. The method constructs a P-RBAC architecture based on five core dimensions: user, department, project, role, and permission, completing multi-dimensional basic data entry and relational configuration. Then, it matches organization-project dimension permissions through user authentication, and parses a three-level permission set (menu, button, and data) based on role permission sets. Finally, it implements dynamic rendering of front-end menu and button permissions and fine-grained filtering of back-end data permissions, achieving multi-project isolation and full-dimensional permission control. The system includes six functional modules: database table construction module, basic data configuration module, identity authentication and project permission matching module, three-level permission parsing module, front-end permission rendering module, and back-end data permission control module. This solves the problems of traditional RBAC models, such as lack of project-level isolation, single-granularity permissions, and disconnection from enterprise organizational structure.

Description

Technical Field

[0001] This invention belongs to the field of computer software access control technology, and more specifically, relates to a method and system for multi-project isolation and three-level access control based on P-RBAC architecture. Background Technology

[0002] Role-based access control (RBAC) is a mainstream access control technology in computer systems. It achieves batch allocation and management of permissions through a hierarchical association of users, roles, and permissions, and has been widely used in systems with single projects and simple organizational structures. With the deepening of enterprise digital transformation, the need for multi-project management in group-level enterprises is becoming increasingly prominent. Group-level multi-project management platforms need to support the operation and management of multiple independent projects simultaneously, involving multi-level organizational structures, multi-type role classifications, and multi-dimensional data isolation, which places higher demands on the refinement, security, and adaptability of access control.

[0003] However, the traditional RBAC model has revealed many technical shortcomings in the actual application of group-level multi-project management platforms, and can no longer meet the requirements for refined and highly secure access control. Specifically, these shortcomings are reflected in the following aspects: Lack of core isolation design at the project level: The traditional RBAC model does not build the association logic between projects, users, and permissions, and lacks a project-level permission boundary division mechanism, which can easily lead to security risks of cross-project data access and cannot adapt to the permission isolation requirements of multi-project parallel management. The granularity of access control is limited: it can only achieve visibility control at the menu level, and does not cover fine-grained management of page button operations and backend data access. It cannot meet the differentiated needs of different roles for operation permissions and data access scope, and the granularity of access control cannot match the complex scenarios of group-level business. Disconnected from the enterprise's multi-level organizational structure: The closed loop of permission association between departments, projects, and users has not been achieved, and permission control cannot be combined with the multi-level organizational structure of the group, company, department, and project department. This results in a mismatch between permission allocation and the actual business organizational structure of the enterprise, greatly reducing the practicality of permission management. Lack of standardized data access control rules: The lack of hierarchical access control rules for data based on role attributes makes it easy for project staff to obtain data that is not related to their project, which violates the principle of least privilege in the field of information security and poses a serious risk of data leakage. Disorganized access control and high maintenance costs: Permissions are not directly bound to projects, and the scope of role permissions is the global system. It is impossible to achieve fine-grained allocation of permissions based on projects. In multi-project scenarios, problems such as permission overlap and unauthorized access are likely to occur. The complexity of access control and maintenance costs are high. Poor architectural scalability: The traditional RBAC model has a single dimension and cannot support the dynamic adjustment of enterprise organizational structure, project scope, and permission system. When an enterprise adds a new project, adjusts the department structure, or adds a new role, a lot of modifications need to be made to the core architecture, resulting in poor adaptability.

[0004] There is currently no effective solution to the aforementioned technical problems. There is an urgent need for a brand-new access control method and system that integrates project and department dimensions into the traditional RBAC model to build a P-RBAC architecture that is adapted to group-level multi-project management. This would enable precise isolation of multi-project data and full-dimensional, refined access control of menus, buttons, and data, while also taking into account the flexibility, scalability, and versatility of the architecture. Summary of the Invention

[0005] To address the aforementioned deficiencies or improvement needs of existing technologies, this invention provides a multi-project isolation and three-level permission control method and system based on a P-RBAC architecture. It innovatively introduces a project dimension to construct a five-dimensional linked P-RBAC architecture on the basis of traditional RBAC. By designing ten core database tables, including a project-permission direct binding table, it establishes a many-to-many relationship system between users, departments, projects, roles, and permissions. Permissions are refined into three levels: menu, button, and interface. The rule_id hierarchical rule enables precise control of operation visibility and data access scope. The user-department-project three-level linkage determines the scope of accessible projects, and the effective permissions are obtained by combining the intersection of the project's basic permission set and the role's permission set. Ultimately, it achieves dynamic rendering of front-end menu buttons and fine-grained filtering of back-end data permissions. This invention can achieve natural data isolation across multiple projects, fine-grained permission control across the entire menu-button-data chain, and triple linkage control between organization, project, and permission. It strictly adheres to the principle of least privilege and features high control accuracy, strong security, good adaptability, strong scalability, and low maintenance costs. It is suitable for permission security control in various group-level multi-project management platforms.

[0006] To achieve the above objectives, one aspect of the present invention provides a method for multi-project isolation and three-level access control based on a P-RBAC architecture, comprising the following steps: S1. The P-RBAC architecture core database table system is constructed based on five core dimensions: user, department, project, role, and permission. The database table system includes basic information tables and relationship tables. The basic information tables include user table, department table, project table, role table, and permission table. The relationship tables include user-department relationship table, user-role relationship table, project-department relationship table, role-permission relationship table, and project-permission relationship table. S2. Enter the corresponding basic data of users, departments, projects, roles, and permissions in each basic information table. Configure many-to-many relationships between users and departments, projects and departments, projects and permissions, users and roles, and roles and permissions through the relationship table. Configure the corresponding rule_id hierarchical control rules for role-permission relationships. S3. When a user initiates a login request, the system verifies the validity of the account and password and the user's status. After successful verification, the system queries all department IDs to which the user belongs based on the user ID, queries all associated project IDs based on the department ID to determine the scope of projects that the user can access, and queries all associated permission IDs based on the project ID to obtain the user's basic permission set within the scope of their project. S4. Query all assigned role IDs based on user ID, query all bound permission IDs and corresponding rule_id hierarchical control rules through role ID, perform intersection operation on the project basic permission set and role permission set to obtain the effective permission set, and combine the perm_type field of the permission table to parse out the user's menu-button-data three-level permission set; S5. The front-end system dynamically renders page elements based on the user's menu and button permissions and the corresponding rule_id hierarchical control rules, displaying menus and buttons with rule_id=1 and hiding menus and buttons with rule_id=0. S6. When a user initiates a data access request, the backend system dynamically constructs data filtering conditions based on the rule_id hierarchical control rules for data permissions and the scope of projects that the user can access, and performs fine-grained filtering on the database query results, returning only the data that the user has permission to access. All data access requests are initiated through the interface, and the interface permission is the only carrier for data permission control.

[0007] Furthermore, the department table is configured with a dept_type field and a parent_id field. The dept_type field is used to classify department types as 1-Group, 2-Company, 3-Department, 4-Project Department, and 5-Virtual Organization. When the parent_id field is 0, it indicates a top-level department. A multi-level organizational structure of Group-Company-Department-Project Department is built through the parent_id field. The project table has a dept_id field, which is associated with the primary key id of the project department type (dept_type=4) in the department table, thus binding the project to its respective project department.

[0008] Furthermore, the permission table sets up a perm_type field and a parent_id field; perm_type divides permissions into three categories: 1-menu, 2-button, and 3-interface, with interface permissions serving as the technical carrier for data permission control; the parent_id of button and interface type permissions points to the corresponding menu permission ID, realizing hierarchical association of permissions.

[0009] Furthermore, the role-permission relationship table sets the rule_id field as a hierarchical control rule. Under the menu / button permission dimension, rule_id is 0 - invisible, 1 - visible. Under the data permission dimension, rule_id is 0 - no permission, 1 - only personal, 2 - departmental permission, 3 - all permissions.

[0010] Furthermore, in step S2, the many-to-many relationship between project and menu permissions is configured through the project-permission relationship table, and the set of permissions that can be used is independently limited for each project, so as to achieve precise isolation of project-level permissions; In step S2, when configuring the many-to-many association between roles and permissions, a corresponding rule_id hierarchical control rule must be configured for each group of role-permission binding relationships to differentiate the control of menu visibility, button visibility and data access scope. Step S2 establishes a five-dimensional permission configuration system that links users, departments, projects, roles, and permissions by uniformly configuring five groups of many-to-many relationships: user-department, user-role, role-permission, project-department, and project-permission.

[0011] Furthermore, in step S3, only users with the enabled status (status=1) are authenticated; the scope of projects that a user can access is determined by the user's department and the project-department relationship. The basic permission set for a project is directly limited by the project-permission relationship table, enabling preliminary filtering of project-level permissions.

[0012] Furthermore, the parsing rules for the three-level permission set in step S4 are as follows: Menu permissions: perm_type=1, visibility is determined by rule_id; Button permissions: perm_type=2, visibility is determined by rule_id; Data permissions: perm_type=3, combined with rule_id to determine the scope of hierarchical data access.

[0013] Furthermore, the backend data filtering rules in step S6 are as follows: rule_id=0: Access denied; rule_id=1: The filtering condition is that the data creator ID = current user ID + project ID ∈ the accessible range; rule_id=2: The filtering condition is that the data belongs to the department ID ∈ user department ID + project ID ∈ accessible range; rule_id=3: The filtering condition is that the item ID is within the accessible range.

[0014] Furthermore, the five core dimensions mentioned in step S1 all adopt many-to-many relationships: user-multiple departments, user-multiple roles, role-multiple permissions, department-multiple projects, and project-multiple permissions, supporting dynamic expansion of organizational structure, project scope, and permission system.

[0015] A second aspect of the present invention provides a multi-project isolation and three-level access control system based on a P-RBAC architecture, used to implement the aforementioned multi-project isolation and three-level access control method based on a P-RBAC architecture, comprising: Database table construction module: Used to build the core database tables of the P-RBAC architecture, configure the field attributes, data types, constraints and relationships between dimensions of each table, and realize multi-level organizational structure support, three-level permission division and hierarchical control rule configuration; Basic data configuration module: Used to enter basic data of users, departments, projects, roles, and permissions in each core database table, configure many-to-many relationships of users-departments, projects-departments, projects-permissions, users-roles, and roles-permissions, and configure corresponding rule_id hierarchical control rules for role-permission associations; The identity authentication and project permission matching module is used to authenticate the user's login request, verify the validity of the account password and the activation of the user status. After successful verification, it queries all departments and related projects to which the user belongs based on the user ID, determines the scope of projects that the user can access and the basic permission set within the scope of the project, and realizes the initial screening of project isolation. The three-level permission parsing module has a built-in permission intersection operation unit, which is used to query all roles assigned to users and the permissions bound to roles and the corresponding rule_id rules. It performs an intersection operation on the project's basic permission set and the role permission set to obtain the effective permission set. Then, combined with the perm_type field of the permission table, it parses out the user's menu-button-data three-level permission set. Front-end permission rendering module: It is used to dynamically render front-end page elements according to the user's menu and button permissions and the corresponding rule_id hierarchical control rules, display menus and buttons that meet the permission requirements, and hide menus and buttons that do not have permission, so as to realize fine-grained control of front-end operation permissions. Backend data access control module: It is used to dynamically construct data filtering conditions based on the user's data access rule_id and the scope of accessible items, and to perform fine-grained filtering and access control on backend data access requests, returning only the data that the user has permission to access, thereby achieving precise control over backend data permissions.

[0016] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects: (1) This invention is the first to integrate the P-RBAC five-dimensional linkage architecture into the project dimension. By adding a project-permission direct binding mechanism, it constructs a complete closed loop of user-department-project-role-permission association, realizing triple linkage of organizational dimension, permission dimension and project dimension. It completely solves the technical defects of traditional RBAC model, such as lack of project isolation, disconnection from multi-level organizational structure and globalization of permissions. It makes the permission boundary clear and the data naturally isolated in multi-project scenarios, greatly improving the adaptability, scalability and control standardization of system architecture.

[0017] (2) This invention can realize refined permission control of the entire chain of menu-button-data. It can accurately control the visibility of operations and the scope of data access through hierarchical control rules, and adopt the intersection verification mechanism of project basic permission set and role permission set to strictly implement the principle of least privilege in information security. It refines the granularity of permission control from the single menu level to the button operation and data interface level, effectively avoids the risks of unauthorized operation, cross-project data access and information leakage, and significantly improves the accuracy of permission control and the level of data security.

[0018] (3) This invention adopts a multi-dimensional many-to-many association and standardized configuration mode. The permission control logic is independent of the business system. It can be quickly adapted to various group-level multi-project management platforms without modifying the core business. Through role batch authorization, project-permission direct binding, front-end dynamic rendering and back-end automatic filtering integrated control, the permission allocation and maintenance process is greatly simplified, the permission management cost is reduced, and the system's universality, implementation and operation efficiency are improved. It provides efficient, secure and scalable permission support capabilities for enterprise multi-project digital management. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a multi-project isolation and three-level access control method based on a P-RBAC architecture according to an embodiment of the present invention. Figure 2 This is a schematic diagram of a multi-project isolation and three-level access control system based on the P-RBAC architecture according to an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0021] like Figure 1 As shown, one aspect of the present invention provides a method for multi-project isolation and three-level permission management based on a P-RBAC (Project-Based Role-Based Access Control) architecture. The P-RBAC architecture is constructed based on five core dimensions: user, department, project, role, and permission. By designing multi-dimensional basic information tables, relationship tables, and project-permission direct binding tables, hierarchical control rules are configured for the association between roles and permissions, achieving triple linkage across organizational, permission, and project dimensions. Ultimately, this achieves multi-project isolation and refined management of menu-button-data three-level permissions. Specifically, the method includes the following steps: S1. Construct the core database table system of the P-RBAC architecture; the database table system includes basic information tables and relationship tables; the basic information tables include user table (sys_user), department table (sys_dept), project table (project), role table (sys_role), and permission table (sys_perm); the relationship tables include user-department relationship table (sys_user_dept), user-role relationship table (sys_user_role), project-department relationship table (sys_project_dept), role-permission relationship table (sys_role_perm), and project-permission relationship table (sys_project_perm); S2. Complete multi-dimensional basic data entry and relationship configuration: Based on the core database table system built in step S1, complete the basic data entry and relationship configuration between various dimensions of the group-level multi-project management platform; enter the corresponding basic data of users, departments, projects, roles, and permissions in each basic information table; configure many-to-many relationships of users-departments, projects-departments, projects-permissions, users-roles, and roles-permissions through the relationship table; and configure the corresponding rule_id hierarchical control rules for role-permission relationships. S3. User authentication and organization-project dimension permission matching: When a user initiates a login request, the system verifies the validity of the account and password and the user's status. After successful verification, the system queries all department IDs to which the user belongs based on the user ID, queries all associated project IDs based on the department ID to determine the scope of projects that the user can access, and queries all associated permission IDs based on the project ID to obtain the user's basic permission set within the scope of the project. S4. Role Permission Set Acquisition and Three-Level Permission Parsing: Query all assigned role IDs based on user ID, query all bound permission IDs and corresponding rule_id hierarchical control rules through role ID, perform intersection operation on the project basic permission set and role permission set to obtain the effective permission set, and combine the perm_type field of the permission table to parse the user's menu-button-data three-level permission set; S5. Dynamic rendering of front-end menu and button permissions: The front-end system dynamically renders page elements based on the user's menu and button permissions and the corresponding rule_id hierarchical control rules, displaying menus and buttons with rule_id=1 and hiding menus and buttons with rule_id=0. S6. Fine-grained filtering and access control of backend data permissions: When a user initiates a data access request, the backend system dynamically constructs data filtering conditions based on the rule_id hierarchical control rules of data permissions and the scope of projects that the user can access, and performs fine-grained filtering on the database query results, returning only the data that the user has permission to access. All data access requests are initiated through the interface, and the interface permission is the only carrier of data permission control.

[0022] This invention constructs an organizational dimension association system of users-departments-projects and a permission dimension association system of users-roles-permissions, combined with a project-permission direct binding mechanism, to achieve precise isolation of project data and refined three-level permission control of menus-buttons-data under a group-level multi-project management platform. It ensures that project team members can only access their own relevant project data, and that personnel of each role can obtain matching operation permissions and data access permissions as needed, adapting to the permission control needs of multi-level organizations at the group level. At the same time, it improves the data security and permission management efficiency of the multi-project management platform, reduces permission maintenance costs, and enhances the flexibility and scalability of the architecture.

[0023] Furthermore, in step S1, the user table (sys_user) is used to store basic information and status of system users, serving as the user subject identifier for access control. It includes fields such as user ID, login account, encrypted password, real name, affiliated department ID, mobile phone, email, and status. The password field is encrypted using BCrypt, and the status field distinguishes between enabled and disabled; see Table 1. Table 1 - User Table (sys_user) The department table (sys_dept) is used to store multi-level organizational structure information of an enterprise. It supports the hierarchical division of group-company-department-project department-virtual organization and includes fields such as department ID, department code, department name, parent department ID, department type, sorting, and status. A parent department ID of 0 indicates a top-level department, and the department type field distinguishes different organizational levels; see Table 2. Table 2 - Department Table (sys_dept) The user-department relationship table (sys_user_dept) is used to implement many-to-many relationships between users and departments. It supports organizational structure configurations where users belong to multiple departments and includes fields such as ID, department ID, and user ID. It sets a joint unique constraint of department ID + user ID; see Table 3. Table 3 - User-Department Relationship Table (sys_user_dept) The role table (sys_role) is used to store system-defined role information, serving as an intermediary between users and permissions to enable batch permission allocation. It includes fields such as role ID, role code, role name, description, and status; see Table 4. Table 4 - Role Table (sys_role) The user-role relationship table (sys_user_role) is used to implement many-to-many relationships between users and roles. It supports assigning multiple roles to a user and stacking permission sets. It includes fields such as ID, role ID, and user ID, and sets a joint unique constraint of role ID + user ID; see Table 5; Table 5 - User-Role Relationship Table (sys_user_role) The project table stores basic project information for the group-level multi-project management platform. It is the core dimension identifier for project isolation and includes fields such as project ID, project code, project name, description, associated project department ID, status, creator, and creation time; see Table 6. Table 6 - Project Table The Project-Department Relationship Table (sys_project_dept) is used to define the relationship between departments and projects, determine which departments have access to the corresponding projects, and is a key relationship table for project isolation. It contains fields such as ID, Department ID, and Project ID, and sets a joint unique constraint of Department ID + Project ID; see Table 7; Table 7 - Project-Department Relationship Table (sys_project_dept) The permissions table (sys_perm) is used to store fine-grained permission information for the system, defining three types of permissions: menu, button, and interface. The interface is the technical carrier for data permission control and includes fields such as permission ID, permission code, permission name, permission type, parent permission ID, route, icon, and sorting. The parent permission ID realizes the hierarchical association of permissions; see Table 8. Table 8 - Permissions Table (sys_perm) The role-permission relationship table (sys_role_perm) is used to implement many-to-many associations between roles and permissions, configure hierarchical control rules, and implement menu / button visibility and data permission control. It includes fields such as ID, permission ID, role ID, and permission rule (rule_id). It sets a joint unique constraint of permission ID + role ID. The rule_id field is the core of hierarchical control rules; see Table 9. Table 9 - Role-Permission Relationship Table (sys_role_perm) The project-permission relationship table (sys_project_perm) is used to implement a direct many-to-many association between projects and permissions, defining the scope of permissions (menus) that can be used by a specific project, further strengthening project isolation and precise permission control. It includes fields such as ID, permission ID, and project ID, and sets a joint unique constraint of permission ID + project ID; see Table 10; Table 10 - Project-Permission Relationship Table (sys_project_perm) Furthermore, in step S1, the department table is configured with a `dept_type` field, supporting department type classifications such as 1-Group, 2-Company, 3-Department, 4-Project Department, and 5-Virtual Organization; the department table is configured with a `parent_id` field, where 0 represents the top-level department, enabling the construction of a multi-level organizational structure from Group to Company to Department to Project Department; the permission table is configured with a `perm_type` field, dividing permissions into three categories: 1-Menu, 2-Button, and 3-Interface, with interface permissions serving as the technical carrier for data permission control; the permission table is also configured with a `path` field and an `icon` field, where the `path` field is only valid for menu and interface type permissions, and the `icon` field is only valid for menu type permissions; the permission table is also configured with a `parent_id` field. The `d` field, specifically the `parent_id` field for button and interface type permissions, is configured as the ID of the corresponding menu permission, enabling hierarchical permission association. The role-permission relationship table uses a `rule_id` field as a hierarchical control rule. Under the menu / button permission dimension, `rule_id` is 0 (invisible) and 1 (visible); under the data permission dimension, `rule_id` is 0 (no permission), 1 (personal only), 2 (department permission), and 3 (all permissions). The `password` field in the user table is stored using BCrypt encryption. The `dept_id` field in the user table is associated with the primary key ID of the department table, binding users to their main department. The `dept_id` field in the project table is associated with the primary key ID of the project department type in the department table, binding projects to their respective project departments. All core database tables use bigint as the primary key type and are auto-incrementing. The default value of the time field is CURRENT_TIMESTAMP, and the character set is uniformly utf8mb4. Many-to-many association tables are set with joint unique constraints. Furthermore, step S2 specifically includes: In the user table, department table, project table, role table, and permission table, respectively enter the basic data of users, departments, projects, roles, and permissions of the platform. The permission data must completely cover all menus, buttons, and backend interfaces of the platform. Configure many-to-many relationships between users and departments through the user-department relationship table, and bind users to their corresponding departments according to the actual organizational structure of the enterprise; The project-department relationship table configures many-to-many relationships between projects and departments, and defines the scope of departments that can access the project based on the project's business affiliation, providing a basis for project isolation; By configuring a project-permission relationship table, a many-to-many relationship between projects and permissions (menus) can be established. Based on the business needs of the project, the set of permissions (menus) that the project can use can be defined to achieve precise project-level control of permissions. Configure many-to-many relationships between users and roles through the user-role relationship table, and assign corresponding roles to users based on their job positions and responsibilities; The role-permission relationship table is used to configure a many-to-many relationship between roles and permissions, and to configure a corresponding rule_id hierarchical control rule for each relationship, so as to realize differentiated configuration of menu-button-data three-level permissions for different roles. In step S2, the many-to-many relationship between projects and menu permissions is configured through the project-permission relationship table, and the set of permissions that can be used is independently limited for each project, so as to achieve precise isolation of project-level permissions. When configuring the many-to-many relationship between roles and permissions, the corresponding rule_id hierarchical management rule must be configured for each role-permission binding relationship to differentiate the control of menu visibility, button visibility and data access scope. In step S2, five sets of many-to-many relationships are uniformly configured: user-department, user-role, role-permission, project-department, and project-permission, forming a five-dimensional linkage permission configuration system of user-department-project-role-permission. In step S2, the basic permission data must completely cover all menus, buttons, and backend interfaces of the platform to ensure comprehensive permission control; the rule_id configuration for role-permission association must be set differently according to the role's job responsibilities and permission scope; the project-permission association must be precisely configured according to the project's business needs to achieve project-level isolation of permissions. Furthermore, in step S3, after the user initiates a system login request, the system completes identity authentication and determines the scope of projects the user can access and the basic permission set based on the user's organizational dimension association and project-permission binding relationship, thus achieving preliminary screening for project isolation. Specifically, this includes: Users initiate a system login request using their login account and password. The system queries the user table to verify the validity of the account and password, and checks the user status field. Only users with the status enabled (status=1) can complete identity authentication and enter the system, while users with the status disabled are directly denied login. Based on the unique ID of the authenticated user, retrieve all department IDs to which the user belongs from the user-department relationship table; Using the department ID found in the query as a condition, retrieve all associated project IDs from the project-department relationship table to determine the scope of projects that the user can access; Using the retrieved project ID as a condition, query all associated permission IDs from the project-permission relationship table to determine the user's basic permission set within the scope of the project, thus achieving preliminary permission filtering based on the project. In step S3, the user authentication verification includes the validity of the account password and the enablement of the user status. Only after both are verified can the user enter the system. Users in a disabled state are directly refused to log in.

[0024] Further, in step S4, the system obtains the user's role permission set based on the user's role assignment relationship, and combines it with the project basic permission set determined in step S3 to parse out the user's final menu-button-data three-level permission set, specifically including: Based on the unique ID of the user who has passed authentication, retrieve all role IDs assigned to the user from the user-role relationship table; Using the retrieved role ID as a condition, query the role-permission relationship table for all bound permission IDs and their corresponding rule_id hierarchical control rules; Perform an intersection operation on the project basic permission set obtained in step S3 and the role permission set obtained in step S2 to obtain the user's valid permission set within the scope of the project. Using the permission ID from the valid permission set as a condition, query the corresponding permission information from the permission table, and combine the perm_type permission type field with the rule_id hierarchical control rule to parse out the user's three-level permission set: Menu permissions: Permission data for perm_type=1, combined with rule_id to determine the visibility of the menu; Button permissions: Permission data for perm_type=2, combined with rule_id to determine the button's visibility; Data permissions: Interface permission data with perm_type=3, combined with rule_id to determine the hierarchical access rules for the data; In step S4, the intersection of the project's basic permission set and the role's permission set is calculated to ensure that users can only obtain the permissions that their roles have within the scope of their project, thus further enhancing the accuracy of permission control.

[0025] Furthermore, in step S5, the front-end system dynamically renders page elements based on the user menu permissions, button permissions, and corresponding rule_id hierarchical control rules parsed in step S4, thereby achieving fine-grained control of front-end operation permissions: menus and buttons with rule_id=1 are displayed normally, supporting normal user access and operation; menus and buttons with rule_id=0 are hidden, preventing users from seeing such menus and buttons on the front-end page, thus achieving control over operation permissions at the front-end level.

[0026] Furthermore, after a user initiates a data access request on the front end, the back end system dynamically constructs data filtering conditions based on the project scope determined in step S3 and the data permission hierarchical rules parsed in step S4, and performs fine-grained filtering on the database query results, returning only the data that the user has permission to access, thereby achieving precise control over backend data permissions. The filtering rules in step S6 are as follows: If the data permission rule_id=0: the system directly rejects the user's data access request, returns a no permission message, and the user cannot obtain any data; If the data permission rule_id=1 (personal only): the filtering condition is that the data creator ID = the current user's unique ID + the project ID ∈ the scope of projects that the user can access, and only the data created by the user in their own project will be returned; If the data permission rule_id=2 (this department's permission): the filtering condition is that the data belongs to the department ID ∈ the user's department ID + the project ID ∈ the scope of projects that the user can access, and only the relevant data of the user's department in the projects it belongs to will be returned; If the data permission rule_id=3 (all permissions): the filter condition is that the project ID ∈ the scope of projects that the user can access, and all data within the scope of the user's project will be returned; All data access requests are initiated through the backend interface. Interface permissions are the sole carrier for data permission control, ensuring the comprehensiveness and effectiveness of data permission control.

[0027] like Figure 2 As shown, a second aspect of the present invention provides a multi-project isolation and three-level access control system based on a P-RBAC architecture, used to implement the above-mentioned control method, including: Database table construction module: Used to build the core database tables of the P-RBAC architecture, configure the field attributes, data types, constraints and relationships between dimensions of each table, realize multi-level organizational structure support, three-level permission division and hierarchical control rule configuration, and provide underlying database support for the entire system; The basic data configuration module is used to enter basic data on users, departments, projects, roles, and permissions into each core database table, configure many-to-many relationships between users and departments, projects and departments, projects and permissions, users and roles, and roles and permissions, and configure corresponding rule_id hierarchical control rules for role-permission relationships, thus completing the initialization of the system's basic data. The identity authentication and project permission matching module is used to authenticate the user's login request, verify the validity of the account password and the activation of the user status. After successful verification, it queries all departments and related projects to which the user belongs based on the user ID, determines the scope of projects that the user can access and the basic permission set within the scope of the project, and realizes the initial screening of project isolation. The three-level permission parsing module has a built-in permission intersection operation unit, which is used to query all roles assigned to users and the permissions bound to roles and the corresponding rule_id rules. It performs an intersection operation on the project's basic permission set and the role permission set to obtain the effective permission set. Then, combined with the perm_type field of the permission table, it parses out the user's menu-button-data three-level permission set. Front-end permission rendering module: It is used to dynamically render front-end page elements according to the user's menu and button permissions and the corresponding rule_id hierarchical control rules, display menus and buttons that meet the permission requirements, and hide menus and buttons that do not have permission, so as to realize fine-grained control of front-end operation permissions. Backend data access control module: It has a built-in data interface verification unit. All data access requests must pass through this unit to verify the interface permissions. The backend data access control module is used to dynamically construct data filtering conditions based on the user's data permission rule_id and the scope of accessible items, and to perform fine-grained filtering and access control on backend data access requests. It only returns the data that the user has permission to access, so as to achieve precise control of backend data permissions.

[0028] It should be noted that the multi-project isolation and three-level access control system based on the P-RBAC architecture provided in this embodiment can be a computer program (including program code) running on a computer device. For example, the multi-project isolation and three-level access control system based on the P-RBAC architecture is an application software. The multi-project isolation and three-level access control system based on the P-RBAC architecture can be used to execute the corresponding steps in the above-described method provided in the embodiments of this application.

[0029] Example 1 Example 1 uses a multi-project management platform of a construction engineering group as an application scenario to describe in detail the multi-project isolation and three-level permission control method and system based on P-RBAC architecture of the present invention: The construction engineering group is a group-level enterprise with two subsidiaries, Company 1 and Company 2. Company 1 has three independent project departments (Project Department A, Project Department B, and Project Department C), and Company 2 has two independent project departments (Project Department D and Project Department F). The platform sets up four roles: group administrator, company administrator, project department administrator, and ordinary project department employee. The business permission requirements are as follows: the group administrator can access the project data of all project departments and has full operation permissions; the company administrator can access the project data of all project departments of the company and has full operation permissions; the project department administrator can access all project data of the project department and has operation permissions for the project department; and ordinary project department employees can only access the project data they created in the project department and only have basic viewing permissions.

[0030] Specifically, the steps include the following: Step 1: Construct the core database table system of the P-RBAC architecture The system's database table building module designs 10 types of core database tables, with the following personalized configurations for key fields: The department table (sys_dept) contains eight entries: Group Headquarters, Company 1, Company 2, Project Department A, Project Department B, Project Department C, Project Department D, and Project Department F. The dept_type is configured as 1 (Group), 2 (Company), 2 (Company), 4 (Project Department), 4 (Project Department), 4 (Project Department), 4 (Project Department), 4 (Project Department). The parent IDs of Company 1 and Company 2 are configured as the Group Headquarters ID. The parent IDs of Project Department A, Project Department B, and Project Department C are configured as the Company 1 ID. The parent IDs of Project Department D and Project Department F are configured as the Company 2 ID, thus establishing a multi-level organizational structure of Group-Company-Project Department. The permissions table (sys_perm) is used to enter permission data for the project management menu (perm_type=1, perm_code: menu:project), the add project button (perm_type=2, perm_code: btn:project:add), the edit project button (perm_type=2, perm_code: btn:project:edit), the project data query interface (perm_type=3, perm_code: api:project:list), and the project data export interface (perm_type=3, perm_code: api:project:export). The parent_id of the button and interface permissions is configured to the permission ID of the project management menu to realize hierarchical association of permissions. Project-Permission Relationship Table (sys_project_perm): Associates the project management menu permissions required by project A with those required by project department A. Projects B, C, D, and F are configured similarly to achieve precise binding between projects and permissions. Role-Permission Relationship Table (sys_role_perm): Configures role-permission associations and corresponding rule_id hierarchical control rules for four types of roles: Group administrator: rule_id=1 for all menus and buttons, rule_id=3 for all interfaces (full permissions); Company Administrator: rule_id=1 for all menus and buttons, rule_id=3 for all interfaces (full permissions); Project Manager: The rule_id of the relevant menus and buttons in this project department is 1, and the rule_id of the relevant interfaces is 3 (full permissions). For regular staff in the project department: the rule_id of the relevant menu in this project department is 1, the rule_id of all buttons is 0, the rule_id of the project data query interface is 1 (for individuals only), and the rule_id of the project data export interface is 0 (no permission). Step 2: Complete basic data entry and relationship configuration Complete the basic data entry and configuration of relationships across various dimensions through the system's basic data configuration module: Project Table: Enter five data entries for Project A, Project B, Project C, Project D, and Project F, which correspond to the core projects of Project Department A, Project Department B, Project Department C, Project Department D, and Project Department F, respectively. dept_id is associated with the department ID of each project department. Project-Department Relationship Table: Associates Project A with Project Department A, Project B with Project Department B, Project C with Project Department C, Project D with Project Department D, and Project F with Project Department F. Company 1 is associated with Projects A, B, and C. Company 2 is associated with Projects D and F. The Group Headquarters is associated with all projects. Defines the project access scope for each department. User-Department Relationship Table: Bind employees of Project Department A to Project Department A, and configure employees of Project Departments B, C, D, and F in the same way; bind company administrators to company departments, bind company administrators to company departments, and bind group administrators to group headquarters departments; User-Role Relationship Table: Assign the Group Administrator role to the Group Headquarters Management Personnel, assign the Company Administrator role to the Management Personnel of Each Company, assign the Project Department Administrator role to the Head of Each Project Department, and assign the Project Department Ordinary Employee role to the Ordinary Employee role to the Ordinary Employee role of Each Project Department. Step 3: User authentication and organization-project dimension permission matching When a regular employee of Project Department A initiates a login request, the system's identity authentication and project permission matching module performs the following operations: Verify that the employee's account password is valid and the user status is enabled to complete identity authentication; Based on the employee's user ID, it was found that their department is Project Department A; By using the department ID of Project Department A, it was found that the associated project is Project A, confirming that the employee can only access Project A; By using the project ID of project A, we can find that its associated basic permission set is the project management menu, thus achieving initial filtering of project permissions.

[0031] Step 4: Obtaining the Role Permission Set and Parsing the Three-Level Permissions The system's three-level permission resolution module performs the following operations: Based on the employee's user ID, it was found that their assigned role was a regular employee in the project department; By using the role ID of a regular employee in the project department, we can find their bound permissions and corresponding rule_id rules; Perform an intersection operation on the project's basic permission set (project management menu) and the role permission set to obtain the effective permission set, which includes the project management menu and the project data query interface. Based on the perm_type field in the permissions table, the employee's three-level permission set is parsed out: visible project management menu (perm_type=1, rule_id=1), no button operation permission (all perm_type=2 rule_id=0), personal permission only for the project data query interface (perm_type=3, rule_id=1), and no project data export permission (perm_type=3, rule_id=0).

[0032] Step 5: Dynamic rendering of front-end menu button permissions Based on the parsed three-level permission set, the system's front-end permission rendering module displays only the "Project Management Menu" on the front-end page, hiding all operation buttons such as Add and Edit. The employee can only see the Project Management Menu and cannot perform any button operations, thus achieving fine-grained control over front-end operation permissions.

[0033] Step 6: Fine-grained filtering and access control of backend data permissions The employee clicks the project management menu on the front end and initiates a project data query request (calling the api:project:list interface). The system's backend data permission control module completes the following operations: The data interface verification unit verifies that the employee has access permissions to the api:project:list interface and allows the request to continue; Based on the employee's data permission rules (rule_id=1) and the scope of accessible projects (project A), dynamically construct the filter conditions: Data creator ID = employee's user ID + project ID = project A; The database query results are filtered according to the filtering conditions, and only all project data created by the employee in project A is returned, so as to achieve precise control of backend data permissions.

[0034] Similarly, after logging into the system, the group administrator can query all project data of all project departments; after logging into the system, the company administrator can query all project data of all project departments under the company; after logging into the system, the administrator of Project Department A can query all project data of Project Department A. All of these achieve precise multi-project isolation and three-level access control through the method and system of this invention, which fully matches the business access requirements of the construction engineering group.

[0035] Example 2 This embodiment uses a multi-product project R&D platform of a technology company as an application scenario. The company has multiple R&D project teams. The platform has four roles: "Technical Director, Project Team Leader, R&D Engineer, and Test Engineer". The business permission requirements are as follows: the Technical Director can access all R&D project data, the Project Team Leader can access all R&D data of their project team, the R&D Engineer can only access the R&D module data they are responsible for, and the Test Engineer can access the test-related data of their project team.

[0036] The multi-project isolation and three-level permission control method of the P-RBAC architecture of the present invention only requires the configuration of key fields of the core database table and the entry of basic data and relationships according to the enterprise's organizational structure (R&D center, each project team), project scope, role permission requirements, etc. The control process is completely consistent with that of Example 1, which can quickly realize multi-project isolation and fine-grained permission control in this scenario, fully demonstrating the flexibility, adaptability and scalability of the present invention.

[0037] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement... Figure 1 The methods provided in each step are detailed in the implementation methods provided in the above steps, and will not be repeated here.

[0038] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for multi-project isolation and three-level access control based on P-RBAC architecture, characterized in that, Includes the following steps: S1. The P-RBAC architecture core database table system is constructed based on five core dimensions: user, department, project, role, and permission. The database table system includes basic information tables and relationship tables. The basic information tables include user table, department table, project table, role table, and permission table. The relationship tables include user-department relationship table, user-role relationship table, project-department relationship table, role-permission relationship table, and project-permission relationship table. S2. Enter the corresponding basic data of users, departments, projects, roles, and permissions in each basic information table. Configure many-to-many relationships between users and departments, projects and departments, projects and permissions, users and roles, and roles and permissions through the relationship table. Configure the corresponding rule_id hierarchical control rules for role-permission relationships. S3. When a user initiates a login request, the system verifies the validity of the account and password and the user's status. After successful verification, the system queries all department IDs to which the user belongs based on the user ID, queries all associated project IDs based on the department ID to determine the scope of projects that the user can access, and queries all associated permission IDs based on the project ID to obtain the user's basic permission set within the scope of their project. S4. Query all assigned role IDs based on user ID, query all bound permission IDs and corresponding rule_id hierarchical control rules through role ID, perform intersection operation on the project basic permission set and role permission set to obtain the effective permission set, and combine the perm_type field of the permission table to parse out the user's menu-button-data three-level permission set; S5. The front-end system dynamically renders page elements based on the user's menu and button permissions and the corresponding rule_id hierarchical control rules, displaying menus and buttons with rule_id=1 and hiding menus and buttons with rule_id=0. S6. When a user initiates a data access request, the backend system dynamically constructs data filtering conditions based on the rule_id hierarchical control rules for data permissions and the scope of projects that the user can access, and performs fine-grained filtering on the database query results, returning only the data that the user has permission to access, thereby achieving precise control of backend data permissions.

2. The method for multi-project isolation and three-level access control based on P-RBAC architecture according to claim 1, characterized in that: The department table has a dept_type field and a parent_id field. The dept_type field is used to classify the department types as 1-Group, 2-Company, 3-Department, 4-Project Department, and 5-Virtual Organization. When the parent_id field is 0, it indicates a top-level department. A multi-level organizational structure of Group-Company-Department-Project Department is built through the parent_id field. The project table has a dept_id field, which is associated with the primary key id of the project department type (dept_type=4) in the department table, thus binding the project to its respective project department.

3. The method for multi-project isolation and three-level access control based on P-RBAC architecture according to claim 2, characterized in that: The permission table sets up a perm_type field and a parent_id field; perm_type divides permissions into three categories: 1-menu, 2-button, and 3-interface, with interface permissions serving as the technical carrier for data permission control; The parent_id of button and interface type permissions points to the permission ID of the corresponding menu, realizing hierarchical association of permissions.

4. The method for multi-project isolation and three-level access control based on P-RBAC architecture according to claim 3, characterized in that: The role-permission relationship table sets the rule_id field as a hierarchical control rule. Under the menu / button permission dimension, rule_id is 0 - invisible, 1 - visible. Under the data permission dimension, rule_id is 0 - no permission, 1 - only personal, 2 - departmental permission, 3 - all permission.

5. A method for multi-project isolation and three-level access control based on P-RBAC architecture according to any one of claims 1-4, characterized in that: In step S2, the many-to-many relationship between project and menu permissions is configured through the project-permission relationship table, and the set of permissions that can be used is independently limited for each project, so as to achieve precise isolation of project-level permissions; In step S2, when configuring the many-to-many association between roles and permissions, a corresponding rule_id hierarchical control rule must be configured for each group of role-permission binding relationships to differentiate the control of menu visibility, button visibility and data access scope. Step S2 establishes a five-dimensional permission configuration system that links users, departments, projects, roles, and permissions by uniformly configuring five sets of many-to-many relationships: user-department, user-role, role-permission, project-department, and project-permission.

6. A method for multi-project isolation and three-level access control based on P-RBAC architecture according to any one of claims 1-4, characterized in that: In step S3, only users with the enabled status (status=1) are authenticated; the scope of projects that a user can access is determined by the user's department and the project-department relationship. The basic permission set for a project is directly limited by the project-permission relationship table, enabling preliminary filtering of project-level permissions.

7. A method for multi-project isolation and three-level access control based on P-RBAC architecture according to any one of claims 1-4, characterized in that, The parsing rules for the three-level permission set in step S4 are as follows: Menu permissions: perm_type=1, visibility is determined by rule_id; Button permissions: perm_type=2, visibility is determined by rule_id; Data permissions: perm_type=3, combined with rule_id to determine the scope of hierarchical data access.

8. A method for multi-project isolation and three-level access control based on P-RBAC architecture according to any one of claims 1-4, characterized in that, The backend data filtering rules in step S6 are as follows: rule_id=0: Access denied; rule_id=1: The filtering condition is that the data creator ID = current user ID + project ID ∈ the accessible range; rule_id=2: The filtering condition is that the data belongs to the department ID ∈ user department ID + project ID ∈ accessible range; rule_id=3: The filtering condition is that the item ID is within the accessible range.

9. A method for multi-project isolation and three-level access control based on P-RBAC architecture according to claim 5, characterized in that, The five core dimensions mentioned in step S1 all adopt a many-to-many relationship: user-multiple departments, user-multiple roles, role-multiple permissions, department-multiple projects, project-multiple permissions, supporting dynamic expansion of organizational structure, project scope, and permission system.

10. A multi-project isolation and three-level access control system based on P-RBAC architecture, characterized in that, The method for implementing multi-project isolation and three-level access control based on the P-RBAC architecture as described in any one of claims 1-9 includes: Database table construction module: Used to build the core database tables of the P-RBAC architecture, configure the field attributes, data types, constraints and relationships between dimensions of each table, and realize multi-level organizational structure support, three-level permission division and hierarchical control rule configuration; Basic data configuration module: Used to enter basic data of users, departments, projects, roles, and permissions in each core database table, configure many-to-many relationships of users-departments, projects-departments, projects-permissions, users-roles, and roles-permissions, and configure corresponding rule_id hierarchical control rules for role-permission associations; The identity authentication and project permission matching module is used to authenticate the user's login request, verify the validity of the account password and the activation of the user status. After successful verification, it queries all departments and related projects to which the user belongs based on the user ID, determines the scope of projects that the user can access and the basic permission set within the scope of the project, and realizes the initial screening of project isolation. The three-level permission parsing module has a built-in permission intersection operation unit, which is used to query all roles assigned to users and the permissions bound to roles and the corresponding rule_id rules. It performs an intersection operation on the project's basic permission set and the role permission set to obtain the effective permission set. Then, combined with the perm_type field of the permission table, it parses out the user's menu-button-data three-level permission set. Front-end permission rendering module: It is used to dynamically render front-end page elements according to the user's menu and button permissions and the corresponding rule_id hierarchical control rules, display menus and buttons that meet the permission requirements, and hide menus and buttons that do not have permission, so as to realize fine-grained control of front-end operation permissions. Backend data access control module: It is used to dynamically construct data filtering conditions based on the user's data access rule_id and the scope of accessible items, and to perform fine-grained filtering and access control on backend data access requests, returning only the data that the user has permission to access, thereby achieving precise control over backend data permissions.

Images