Role-based authority management method and device, storage medium and electronic equipment

Abstract

The invention relates to a role-based authority management method and device, a storage medium and electronic equipment. The method comprises the following steps: acquiring a tenant forbidding rule set by a target tenant in an RBAC platform; according to the configured tenant forbidding function list, obtaining a corresponding storage strategy, storing the tenant forbidding rule, and synchronizing the tenant forbidding rule to all related micro-service nodes of the target tenant in the RBAC platform; obtaining an original role permission set of the authenticated target user on the RBAC platform and a tenant forbidding rule corresponding to a target tenant accessed by the target user, performing reverse filtering on the original role permission set based on the tenant forbidding rule to obtain a filtered role permission set, and performing role permission filtering on the filtered role permission set; synchronizing the filtering role permission set to all related micro-service nodes of the target tenant in the RBAC platform; and controlling the permission of the target user to access the target tenant based on the synchronized filtering role permission set. The platform function can be flexibly forbidden without changing the existing permission system, and the permission management efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of Internet access control technology, and in particular to a role-based access control method, apparatus, storage medium, and electronic device. Background Technology

[0002] Cloud-native technologies enable organizations, enterprises, and institutions to build and run scalable applications (tenants) in new dynamic environments such as public, private, and hybrid clouds, and have become the mainstream choice for enterprise application architecture. Among these, multi-tenant (MT) systems, by providing services to multiple independent tenants simultaneously, with tenant data isolation and resource sharing, are widely used in Software-as-a-Service (SaaS) platforms, enterprise collaboration systems, and other scenarios due to their advantages such as high resource utilization and efficient deployment and maintenance. Role-based access control (RBAC), which associates roles with permissions, is the core solution for permission management in multi-tenant systems. For each tenant within a multi-tenant system, pre-defined roles (such as project administrators or regular users) are assigned to that tenant, enabling permission control for users within that tenant.

[0003] As enterprises deepen their digital transformation, tenants of different industries and sizes have increasingly strong demands for customized permissions. RBAC platforms can no longer meet the application scenarios where the same role has different permissions for tenants. Therefore, fine-grained permission management of RBAC platforms based on cloud-native multi-tenant systems has become a core demand for technological development. Among related technologies, the permission control technology of RBAC platforms based on cloud-native multi-tenant systems is mainly based on forward RBAC extension, and its core implementation logic is as follows: By pre-setting a global role library in the RBAC platform, such as project administrator, developer, and viewer roles, a fixed set of permissions is associated with each role. These permissions include, but are not limited to, page access rights and operation rights. After a tenant is created, the administrator assigns available roles to the tenant from the global role library, or creates tenant-specific roles by copying and slightly modifying global roles from the library, and retrieves the permission set associated with each role from the global role library. Users obtain corresponding permissions by associating with roles within their tenant. In this way, role permission management and control are performed based on a pre-set forward authorization chain (user → role → permission). For example, K8s (Kubernetes) native RBAC platform extension solutions all use forward authorization chain as the core logic for allocating permissions. However, this role permission management method requires modifying or copying the global role for each tenant to achieve differentiated management of role permissions within the tenant. In cases where the global role library is complex (e.g., containing dozens of roles), the cost of achieving differentiated management of role permissions within the tenant is high, and it is prone to role redundancy, maintenance difficulties, and low permission management efficiency. Summary of the Invention

[0004] In view of this, the present invention provides a role-based access control method, apparatus, storage medium, and electronic device.

[0005] Specifically, the present invention is achieved through the following technical solution: According to a first aspect of the present invention, a role-based access control method is provided, the role-based access control method comprising: Obtain the tenant denial rules set by the target tenant in the role-based access control (RBAC) platform; Based on the list of disabled functions configured by the target tenant, obtain the corresponding storage policy, store the tenant prohibition rules, and synchronize the tenant prohibition rules to all relevant microservice nodes of the target tenant in the RBAC platform; Obtain the original role and permission set of the authenticated target user on the RBAC platform, as well as the tenant prohibition rule corresponding to the target tenant accessed by the target user. Based on the tenant prohibition rule, perform reverse filtering on the original role and permission set to obtain the filtered role and permission set. Synchronize the filtered role and permission set to all relevant microservice nodes of the target tenant in the RBAC platform. The system controls the access permissions of the target user to the target tenant based on a synchronized set of filtered role permissions.

[0006] Optionally, the step of obtaining the corresponding storage policy based on the tenant disabled function list configured by the target tenant and storing the tenant prohibition rules includes: If the target tenant is determined to be active based on the tenant disabled function list of the target tenant, the corresponding storage policy is a caching policy, and the tenant prohibition rule is stored in the cache; If the target tenant is determined to be inactive based on the tenant disabled feature list of the target tenant, the corresponding storage policy is a persistent storage policy, and the tenant prohibition rule is stored in persistent storage.

[0007] Optionally, synchronizing the tenant blocking rule to all relevant microservice nodes of the target tenant in the RBAC platform includes: Based on the configuration mapping method of the container orchestration platform, the tenant prohibition rule is sent to all relevant microservice nodes of the target tenant in the RBAC platform.

[0008] Optionally, the method further includes: Based on the target tenant's pre-set list of disabled tenant functions, adjust the corresponding storage policy.

[0009] Optionally, the acquisition of the original role and permission set of the authenticated target user on the RBAC platform, and the tenant prohibition rules corresponding to the target tenant accessed by the target user, includes: Perform user identity authentication on the target user; Perform tenant identity authentication on the target tenant accessed by the target user; Within the target tenant, query and obtain the target user's target role; In the RBAC platform, obtain the original role permission set corresponding to the target role; In the RBAC platform, the mapping relationship between tenants and storage policies is queried to obtain the storage policy of the target tenant. From the custom resources corresponding to the storage policy, the tenant prohibition rule corresponding to the target tenant is obtained.

[0010] Optionally, the step of reverse filtering the original role permission set based on the tenant prohibition rule to obtain a filtered role permission set includes: The tenant prohibition rules are parsed. For each prohibition rule obtained from the parsing, a query is performed in the original role permission set. If the prohibition rule is found, it is filtered from the original role permission set to obtain a filtered role permission set.

[0011] Optionally, synchronizing the filtered role permission set to all relevant microservice nodes of the target tenant in the RBAC platform includes: The filtered role permission set obtained after filtering based on tenant prohibition rules is returned to the front end through the JRestful API role permission interface, and simultaneously synchronized to the permission verification cache of the backend interface gateway.

[0012] The role-based access control (RBAC) method in this technical solution obtains the tenant prohibition rules set by the target tenant in the RBAC platform; based on the tenant disabled function list configured by the target tenant, obtains the corresponding storage policy, stores the tenant prohibition rules, and synchronizes the tenant prohibition rules to all relevant microservice nodes of the target tenant in the RBAC platform; obtains the original role permission set of the authenticated target user in the RBAC platform, as well as the tenant prohibition rules corresponding to the target tenant accessed by the target user, performs reverse filtering on the original role permission set based on the tenant prohibition rules, obtains a filtered role permission set, and synchronizes the filtered role permission set to all relevant microservice nodes of the target tenant in the RBAC platform; and controls the target user's access to the target tenant based on the synchronized filtered role permission set. In this way, by utilizing the tenant prohibition rules set by the tenant for reverse access control, and filtering out unnecessary permissions from the original role permission set according to the tenant prohibition rules, differentiated management of permissions for the same role can be achieved, effectively improving the efficiency of role permission management.

[0013] According to a second aspect of the present invention, a role-based access control device is provided, the role-based access control device comprising: The rule setting module is used to obtain the tenant denial rules set by the target tenant in the role-based access control (RBAC) platform; The rule storage module is used to obtain the corresponding storage policy based on the list of disabled functions configured by the target tenant, store the tenant prohibition rules, and synchronize the tenant prohibition rules to all relevant microservice nodes of the target tenant in the RBAC platform. The permission reverse filtering module is used to obtain the original role permission set of the authenticated target user on the RBAC platform, as well as the tenant prohibition rule corresponding to the target tenant accessed by the target user, perform reverse filtering on the original role permission set based on the tenant prohibition rule, obtain the filtered role permission set, and synchronize the filtered role permission set to all relevant microservice nodes of the target tenant in the RBAC platform. The synchronization update module is used to control the access permissions of the target user to the target tenant based on the synchronized filter role permission set.

[0014] According to a third aspect of the present invention, a storage medium is provided having a computer program stored thereon, wherein when the program is executed by a processor, it implements the steps of the role-based access control method in any possible implementation of the first aspect.

[0015] According to a fourth aspect of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the role-based access control method in any possible implementation of the first aspect. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a role-based access control method provided in an embodiment of the present invention; Figure 2 A schematic diagram of a role-based access control device provided in an embodiment of the present invention; Figure 3 Another schematic diagram of a role-based access control device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] In related technologies, role-based access control methods require modifying or copying global roles for each tenant to achieve differentiated management of role permissions within that tenant. In cases where the global role library is complex (e.g., containing dozens of roles), the cost of achieving differentiated management of role permissions within a tenant is high, and it is prone to role redundancy, maintenance difficulties, and low management efficiency. Meanwhile, it cannot meet tenant customization needs and lacks flexibility: In the RBAC platform, to set different permissions for the same role in different tenants, it is necessary to add a new role or modify the permission set of the role. It is not possible to quickly customize based on the original role, which makes it difficult to meet the flexible needs of multiple tenants with multiple permissions in a cloud-native multi-tenant system. Furthermore, the permissions set take effect late: After the permissions are modified, the application needs to be restarted, the cache refreshed, or wait for timed synchronization. They cannot take effect in real time, which affects the user experience. Moreover, the dimension of management and control of permissions is single: It only supports forward control of tenant → role → permission, and lacks a tenant-level reverse prohibition mechanism, which cannot accurately block some permissions while retaining the remaining default permissions. In addition, there is insufficient front-end and back-end collaboration: In related technologies, the focus is on back-end interface permission control. The permission filtering of front-end page, button and other resources depends on the permission management results returned by the back-end interface, which is prone to inconsistencies such as the front-end being able to see but the back-end denying access.

[0021] In this embodiment, the RBAC platform based on the cloud-native multi-tenant system, without changing the role system of the RBAC platform, achieves differentiated management of permissions for the same role through tenant-level reverse access control. That is, by inheriting the full permissions of the role by default, unnecessary permissions are filtered out by tenant-level prohibition rules, thereby achieving differentiated management of permissions for the same role, effectively improving the management efficiency of role permissions and meeting the needs for differentiated management of role permissions.

[0022] See Figure 1 This invention provides a role-based access control method, which may include the following steps: S101. Obtain the tenant denial rules set by the target tenant in the role-based access control (RBAC) platform; In this embodiment, as an optional embodiment, the target tenant administrator inputs tenant prohibition rules for the target tenant through the visual configuration interface provided by the RBAC platform.

[0023] In this embodiment, as an optional implementation, each tenant can access the RBAC platform through the OAuth2 protocol, an open authorization framework that allows third-party applications to obtain limited operation permissions for users in specific services without obtaining user account passwords, or the Lightweight Directory Access Protocol (LDAP).

[0024] In this embodiment, as an optional embodiment, after the target tenant administrator defines the tenant prohibition rule, the matching method of the tenant prohibition rule can also be set, wherein the matching method includes but is not limited to: exact matching and fuzzy matching.

[0025] In this embodiment, as an optional implementation, the tenant prohibition rules include, but are not limited to: platform function prohibition rules, tenant user prohibition rules, and resource scope prohibition rules. Among them, The platform function disabling rule is set to specify one or more platform functions that are prohibited from being accessed by the first role pre-defined under the current tenant. As an optional embodiment, the platform functions include, but are not limited to: project administrator, role-based access prohibition function, and data statistics function. The first role is a general term that includes one or more roles. The tenant user disabling rule is set to apply a pre-defined additional prohibition rule to a second role pre-defined within the current tenant. For example, a project administrator role within the current tenant is additionally prohibited from accessing the member management page in the project management function of the current tenant. In this embodiment, the project administrator is a role, and project management is a platform function. Project management is performed through roles, and this embodiment does not limit this. Resource scope prohibition rules are set to limit the dimensions of resources that are prohibited from access. Resources include, but are not limited to, pages, buttons, interfaces, and data. If the prohibited resources include pages and buttons, the corresponding resource dimension is 2-dimensional. As an optional embodiment, resource scope prohibition rules support hierarchical configuration. For example, a resource scope prohibition rule can be set to prohibit access to all sub-pages under the project management function.

[0026] In this embodiment, as an optional implementation, the platform function disabling rules, tenant user disabling rules, and resource scope disabling rules can be adjusted or updated. Platform function disabling rules include, but are not limited to, interface-level disabling rules, and resource scope disabling rules include, but are not limited to, page-level disabling rules. As another optional implementation, the tenant disabling rules corresponding to a tenant can be expanded or reduced based on the tenant's actual needs, thus expanding the granularity of the tenant disabling rules. This embodiment does not limit this. For example, as an optional implementation, this embodiment supports page and interface-level disabling; after expansion, it can support "data-level disabling." For instance, to prevent a tenant's project administrator from viewing data from other projects, data dimension identifiers (such as project ID and department ID) can be added to the tenant disabling rules. As another optional implementation, this embodiment, based on the "tenant + role + user" dimension, can be expanded to support multi-dimensional combinations of "tenant + role + user group + time" (such as disabling a user from accessing a function only during working hours). This can be achieved by adding time range and user group fields to the tenant disabling rules.

[0027] In this embodiment, as an optional implementation, the tenant prohibition rule is submitted via a RESTful API after configuration.

[0028] S102. Based on the list of disabled functions configured by the target tenant, obtain the corresponding storage policy, store the tenant prohibition rules, and synchronize the tenant prohibition rules to all relevant microservice nodes of the target tenant in the RBAC platform. In this embodiment, as an optional embodiment, based on the tenant disabled function list configured by the target tenant, the corresponding storage policy is obtained, and the tenant prohibition rules are stored, including: If the target tenant is determined to be active based on the tenant disabled function list of the target tenant, the corresponding storage policy is a caching policy, and the tenant prohibition rule is stored in the cache; If the target tenant is determined to be inactive based on the tenant disabled feature list of the target tenant, the corresponding storage policy is a persistent storage policy, and the tenant prohibition rule is stored in persistent storage.

[0029] In this embodiment, after the tenant prohibition rule is configured, it is submitted to the rule storage module for storage via a RESTful API. As an optional embodiment, caching includes, but is not limited to, Redis caching, and persistent storage includes, but is not limited to, MySQL. The rule storage module adopts a dual-storage architecture of "MySQL + Redis". MySQL stores the full data of the tenant prohibition rules to support persistence, while Redis caches the tenant prohibition rules for active tenants to improve query efficiency. As another optional embodiment, Kubernetes custom resource definitions (CRDs) can also be used to store the tenant prohibition rules, thereby leveraging the native resource scheduling and synchronization capabilities of Kubernetes to adapt to Kubernetes deployment scenarios and improve the synchronization efficiency of tenant prohibition rules.

[0030] In this embodiment, as an optional implementation, synchronizing the tenant blocking rule to all relevant microservice nodes of the target tenant in the RBAC platform includes: Based on the configuration mapping method of the container orchestration platform, the tenant prohibition rule is sent to all relevant microservice nodes of the target tenant in the RBAC platform.

[0031] In this embodiment, the rule storage module synchronizes tenant prohibition rules to all relevant microservice nodes through the configuration mapping (ConfigMap) method of the key-value pair resources used to store configuration data in the container orchestration platform (K8s, Kubernetes), ensuring the consistency of tenant prohibition rules in a distributed environment.

[0032] In this embodiment, as an optional embodiment, the method may further include: Based on the target tenant's pre-set list of disabled tenant functions, adjust the corresponding storage policy.

[0033] In this embodiment, after storing the tenant prohibition rules for the target tenant, the activity level of the target tenant may change. For example, a target tenant that was historically inactive may become active within a preset time period. In this case, the tenant prohibition rules stored in MySQL will be retrieved and cached in Redis to improve query efficiency. If a target tenant that was historically active may become inactive within a preset time period, the tenant prohibition rules cached in Redis will be retrieved and persistently stored in MySQL to improve cache utilization efficiency. The changes take effect immediately without requiring a logout or restart, and the pages, interfaces, and resource permissions of all members of the tenant will be immediately re-rendered and hidden.

[0034] S103. Obtain the original role and permission set of the authenticated target user on the RBAC platform, and the tenant prohibition rule corresponding to the target tenant accessed by the target user. Based on the tenant prohibition rule, perform reverse filtering on the original role and permission set to obtain the filtered role and permission set, and synchronize the filtered role and permission set to all relevant microservice nodes of the target tenant in the RBAC platform. In this embodiment, as an optional embodiment, the original role and permission set of the authenticated target user on the RBAC platform, and the tenant prohibition rules corresponding to the target tenant accessed by the target user, are obtained, including: Perform user identity authentication on the target user; Perform tenant identity authentication on the target tenant accessed by the target user; Within the target tenant, query and obtain the target user's target role; In the RBAC platform, obtain the original role permission set corresponding to the target role; In the RBAC platform, the mapping relationship between tenants and storage policies is queried to obtain the storage policy of the target tenant. From the custom resources corresponding to the storage policy, the tenant prohibition rule corresponding to the target tenant is obtained.

[0035] In this embodiment, when a target user logs into the RBAC platform to access the tenant, the authentication module completes the verification of the tenant's identity and the user's identity, and then obtains the target user's original role and permission set on the RBAC platform. For example, if the target user's role is confirmed to be a project administrator, the corresponding original role and permission set is: pages a, b, c, and interfaces API-1 and API-2.

[0036] In this embodiment, the storage policy of the target tenant is obtained by querying the mapping relationship between the target tenant and the storage policy, and the tenant prohibition rules are obtained from the custom resources corresponding to the storage policy. For example, if it is determined that the custom resource corresponding to the storage policy is a tenant CRD, the permission filtering module queries the tenant prohibition rules corresponding to the tenant (tenantId) to which the target user belongs from the tenant CRD, and performs reverse filtering on the original permission set based on the tenant prohibition rules.

[0037] In this embodiment, as an optional embodiment, the original role permission set is reverse-filtered based on the tenant prohibition rule to obtain a filtered role permission set, including: The tenant prohibition rules are parsed. For each prohibition rule obtained from the parsing, a query is performed in the original role permission set. If the prohibition rule is found, it is filtered from the original role permission set to obtain a filtered role permission set.

[0038] In this embodiment, the only optional embodiment is that if the tenant prohibition rule prohibits "page a", then "page a" is removed from the original role permission set to obtain the filtered role permission set; If the tenant's prohibition rule has additional prohibition rules for this role or target user, then the filtering will be overlaid. For example, if the additional prohibition rule is to prohibit "page b", then in the user's set of filtered role permissions, the final permission will only retain "page c".

[0039] In this embodiment, the permission filtering logic adopts the formula: "Original permission set - Prohibited permission set corresponding to tenant prohibition rule = Final effective permission set (filtered role permission set)". As an optional embodiment, in this embodiment, let: P be the original permission set of the role, which is preset by the RBAC platform and cannot be modified; F be the tenant-level prohibited permission set corresponding to the tenant prohibition rule, which is configured by the tenant; U be the user-level additional prohibited permission set (optional); and R be the final effective permission set, satisfying the following formula: R = P - (F∪U) in, P: {p1, p2, ..., pn}, where pi is the i-th resource identifier uniformly allocated by the RBAC platform, such as page ID or interface path; F: {f1, f2, ..., fm}, where fi is the i-th prohibited resource identifier configured by the tenant for the role to which the target user belongs; U: {u1, u2, ..., uk}, where ui is the i-th additional prohibited resource identifier configured by the tenant for the target user, U P; ∪: Set merging operation, the merged set of F and U is the total prohibited permissions of the tenant on the target user.

[0040] In this embodiment, tenant-level reverse prohibition control is used to ensure that the existing role system is not modified; the technology can be implemented based on mainstream cloud-native technology stacks: microservice frameworks (Gin, ClientGo, Kubernetes Operator), caching (Redis Cluster, tenant CRD), message listening (Etcd, List / Watch), and front-end frameworks (Vue3 / React); the permission filtering module can be deployed as an independent middleware and integrated through API gateway plugins without intruding on business service code.

[0041] In this embodiment, as another optional embodiment, a hybrid mode of "reverse prohibition + positive supplementation" can also be adopted, that is, allowing tenants to prohibit some permissions while adding a small number of exclusive permissions in addition to the original permissions of the role. For example, a tenant's project administrator can add "custom report" permission in addition to the default permissions. The core formula is adjusted to: R = (P-(F∪U))∪S (S is the set of positive supplementation permissions for the tenant).

[0042] In this embodiment, as an optional implementation, the filtering role permission set is synchronized to all relevant microservice nodes of the target tenant in the RBAC platform, including: The set of filtered role permissions obtained after filtering based on tenant prohibition rules is returned to the front end through the JSON Web (JWT, JSONWeb Token) interface or the Restful API role permission interface, and simultaneously synchronized to the permission verification cache of the backend interface gateway.

[0043] In this embodiment, the relevant microservice nodes include, but are not limited to: front-end and back-end.

[0044] S104. Control the access permissions of the target user to the target tenant based on the synchronized filtering role permission set.

[0045] In this embodiment, as an optional implementation, the access permissions of the target user to the target tenant are controlled based on a synchronized set of filtered role permissions, including: The front end dynamically renders page resources based on a synchronized set of filtered role permissions. Resources corresponding to permissions not included in the set of filtered role permissions are not displayed, grayed out, or hidden. The backend interface management system intercepts the target user's request, verifies the resources contained in the request, and returns a prohibited access message if the resources contained in the request are not included in the filter role permission set.

[0046] In this embodiment, the front-end controls permissions based on the returned set of filtered roles and permissions. Front-end frameworks, such as Vue and React, dynamically render page resources based on this set. Resources corresponding to permissions not included in the set are not displayed, or are grayed out or hidden. For example, unauthorized pages do not display entry points, and buttons are grayed out or hidden to avoid being visible but unusable.

[0047] For backend control: The interface gateway intercepts all requests from the target user and verifies whether the resource ID (page, interface) of the request is in the filtered role permission set. If it belongs to the tenant prohibition rule, it directly returns the information that access is prohibited, ensuring that the permission control is not bypassed by the frontend.

[0048] In this embodiment, as an optional embodiment, the method further includes: Upon receiving the updated tenant prohibition rule for the target tenant, the system updates the stored tenant prohibition rule and synchronizes the updated tenant prohibition rule to all relevant microservice nodes of the target tenant in the RBAC platform.

[0049] In this embodiment, when the tenant administrator modifies the tenant prohibition rule, the rule storage module stores it in the tenant configuration and cache middleware and it takes effect: the tenant cache configuration is refreshed in real time, the rules for the target user role permissions are calculated in real time, and the configuration is refreshed in real time through the front-end user role permission interface, and the filter role permission set is updated in real time.

[0050] In this embodiment, as an optional implementation, the role permission set is updated in real time based on WebSocket + Redis subscription. As another optional implementation, an HTTP long polling mechanism can be used, suitable for older front-end frameworks that do not support WebSocket. The core logic is that the front-end periodically (at 1-second intervals) requests the rule change interface; if the rules have been updated, the permission set is retrieved again. Alternatively, the permission set can be passed through a RESTful API interface. The front-end renders (menus, pages, buttons) based on the data in the permission set, and the back-end filters the corresponding business interfaces to determine whether the user has the permission to request the interface.

[0051] In this embodiment, after the platform frontend obtains the interface data (updating the tenant prohibition rules), it re-updates the filter role permission set, dynamically updates the rendered page resources, and refreshes the frontend permission cache in real time to ensure that subsequent requests take effect immediately. The entire process does not require restarting the system, and the effect delay is ≤1 second.

[0052] The method in this embodiment can be deployed based on a K8s microservice architecture.

[0053] This embodiment employs a tenant-level reverse control mechanism, distinct from the forward authorization mode in related technologies. It utilizes a core logic of "default inheritance + reverse prohibition," eliminating the need to modify the existing role system of the RBAC platform. Permissions are filtered directly through tenant-level rules, achieving differentiated permissions for the same role and effectively improving role management efficiency. Simultaneously, a non-intrusive architecture design is adopted: fully reusing the existing roles, users, and authentication system of the RBAC platform, only adding a tenant prohibition rule layer. This eliminates the need to refactor the core code of the RBAC platform, lowering the technical implementation threshold, improving solution compatibility and scalability, and effectively reducing deployment and maintenance costs. Furthermore, front-end and back-end collaborative permission control simultaneously covers front-end resource visualization and back-end interface access rights, avoiding security vulnerabilities from single-dimensional control and ensuring the security and consistency of permission control. Moreover, it supports multi-dimensional prohibition rules: supporting three levels of prohibition rules—"platform function + tenant user + resource scope"—meeting the dual needs of overall tenant customization and personalized user permission adjustments, effectively meeting the customization requirements in complex scenarios. In addition, millisecond-level real-time refresh and effectiveness are achieved: the front-end dynamic refresh mechanism ensures that changes to tenant rules take effect immediately without requiring a system restart, adapting to high-frequency permission adjustment scenarios and improving user experience. Specifically, it has the following beneficial technical effects: No need to refactor the existing system: The original role system and permission architecture of the RBAC platform are not changed. Only a tenant prohibition rule layer is added, which reduces the cost of technical transformation and adapts to the upgrade needs of existing cloud-native multi-tenant systems. Enhanced flexibility in permission customization: The same role can quickly achieve permission differentiation in different tenants through tenant prohibition rules. For example, the project administrator in tenant A can see pages a, b, and c, while the project administrator in tenant B can only see page c, thus meeting the customization needs of "multiple tenants and multiple permissions on one RBAC platform". Improved precision of access control: Supports multi-dimensional prohibition control of pages, interfaces, buttons, data, etc., and front-end and back-end collaborative verification to prevent permission leakage or unauthorized access; Operational efficiency optimization: Tenant administrators can configure tenant prohibition rules independently without the need for RBAC platform administrator intervention, reducing communication costs for cross-tenant permission adjustments; Real-time effect enhances user experience: rule changes can be synchronized with the front-end and back-end within 1 second without restarting the application, adapting to high-frequency permission adjustment scenarios (such as temporarily disabling a function). Highly scalable: Based on a cloud-native microservice architecture, it supports horizontal scaling of the number of tenants and the number of tenant prohibition rules, adapting to ultra-large-scale multi-tenant scenarios.

[0054] The method in this embodiment, as an optional embodiment, has several examples of core application scenarios as follows: SaaS-based project management platform: Scenario Description: The platform serves enterprise tenants in different industries (such as the Internet, manufacturing, and government agencies), all of whom use the "Project Administrator" role. However, for Internet enterprise tenants, the "Project Administrator" role needs to access the "Iteration Management" and "Defect Tracking" pages, while for government agency tenants, the "Project Administrator" role only needs to access the "Project Progress" page. This embodiment configures tenant prohibition rules to achieve different permissions for the same role. In this embodiment, the project management interface of tenant A (including page entrances a, b, and c) and the project management interface of tenant B (including only page entrance c) are displayed on the front-end page.

[0055] Enterprise-grade cloud collaboration platform: In this embodiment, the enterprise-level cloud collaboration platform includes functions such as "document management", "meeting management", and "approval process". Due to compliance requirements, a tenant prohibits ordinary user roles from accessing the "approval process" function. By configuring the platform's function disabling rules, the function can be blocked without modifying the original permissions of ordinary user roles.

[0056] Cloud-native application development platform (PaaS): In this embodiment, the cloud-native application development platform provides container deployment and resource scheduling functions for development teams of different sizes. For the "development leader" role in a small team, there is no need to access the "resource quota management" page. Through the tenant-level prohibition rules in this embodiment, only core function permissions are retained, simplifying the operation interface.

[0057] Multi-department shared system: For multi-department shared systems: different departments within the same enterprise act as "tenants" to achieve permission isolation for the same roles between departments; Temporary access control: Tenant administrators can temporarily configure tenant restriction rules to limit certain permissions of a role / user (such as prohibiting modification of configurations during project deployment). The restriction rules can be quickly canceled and permissions restored later.

[0058] Based on the same inventive concept, such as Figure 2 As shown, this embodiment of the invention also provides a role-based access control device, the device comprising: The rule setting module 201 is used to obtain the tenant prohibition rules set by the target tenant in the role-based access control (RBAC) platform; In this embodiment, as an optional implementation, the tenant prohibition rules include, but are not limited to: platform function prohibition rules, tenant user prohibition rules, and resource scope prohibition rules. Among them, Platform feature disabling rules are set to specify one or more platform features that are prohibited from being accessed by the pre-defined first role under the current tenant; Tenant user disable rules are set to apply to pre-defined second roles within the current tenant, overlaying pre-defined additional prohibition rules. Resource scope prohibition rules are set to limit access to specific resource dimensions.

[0059] In this embodiment, as an optional embodiment, the platform function disabling rules, tenant user disabling rules, and resource scope prohibition rules can be adjusted or updated.

[0060] In this embodiment, as an optional implementation, each tenant accesses the RBAC platform via the OAuth2 protocol or the LDAP protocol.

[0061] The rule storage module 202 is used to obtain the corresponding storage policy based on the tenant disabled function list configured by the target tenant, store the tenant prohibition rules, and synchronize the tenant prohibition rules to all relevant microservice nodes of the target tenant in the RBAC platform. In this embodiment, the relevant microservice nodes include, but are not limited to: front-end and back-end.

[0062] In this embodiment, as an optional embodiment, the rule storage module 202 is specifically used for: If the target tenant is determined to be active based on the tenant disabled function list of the target tenant, the corresponding storage policy is a caching policy, and the tenant prohibition rule is stored in the cache; If the target tenant is determined to be inactive based on the tenant disabled feature list of the target tenant, the corresponding storage policy is a persistent storage policy, and the tenant prohibition rule is stored in persistent storage.

[0063] In this embodiment, as an optional implementation, the cache includes, but is not limited to, Redis cache, and the persistent storage includes, but is not limited to, MySQL. As another optional implementation, Kubernetes CRD storage tenant prohibition rules can also be directly adopted; this embodiment does not limit this approach.

[0064] In this embodiment, as another optional embodiment, the rule storage module 202 is further used for: Based on the configuration mapping method of the container orchestration platform, the tenant prohibition rule is sent to all relevant microservice nodes of the target tenant in the RBAC platform.

[0065] In this embodiment, as another optional embodiment, the rule storage module 202 is further used for: Based on the target tenant's pre-set list of disabled tenant functions, adjust the corresponding storage policy.

[0066] The permission reverse filtering module 203 is used to obtain the original role permission set of the authenticated target user on the RBAC platform, as well as the tenant prohibition rule corresponding to the target tenant accessed by the target user, perform reverse filtering on the original role permission set based on the tenant prohibition rule, obtain the filtered role permission set, and synchronize the filtered role permission set to all relevant microservice nodes of the target tenant in the RBAC platform. In this embodiment, as an optional embodiment, the permission reverse filtering module 203 is specifically used for: Perform user identity authentication on the target user; Perform tenant identity authentication on the target tenant accessed by the target user; Within the target tenant, query and obtain the target user's target role; In the RBAC platform, obtain the original role permission set corresponding to the target role; In the RBAC platform, the mapping relationship between tenants and storage policies is queried to obtain the storage policy of the target tenant. From the custom resources corresponding to the storage policy, the tenant prohibition rule corresponding to the target tenant is obtained.

[0067] In this embodiment, as another optional embodiment, the permission reverse filtering module 203 is further used for: The tenant prohibition rules are parsed. For each prohibition rule obtained from the parsing, a query is performed in the original role permission set. If the prohibition rule is found, it is filtered from the original role permission set to obtain a filtered role permission set.

[0068] In this embodiment, the permission filtering logic adopts the following formula: "Original permission set - Prohibited permission set corresponding to tenant prohibition rule = Final effective permission set (filtered role permission set)".

[0069] In this embodiment, as an optional implementation, the set of filtered role permissions is obtained using the following formula: R = P - (F∪U) Where P is the original set of permissions for roles, F is the set of tenant-level prohibited permissions corresponding to the tenant prohibition rule, U is the set of additional prohibited permissions for users, and R is the set of filtered role permissions.

[0070] In this embodiment, as another optional embodiment, the permission reverse filtering module 203 is further used for: The set of filtered role permissions obtained after filtering based on tenant prohibition rules is returned to the front end through a RESTful API interface, and simultaneously synchronized to the permission verification cache of the backend interface gateway.

[0071] The synchronization update module 204 is used to control the access permissions of the target user to the target tenant based on the synchronized filter role permission set.

[0072] In this embodiment, as an optional embodiment, the synchronization update module 204 is specifically used for: The front end dynamically renders page resources based on a synchronized set of filtered role permissions. Resources corresponding to permissions not included in the set of filtered role permissions are not displayed, grayed out, or hidden. The backend interface management system intercepts the target user's request, verifies the resources contained in the request, and returns a prohibited access message if the resources contained in the request are not included in the filter role permission set.

[0073] In this embodiment, as another optional embodiment, the synchronization update module 204 is further used for: Upon receiving the updated tenant prohibition rule for the target tenant, the system updates the stored tenant prohibition rule and synchronizes the updated tenant prohibition rule to all relevant microservice nodes of the target tenant in the RBAC platform.

[0074] Figure 3 This is another schematic diagram of a role-based access control device provided in an embodiment of the present invention. For example... Figure 3 As shown, the device includes: The tenant rule definition module 301 is used to receive access denial rules configured by the tenant administrator; The prohibition rule storage module 302 is used for distributed storage of tenant prohibition rules and supports high-concurrency read and write operations; In this embodiment, the tenant prohibition rules for historically active tenants are stored in a cache, and the tenant prohibition rules for historically inactive tenants are stored in persistent storage.

[0075] The permission filtering module 303 is the core processing module, used to filter the default permissions of roles based on tenant prohibition rules and obtain the set of filtered role permissions. The front-end and back-end collaboration control module 304 is used to synchronize the visibility of front-end resources and the access rights of back-end interfaces in order to obtain a set of filtered role permissions. The real-time refresh and activation module 305 is used to ensure that changes to tenant prohibition rules take effect immediately, so as to update the obtained set of filtered role permissions in real time.

[0076] Based on the same inventive concept, embodiments of the present invention also provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the role-based access control method in any of the above possible implementations.

[0077] Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0078] Based on the same inventive concept, see [link to inventive concept] Figure 4 This invention also provides an electronic device, including a memory 101 (e.g., non-volatile memory), a processor 102, and a computer program stored on the memory 101 and executable on the processor 102. When the processor 102 executes the program, it implements the steps of the role-based access control method in any of the above possible implementations, which can be equivalent to the aforementioned role-based access control device. Of course, the processor can also be used to process other data or perform calculations. This electronic device can be a PC, server, terminal, or other similar device.

[0079] like Figure 4 As shown, the electronic device may also include: memory 103, network interface 104, and internal bus 105. In addition to these components, other hardware may also be included, which will not be described in detail here.

[0080] It should be noted that the above-mentioned role-based access control device can be implemented by software. As a logical device, it is formed by the processor 102 of the electronic device in which it is located reading the computer program instructions stored in the non-volatile memory into the memory 103 for execution.

[0081] The embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, the program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0082] The processing and logic flow described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flow can also be executed by special-purpose logic circuitry—such as FPGA (Field Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit), and the device can also be implemented as special-purpose logic circuitry.

[0083] Suitable computers for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0084] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0085] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily used to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0086] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0087] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0088] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0089] The above are merely specific embodiments of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A role-based permission management method, characterized by, The method comprises the following steps: obtaining a tenant disabling rule set by a target tenant in a role-based access control (RBAC) platform; storing the tenant disabling rule in a corresponding storage strategy according to a tenant disabling function list configured by the target tenant, and synchronizing the tenant disabling rule to all related micro-service nodes of the target tenant in the RBAC platform; obtaining a set of original role permissions of a target user authenticated in the RBAC platform, and a tenant disabling rule corresponding to a target tenant accessed by the target user, performing reverse filtering on the set of original role permissions based on the tenant disabling rule, obtaining a set of filtered role permissions, and synchronizing the set of filtered role permissions to all related micro-service nodes of the target tenant in the RBAC platform; controlling the permission of the target user to access the target tenant based on the synchronized set of filtered role permissions.

2. The role-based rights management method of claim 1, wherein, The step of storing the tenant disabling rule in a corresponding storage strategy according to a tenant disabling function list configured by the target tenant comprises the following steps: if it is determined that the target tenant is active based on the tenant disabling function list of the target tenant, the corresponding storage strategy is a cache strategy, and the tenant disabling rule is stored in the cache; if it is determined that the target tenant is not active based on the tenant disabling function list of the target tenant, the corresponding storage strategy is a persistent storage strategy, and the tenant disabling rule is stored in a persistent storage.

3. The role-based rights management method of claim 2, wherein, The step of synchronizing the tenant disabling rule to all related micro-service nodes of the target tenant in the RBAC platform comprises the following step: sending the tenant disabling rule to all related micro-service nodes of the target tenant in the RBAC platform based on a configuration mapping method of a container orchestration platform.

4. The role-based rights management method of claim 3, wherein, The method further comprises the following step: adjusting the corresponding storage strategy according to a pre-configured tenant function disabling list record of the target tenant.

5. The role-based rights management method according to any one of claims 1 to 4, characterized in that, The steps of obtaining a set of original role permissions of a target user authenticated in the RBAC platform, and a tenant disabling rule corresponding to a target tenant accessed by the target user comprise the following steps: performing user identity authentication on the target user; performing tenant identity authentication on the target tenant accessed by the target user; querying a target role of the target user in the target tenant; obtaining a set of original role permissions corresponding to the target role in the RBAC platform; querying a mapping relationship between tenants and storage strategies in the RBAC platform, obtaining a storage strategy of the target tenant, and obtaining a tenant disabling rule corresponding to the target tenant from a custom resource corresponding to the storage strategy.

6. The role-based rights management method of claim 5, wherein, The step of performing reverse filtering on the set of original role permissions based on the tenant disabling rule to obtain a set of filtered role permissions comprises the following steps: parsing the tenant disabling rule, querying the set of original role permissions for each disabling rule obtained by the parsing, filtering the disabling rule from the set of original role permissions if the disabling rule is queried, and obtaining a set of filtered role permissions.

7. The role-based rights management method of claim 5, wherein, The step of synchronizing the set of filtered role permissions to all related micro-service nodes of the target tenant in the RBAC platform comprises the following step: The filtered role permission set based on the tenant prohibition rule is returned to the front end through a RestFul API role permission interface, and is simultaneously synchronized to a permission verification cache of a back-end interface gateway.

8. A role-based rights management apparatus, characterized by comprising: The role-based permission management apparatus comprises: A rule setting module configured to acquire a tenant prohibition rule set by a target tenant in a role-based access control (RBAC) platform; A rule storage module configured to acquire a corresponding storage strategy based on a tenant disabled function list configured by the target tenant, store the tenant prohibition rule, and synchronize the tenant prohibition rule to all related micro-service nodes of the target tenant in the RBAC platform; A permission reverse filtering module configured to acquire an original role permission set of the target user in the RBAC platform after authentication, and a tenant prohibition rule corresponding to a target tenant accessed by the target user, perform reverse filtering on the original role permission set based on the tenant prohibition rule, acquire a filtered role permission set, and synchronize the filtered role permission set to all related micro-service nodes of the target tenant in the RBAC platform; A synchronization updating module configured to control a permission of the target user to access the target tenant based on the synchronized filtered role permission set.

9. A storage medium, characterized by A program or instruction is stored on a storage medium, and the program or instruction is run by a processor to implement the steps of the role-based permission management method according to any one of claims 1 to 7.

10. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the steps of the role-based permission management method according to any one of claims 1 to 7 when executing the program.

Images