User authority configuration method, device, electronic device and storage medium

Abstract

The present application discloses a user authority configuration method, device, electronic device and storage medium, which relates to the field of computer technology, including determining a permission tree structure of a custom role based on a permission set of a custom role, each permission code in the permission set corresponds to a tree node in the permission tree structure, and determining the hierarchical information of the tree node corresponding to the permission code based on the hierarchical information represented by the permission code; adding a user to the custom role to determine the custom role to which the user belongs; determining the user's permission information based on the permission set of the custom role to which the user belongs; in response to a shielding operation on the target permission of any custom role, determining the permission code to be shielded based on the target permission of the custom role and the target permission tree structure, and updating the user's permission information based on the permission code to be shielded. The present application solves the technical problem of poor flexibility in adjusting the permission inheritance relationship, and achieves the technical effect of improving the flexibility of adjusting the permission inheritance relationship.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device, and storage medium for configuring user rights. Background Art

[0002] Early access control models, such as Access Control Lists (ACLs), required individual permissions to be configured for each user. This resulted in extremely high maintenance costs as the user base expanded or the organizational structure changed. To address these issues, the Role-Based Access Control (RBAC) model emerged. This model manages user access to system resources by assigning users to specific roles and defining permissions for those roles, reducing the complexity of user permission configuration.

[0003] However, the role hierarchy of the RBAC model is fixed, and the permission inheritance relationship cannot be dynamically adjusted, resulting in poor flexibility. Summary of the Invention

[0004] The present application provides a user authority configuration method, device, electronic device and storage medium to at least solve the problem in related technologies that the authority inheritance relationship cannot be dynamically adjusted and the flexibility is poor.

[0005] This application provides a user rights configuration method, including:

[0006] Create multiple custom characters;

[0007] Determine a permission set of the custom role based on the attribute information of the custom role, wherein the permission set includes multiple permission codes, and each permission corresponds to a permission code;

[0008] Based on the permission set of the custom role, determine the permission tree structure of the custom role, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and based on the hierarchical information represented by the permission code, determine the hierarchical information of the tree node corresponding to the permission code;

[0009] Add users to custom roles to determine the custom roles to which users belong;

[0010] Determine the user's permission information based on the permission set of the user's custom role;

[0011] In response to a masking operation on the target permission of any custom role, the permission code to be masked is determined based on the target permission and target permission tree structure of the custom role, and the permission set of the custom role and the permission information of the user corresponding to the custom role are updated based on the permission code to be masked.

[0012] This application also provides a user rights configuration device, including:

[0013] Creation module for creating multiple custom roles;

[0014] A first determination module is configured to determine a permission set of the custom role based on attribute information of the custom role, wherein the permission set includes a plurality of permission codes, and each permission corresponds to a permission code;

[0015] A second determination module is configured to determine a permission tree structure of the custom role based on the permission set of the custom role, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and hierarchical information of the tree node corresponding to the permission code is determined based on hierarchical information represented by the permission code;

[0016] The third determination module is used to add a user to the custom role to determine the custom role to which the user belongs;

[0017] A fourth determination module is used to determine the user's permission information based on the permission set of the user's custom role;

[0018] The fifth determination module is used to respond to the shielding operation of the target permission of any custom role, determine the permission code to be shielded based on the target permission and target permission tree structure of the custom role, and update the permission set of the custom role and the permission information of the user corresponding to the custom role based on the permission code to be shielded.

[0019] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned user authority configuration methods when executing the computer program.

[0020] The present application also provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, the steps of any of the above-mentioned user authority configuration methods are implemented.

[0021] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned user authority configuration methods when executed by a processor.

[0022] Through this application, due to the creation of multiple custom roles; based on the attribute information of the custom role, the permission set of the custom role is determined, wherein the permission set includes multiple permission codes, and each permission corresponds to a permission code; based on the permission set of the custom role, the permission tree structure of the custom role is determined, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and the hierarchical information of the tree node corresponding to the permission code is determined based on the hierarchical information represented by the permission code; users are added to the custom role to determine the custom role to which the user belongs; based on the permission set of the custom role to which the user belongs, the permission information of the user is determined; in response to the shielding operation of the target permission of any custom role, based on the target permission of the custom role and the target permission tree structure, the permission code to be shielded is determined, and the permission set of the custom role and the permission information of the user corresponding to the custom role are updated based on the permission code to be shielded. The dynamic adjustment of the permission inheritance relationship is achieved through the permission tree structure, therefore, the technical problem that the related technology cannot dynamically adjust the permission inheritance relationship and has poor flexibility can be solved, and the technical effect of dynamically adjusting the permission inheritance relationship and improving flexibility is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0024] Figure 1 A schematic diagram of the structure of a user rights configuration system provided in an embodiment of the present application;

[0025] Figure 2 A flowchart of a method for configuring user rights provided in an embodiment of the present application;

[0026] Figure 3 A flowchart of another method for configuring user rights provided in an embodiment of the present application;

[0027] Figure 4 A flowchart of another user rights configuration method provided in an embodiment of the present application;

[0028] Figure 5 An interactive diagram for configuring user permissions provided in an embodiment of the present application;

[0029] Figure 6 A schematic diagram of the structure of a user rights configuration device provided in an embodiment of the present application;

[0030] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0032] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0033] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0034] Early access control models, such as ACLs, implemented resource access control by configuring permissions for each user. Specifically, permissions were directly tied to users, requiring system administrators to individually configure a list of accessible resources (such as pages, operations, and data) for each user. This static configuration approach required individual modifications to the user-permission relationship whenever permissions were changed, resulting in high maintenance costs. For example, permissions needed to be reconfigured each time a new user was added, making it easy to omit or conflict permissions during permission adjustments. Furthermore, early access control models struggled to adapt to dynamic business needs. When organizational structures or user roles changed in institutions like schools, user permissions required frequent manual adjustments, preventing batch management through abstraction layers. This direct per-user permission configuration approach easily led to over-allocation of permissions, violating the principle of least privilege. Furthermore, misconfigured permissions could easily grant users access to sensitive data, increasing the risk of data leakage. The principle of least privilege states that each user, process, or component in a system should be granted only the minimum permissions necessary to complete its tasks, and should not have any additional permissions.

[0035] To solve the above problems, the RBAC model came into being. This model indirectly manages user access to system resources by assigning users to specific roles and defining permissions for these roles, reducing the complexity of user permission configuration.

[0036] However, the RBAC model's fixed role hierarchy prevents dynamic adjustment of permission inheritance, resulting in limited flexibility. Furthermore, as business complexity increases, the number of roles grows exponentially, significantly increasing the cost of configuring and maintaining permissions. For example, adjusting permissions for a role in a large organization requires traversing all associated users of that role to adjust permissions, a cumbersome operation and making it difficult to ensure consistency. The RBAC model lacks support for batch permission management and cannot achieve efficient inheritance and overrides through abstraction levels, making the system difficult to adapt to dynamic business scenarios.

[0037] Moreover, permission changes rely on manual operations, and misconfiguration may lead to sensitive data leakage or function abuse. For example, mistakenly enabling data deletion permissions may cause irreversible data loss, posing a high security risk.

[0038] In order to solve the above problems, an embodiment of the present application provides a user permission configuration method, the method comprising: creating multiple custom roles; determining a permission set of the custom role based on the attribute information of the custom role, wherein the permission set includes multiple permission codes, each permission corresponding to a permission code; determining a permission tree structure of the custom role based on the permission set of the custom role, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and determining the hierarchical information of the tree node corresponding to the permission code based on the hierarchical information represented by the permission code; adding a user to the custom role to determine the custom role to which the user belongs; determining the permission information of the user based on the permission set of the custom role to which the user belongs; in response to a masking operation on the target permission of any custom role, determining the permission code to be masked based on the target permission of the custom role and the target permission tree structure, and updating the permission set of the custom role and the permission information of the user corresponding to the custom role based on the permission code to be masked. The method provided by the above scheme can determine the inheritance relationship between the permissions of the custom role based on the permission tree structure of the custom role, and then dynamically adjust the permission inheritance relationship through the permission tree structure, thereby achieving the technical effect of dynamically adjusting the permission inheritance relationship and improving the flexibility of permission adjustment.

[0039] And through the customized role permission tree structure, fine control and batch management of permissions can be achieved to adapt to complex business scenarios.

[0040] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the user authority configuration method depends, the specific application environment architecture or specific hardware architecture is described here.

[0041] The user rights configuration method, device, electronic device and storage medium provided in the embodiments of the present application are suitable for configuring user rights. Figure 1As shown, it is a structural diagram of the user permission configuration system based on the embodiment of the present application, which mainly includes a client and an artificial intelligence (AI) platform, wherein the AI ​​platform is used to create multiple custom roles; based on the attribute information of the custom role, the permission set of the custom role is determined, wherein the permission set includes multiple permission codes, and each permission corresponds to a permission code; based on the permission set of the custom role, the permission tree structure of the custom role is determined, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and the hierarchical information of the tree node corresponding to the permission code is determined based on the hierarchical information represented by the permission code; a user is added to the custom role to determine the custom role to which the user belongs; based on the permission set of the custom role to which the user belongs, the permission information of the user is determined; in response to the client's shielding operation on the target permission of any custom role, the permission code to be shielded is determined based on the target permission and the target permission tree structure of the custom role, and the permission set of the custom role and the permission information of the user corresponding to the custom role are updated based on the permission code to be shielded.

[0042] The embodiment of the present application provides a user rights configuration method, which is applied to an AI platform. Figure 2 A flowchart of the user rights configuration method provided in the embodiment of the present application is shown in FIG. Figure 2 As shown, the process includes:

[0043] Step S201: Create multiple custom roles.

[0044] The AI ​​platform comes with multiple pre-configured basic roles, such as super administrator, system administrator, group administrator, auditor, and ordinary user. Each basic role is associated with an initial set of permissions, which cannot be changed.

[0045] The AI ​​platform supports the creation of custom roles. System administrators can define the name, permission description, and permission configuration of custom roles through a visual interface. The permission configuration includes all functional permissions under the role by default.

[0046] It should be noted that a parent-child relationship can exist between multiple custom roles created, in which the permissions of the child role inherit the permissions of the parent role by default.

[0047] Step S202: determining a permission set of the custom role based on the attribute information of the custom role, wherein the permission set includes a plurality of permission codes, and each permission corresponds to a permission code.

[0048] Among them, the attribute information of the custom role may include super administrator, system administrator, group administrator, auditor, ordinary user, etc. It should be noted that when the attribute information of the custom role is super administrator, the permission set of the custom role is consistent with the initial permission set of the super administrator basic role; when the attribute information of the custom role is system administrator, the permission set of the custom role is consistent with the initial permission set of the system administrator basic role; when the attribute information of the custom role is group administrator, the permission set of the custom role is consistent with the initial permission set of the group administrator basic role; when the attribute information of the custom role is auditor, the permission set of the custom role is consistent with the initial permission set of the auditor basic role; when the attribute information of the custom role is ordinary user, the permission set of the custom role is consistent with the initial permission set of the ordinary user basic role. The permission set is the aforementioned permission configuration.

[0049] It should be further noted that you can adjust the permissions of a custom role by adjusting the permission configuration. Permissions can be menus or business operations. In other words, each menu or business operation corresponds to a permission code. For example, the permission code may be "User Management: Add".

[0050] Step S203: Determine the permission tree structure of the custom role based on the permission set of the custom role, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and determine the hierarchical information of the tree node corresponding to the permission code based on the hierarchical information represented by the permission code.

[0051] Each permission code corresponds to a tree node in the permission tree structure, and each tree node has a unique tree node code. In other words, each permission code is bound to a unique tree node code, namely tree_id. tree_id can represent the hierarchy and subordinate management of permission codes. The permission tree structure can be used to customize the hierarchical display of permissions for roles and the hierarchical blocking of permissions. For example, if the user group's secondary menu permissions are blocked, the user group's secondary menu permissions and the tab pages and operation permissions within the secondary menu will also be blocked.

[0052] Step S204: Add the user to the custom role to determine the custom role to which the user belongs.

[0053] It is understandable that the user belongs to the custom role to which the user is added.

[0054] There are also pre-added users in multiple basic roles. According to the initial permission set of the basic role, the permission information of the user corresponding to the basic role is determined.

[0055] Specifically, member management is performed in a custom role. Adding a member is adding a user to determine the custom role to which the user belongs.

[0056] Step S205: Determine the permission information of the user based on the permission set of the custom role to which the user belongs.

[0057] It is understandable that the permissions corresponding to the permission codes included in the permission set of the user's custom role are the permissions possessed by the user. In other words, the user's permission information is determined according to the permission set of the user's custom role.

[0058] Step S206, in response to the masking operation of the target permission of any custom role, based on the target permission and the target permission tree structure of the custom role, determine the permission code to be masked, and update the permission set of the custom role and the permission information of the user corresponding to the custom role based on the permission code to be masked.

[0059] The target permission tree structure can be used to determine the inheritance relationship between permissions. When shielding the target permission of any custom role, multiple permissions that have an inheritance relationship with the target permission can be determined based on the target permission tree structure of the custom role. The target permission and the multiple permissions that have an inheritance relationship with the target permission can be used as permissions to be shielded. Based on the permissions to be shielded, the permission code to be shielded can be determined. Based on the permission code to be shielded, the permission set of the custom role, the target permission tree structure, and the permission information of the user corresponding to the custom role can be updated.

[0060] It can be understood that the embodiment of the present application realizes dynamic batch adjustment of user permissions through the permission tree structure. For example, if it is necessary to modify the user permissions under a custom role in the AI ​​platform, directly select the custom role in the role module, and modify the permission configuration of the custom role according to the permission tree structure of the custom role. After the modification is completed, all users belonging to the custom role will no longer have user permissions, thereby realizing efficient and quick completion of user permission changes.

[0061] The user authority configuration method provided by the embodiment of the present application is through creating multiple custom roles; based on the attribute information of the custom role, determining the permission set of the custom role, wherein the permission set includes multiple permission codes, and each permission corresponds to a permission code; based on the permission set of the custom role, determining the permission tree structure of the custom role, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and the hierarchical information of the tree node corresponding to the permission code is determined based on the hierarchical information represented by the permission code; adding users to the custom role to determine the custom role to which the user belongs; determining the user's permission information based on the permission set of the custom role to which the user belongs; in response to the shielding operation of the target permission of any custom role, determining the permission code to be shielded based on the target permission and the target permission tree structure of the custom role, and updating the permission set of the custom role and the permission information of the user corresponding to the custom role based on the permission code to be shielded. The dynamic adjustment of the permission inheritance relationship is achieved through the permission tree structure, thereby solving the technical problem that the related technology cannot dynamically adjust the permission inheritance relationship and has poor flexibility, and achieving the technical effect of dynamically adjusting the permission inheritance relationship and improving flexibility.

[0062] The embodiment of the present application provides a user rights configuration method, which is applied to an AI platform. Figure 3 A flowchart of the user rights configuration method provided in the embodiment of the present application is shown in FIG. Figure 3 As shown, the process includes:

[0063] Step S301: Create multiple custom roles. Figure 2 Step S201 of the illustrated embodiment will not be described in detail here.

[0064] Step S302: Based on the attribute information of the custom role, determine the permission set of the custom role, wherein the permission set includes multiple permission codes, and each permission corresponds to a permission code. Figure 2 Step S202 of the illustrated embodiment will not be described in detail here.

[0065] Step S303: Based on the permission set of the custom role, determine the permission tree structure of the custom role, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and the hierarchical information of the tree node corresponding to the permission code is determined based on the hierarchical information represented by the permission code. Figure 2 Step S203 of the illustrated embodiment will not be described in detail here.

[0066] Step S304: Add the user to the custom role to determine the custom role to which the user belongs. Figure 2 Step S204 of the illustrated embodiment will not be described in detail here.

[0067] Step S305: Determine the user's permission information based on the permission set of the user's custom role. Figure 2 Step S205 of the illustrated embodiment will not be described in detail here.

[0068] Step S306, in response to the masking operation on the target permission of any custom role, based on the target permission and the target permission tree structure of the custom role, determine the permission code to be masked, and update the permission set of the custom role and the permission information of the user corresponding to the custom role based on the permission code to be masked.

[0069] Specifically, the above step S306 includes:

[0070] Step S3061: Based on the target permission of the custom role, determine the target permission code corresponding to the target permission.

[0071] Step S3062: Based on the target authority code, obtain the target authority matrix corresponding to the target authority code.

[0072] Each permission code corresponds to a permission matrix, and permission configuration is performed on the permission matrix of the permission code. For permission codes corresponding to configurable menus or operations, set the configurable field is_allowed_edit to 1, assign a corresponding tree_id, and set the Chinese or English name of the permission code. The permission matrix of the permission code includes information such as tree_id, permission name, is_allowed_edit, whether it is configurable, and permission description.

[0073] The editing authorization function interface supports the settings of the tree_id, is_allowd_edit, and permission name (name) fields, that is, these fields can be set. Among them, the is_allowd_edit field indicates whether it is configurable. Based on the is_allowd_edit field, the configurable permissions of the user permission configuration page can be determined. The name field represents the name of the menu or operation, that is, the permission name. This field is used to display the permission name on the user permission configuration page. Among them, the user permission configuration page includes the user's permission information. Administrators can dynamically adjust permissions based on the permission matrix table. Among them, the permission matrix table is shown in Table 1, and each row corresponds to a permission matrix of a permission code.

[0074] Table 1

[0075]

[0076] Step S3063: Determine whether the target permission supports the configuration based on the target permission matrix.

[0077] It is understood that whether the target permission supports configuration is determined based on the is_allowed_edit field in the target permission matrix. If the is_allowed_edit field is 1, the target permission supports configuration, and if the is_allowed_edit field is 0, the target permission does not support configuration.

[0078] It should be noted that the permissions in a custom role can be preset to support configuration.

[0079] Furthermore, based on this permission matrix, you can filter by multiple dimensions, such as roles and permission sets, to improve the efficiency of role permission configuration. Furthermore, combined with configurable fields, it supports flexible override and inheritance permission rules.

[0080] Step S3064: If the target permission supports configuration, the permission code to be blocked is determined based on the target permission code and the target permission tree structure.

[0081] It is understood that a child role can override the parent role's permission configuration by setting the is_allowed_edit field to 1. For example, if the parent role has the Create User Group permission, the child role inherits this permission. If the is_allowed_edit field of the child role's Create User Group permission is 1, the child role can block this Create User Group permission.

[0082] The user rights configuration method provided by the embodiments of the present application uses the target rights matrix to determine whether the target rights support configuration. Only when configuration is supported does it further determine the permission code to be blocked. This avoids invalid operations on permissions that are not allowed to be configured, improving the accuracy and efficiency of rights management. For example, basic permissions that are fixed in some systems and cannot be arbitrarily changed will not be misoperated.

[0083] In some optional implementations, the above step S3064 includes:

[0084] Step a1: Based on the target permission code and the target permission tree structure, determine the target tree node of the target permission code in the target permission tree structure.

[0085] Step a2: If the target tree node has a descendant tree node, the permission code corresponding to the descendant tree node of the target tree node and the target permission code are used as the permission code to be masked.

[0086] The descendant tree nodes refer to all child nodes of the target tree node and the child nodes of its child nodes, and all level nodes recursively.

[0087] Step a3: If the target tree node does not have a descendant tree node, the target permission code is used as the permission code to be masked.

[0088] In the user rights configuration method provided by the embodiments of this application, when a target tree node has descendant tree nodes, the permission code corresponding to the descendant tree node and the target permission code are used together as the permission code to be blocked. This allows batch operations when blocking a certain permission and its related sub-permissions, eliminating the need to search and set each one individually, greatly improving the efficiency of rights management.

[0089] In some optional implementations, the above user rights configuration method further includes:

[0090] Step b1: Cache the permission set of the custom role to the client.

[0091] In step b2, whenever the permission set of a custom role is updated, the permission set of the custom role cached by the client is updated based on the updated permission set of the custom role, so that when any user performs a target operation, it is determined whether the user has the permission to perform the target operation based on the permission set of the custom role to which the user belongs. If the user has the permission to perform the target operation, the user is allowed to perform the target operation.

[0092] The client caches the permission set of the custom role to achieve immediate effect. That is, if the user who belongs to the custom system administrator role needs to cancel the modify role permission, the user can uncheck the modify role permission under the user in the role module through the AI ​​platform. After the setting is completed, the role permission is synchronized to the client in real time, that is, all users belonging to the role will cancel the modify role permission.

[0093] Furthermore, the AI ​​platform can employ interceptor technology. When a user initiates a target operation, the platform determines whether the user has permission to perform the target operation based on the permission set of the user's custom role. If the user has permission to perform the target operation, the user is allowed to perform the target operation. If the permission configuration cancels the role modification permission for the user's role, the user will not have the role modification permission when logging into the AI ​​platform.

[0094] The user rights configuration method provided in the embodiments of the present application caches the permission set of a custom role on the client. This eliminates the need for the client to request permission information from the server each time the user performs a target operation. Instead, the client can directly read the permission set data from the local cache to determine the user's rights. This significantly reduces network interaction with the server, reduces network latency, and enables faster operation responses, resolving the issue of a lack of a real-time validation mechanism for user rights configuration in related technologies.

[0095] In some optional implementations, the above user rights configuration method further includes:

[0096] Step c1: When the permission set of any custom role is updated, the update information is recorded in the audit log, wherein the update information includes the update operator, update time and update content.

[0097] That is to say, after the permissions of each custom role are configured, all permission change operations must be recorded in the audit log, including the operator (i.e., the update operator), update time, priority, modified content (i.e., updated content), etc.

[0098] The user authority configuration method provided by the embodiment of the present application solves the shortcomings of the related art in lacking an audit log tracking function, and can quickly trace erroneous operations or malicious behaviors based on the audit log.

[0099] In some optional implementations, the above user rights configuration method further includes:

[0100] Step d1: When the permission set of any custom role is updated, a historical version of the permission set of the custom role is saved.

[0101] Step d2: After the permission set of any custom role is updated, in response to a permission rollback operation, the permission set of the custom role is restored based on a historical version of the permission set of the custom role.

[0102] The AI ​​platform supports rollback of permission set changes to prevent system anomalies caused by misoperation. It is understood that if the permission set of a custom role is restored, the permission tree structure of the custom role and the permission information of the user corresponding to the custom role will also be restored to the historical version.

[0103] The user permission configuration method provided in the embodiment of the present application avoids system function abnormalities, data leakage and other problems caused by incorrect permission configuration by supporting the rollback function of permission set changes, thereby ensuring stable and secure operation of the system.

[0104] In some optional implementations, the above step S303 includes:

[0105] Step e1: for any permission code in the permission set, determine the number of separators in the permission code. The permission code uses separators to represent the hierarchical relationship. For example, if the permission code is "User Management: Add", the separator can be ":".

[0106] Step e2: determining the level information represented by the permission code based on the number of separators in the permission code.

[0107] If the number of separators in the permission code is 0, the level information represented by the permission code is the first level; if the number of separators in the permission code is 1, the level information represented by the permission code is the second level; if the number of separators in the permission code is 2, the level information represented by the permission code is the third level, and so on. The first level, second level, and third level are the menus or operation levels of the permissions corresponding to the permission codes.

[0108] Step e3: determining the tree node code of the tree node corresponding to the permission code based on the hierarchical information represented by the permission code, so as to obtain the tree node codes of the tree nodes corresponding to all the permission codes in the permission set.

[0109] The tree node code uses a tree structure format with the following structure: level 1, level 2, level 3, etc., supporting hierarchical expansion. Levels 1, 2, and 3 represent the menu or operation levels of the permissions corresponding to the permission code. The blocking logic is that if the role permission of the level 1 node is blocked, all its child nodes will automatically become invalid and the permissions will be blocked.

[0110] For example, the tree node code of the first-level menu "User Management" is "1", the tree node code of the second-level menu "User Group" is "1.1", and the tree node code of the third-level operation "Create User Group" is "1.1.1". The parent-child node relationship is identified by numbers separated by decimal points, and the tree node code of the parent node is the prefix of the child node. It can be understood that different first-level menus correspond to different tree node codes, different second-level menus correspond to different tree node codes, and different third-level operations correspond to different tree node codes. In other words, different permission codes correspond to different tree node codes, that is, the corresponding tree nodes are different, and each permission corresponds to a unique tree node code.

[0111] Step e4: Based on the tree node codes of the tree nodes corresponding to all the permission codes in the permission set, determine whether the tree node code of the tree node corresponding to the first permission code in the permission set is a prefix of the tree node code of the tree node corresponding to the second permission code.

[0112] The first permission code may be any permission code in the permission set, and the second permission code is a permission code different from the first permission code.

[0113] Step e5: If there is a tree node in the permission set whose tree node code corresponding to the first permission code is a prefix of the tree node code corresponding to the second permission code, then determine that the tree node corresponding to the first permission code is the parent node of the tree node corresponding to the second permission code, and the tree node corresponding to the second permission code is the child node of the tree node corresponding to the first permission code.

[0114] It can be understood that if the tree node code of the tree node corresponding to the first permission code in the permission set is a prefix of the tree node code of the tree node corresponding to the second permission code, then the association relationship between the tree node corresponding to the first permission code and the tree node corresponding to the second permission code is determined to be a parent-child relationship.

[0115] Step e6: constructing a permission tree structure of the custom role based on the tree node codes of the tree nodes corresponding to all permission codes in the permission set and the association relationship between the tree nodes corresponding to all permission codes in the permission set, wherein the association relationship includes a parent-child relationship.

[0116] In some optional implementations, the above step b2 includes:

[0117] Step b21: Based on the updated permission set of the custom role, determine incremental permission set update information between the updated permission set of the custom role and the permission set of the custom role before the update.

[0118] Step b22: Based on the incremental permission set update information, the permission set of the custom role cached by the client is updated.

[0119] The user permission configuration method provided in the embodiment of the present application, compared to pushing the complete updated permission set with each update, only transmits the changed part of the permission set in incremental updates, avoiding the complex operation of replacing the entire data, significantly reducing network latency, ensuring that the user permission configuration takes effect immediately, and improving the user operation response speed.

[0120] The embodiment of the present application provides a user rights configuration method, which is applied to an AI platform. Figure 4 A flowchart of the user rights configuration method provided in the embodiment of the present application is shown in FIG. Figure 4 As shown, the process includes:

[0121] The first step is role definition and hierarchical modeling. This step includes creating custom roles, configuring permissions in a visual interface, and managing hierarchical tree structures. For details, please refer to steps S201 to S203 above and will not be repeated here.

[0122] The second step is the dynamic configuration mechanism for permissions. This step includes defining the permission matrix, binding unique tree node codes, configuring permission inheritance and overwriting, and dynamically adjusting the permission matrix. Please refer to the description of the corresponding section above for details and will not be repeated here.

[0123] The third step is dynamic permission adjustment and effectiveness. This step includes front-end caching permission list, batch adjustment of role permissions, instant synchronization to the client, and back-end interceptor verification of permission code. Among them, the front-end caches the permission list, that is, the client caches the permission set of custom roles. For batch adjustment of role permissions, please refer to the relevant description of the aforementioned step S206, which will not be repeated here. For instant synchronization to the client, please refer to the relevant description of the aforementioned step b2, which will not be repeated here. The back-end interceptor verifies the permission code, that is, the AI ​​platform can use interceptor technology to intercept operations initiated by users that do not have permission.

[0124] Step 4: Security audit and log tracking. This step includes recording operation logs, storing the modification content, operator, and time, and supporting permission rollback. For details, please refer to the descriptions of steps c1, d1, and d2 above and will not be repeated here.

[0125] The user rights configuration method provided in the embodiments of this application overcomes the limitations of the traditional RBAC model in complex business scenarios, providing an efficient, secure, and scalable access control solution for AI platforms. This enables precise control of access resources for different users and reduces the risks caused by improper rights management or operational errors. In response to the shortcomings of the traditional RBAC model, the embodiments of this application are dedicated to enhancing the flexibility and dynamism of rights configuration, supporting batch management and achieving immediate effectiveness, thereby reducing maintenance costs, preventing excessive rights allocation, improving system security, and reducing the risk of misoperation through audit logs and rights rollback functions.

[0126] To make the user authority configuration method of the embodiment of the present application clearer, the following Figure 5 The interactive diagram for configuring user permissions is shown in the following example. Figure 5As shown, the AI ​​platform supports basic roles and custom roles. The system administrator in the basic role has all permissions under the user management module. The system administrator enters the account and password on the AI ​​platform's login interface to log in to the AI ​​platform, enters the AI ​​platform's role management module, and uses the role management module to create custom roles with system administrator, group administrator, auditor, and ordinary user as permission attributes. It is understood that custom roles created through the role management module are saved to the database. Custom roles have permission configuration capabilities. System administrators can modify the permission configuration of custom roles and save the permission configuration of custom roles to the database. After a custom role is successfully created, permissions can be configured multiple times. Based on the set of permissions that have and can be configured, some menus or operation permissions can be blocked to form the permissions of new roles. The system administrator creates users through the user management module and selects the users to be granted permissions to determine the roles to which the users belong. The permission configuration of the role to which the users belong is determined as the permission configuration of the user to complete the user empowerment. It should be noted that the AI ​​platform also includes other modules.

[0127] The following describes the permission configuration of AI platform users using a custom role with the permission attributes of system administrator, group administrator, auditor, and ordinary user:

[0128] The system administrator has all permissions under the user management module. A custom role created with the system administrator as the permission attribute can set permissions for users, user groups, and role modules under the user management module in the permission configuration. Therefore, after logging into the AI ​​platform, users under the custom role created with the system administrator as the permission attribute will have permissions related to users, user groups, and roles. When there is a business need to modify a permission attribute of a user under the custom role, such as canceling the role module permission, the role module can be blocked in the permission configuration. In this case, all users under the custom role will not have the role module permission when logging into the AI ​​platform.

[0129] Group administrators have permissions in the User module, but not in the User Group and Role modules. Custom roles created with Group Administrator as the permission attribute can select permissions in the User module during permission configuration, but cannot configure permissions in the User Group and Role modules. Therefore, users in custom roles created with Group Administrator as the permission attribute will have user-related permissions after logging into the AI ​​platform. If business requirements require that group administrators not be able to create users, the User Creation permission can be disabled in the Permission Configuration. Once this permission is disabled, users in this custom role will not have the ability to create users after logging into the AI ​​platform.

[0130] Auditors only have the right to query basic user information and quota permission information. Therefore, custom roles created with Auditor as the permission attribute can only be configured to query basic user information and quota permission information in the permission configuration. Sub-menus under Basic User Information and Permission Quota Information cannot be configured. Users assigned to this custom role can only query the Basic User Information and Quota Permission Information pages and cannot perform other operations. If the permissions of this custom role are blocked, users with this custom role will be prompted that they do not have any permissions when logging into the AI ​​platform.

[0131] Ordinary users do not have permissions for the User Management module. Therefore, users with custom roles created with Ordinary User as the permission attribute cannot view functions related to the User Management module after logging into the AI ​​platform.

[0132] The user authority configuration method provided in the embodiment of the present application adopts a dynamic configuration mechanism of role authority, which effectively solves the deficiencies of the RBAC model in terms of flexibility and scalability, and significantly improves the security of the system while improving work efficiency.

[0133] The user authority configuration method provided in the embodiment of the present application improves the flexibility of user management. By adopting a tree-shaped hierarchical authority inheritance model (such as a tree_id encoding mechanism), it supports dynamic adjustment of authority inheritance relationships, and realizes fine control and batch management of authorities to adapt to complex business scenarios. In combination with dynamic authority matrix configuration technology, it supports multi-maintenance screening and real-time synchronization, optimizes operational sales, and thus reduces the cost of large-scale role authority maintenance. By introducing a security audit log and an authority rollback mechanism, the traceability and recoverability of authority changes are ensured. At the same time, the interceptor technology is used to realize the immediate effectiveness of authority changes, avoiding the risk of misoperation or authority abuse. The user authority configuration method provided in the embodiment of the present application can be widely used in the entire process of authority definition, configuration, and effectiveness, and is applicable to AI platforms in multiple fields, with broad application prospects.

[0134] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0135] The embodiment of the present application also provides a user authority configuration device, such as Figure 6 As shown, the user authority configuration device includes:

[0136] The creation module 601 is used to create multiple custom roles.

[0137] The first determining module 602 is configured to determine a permission set of the custom role based on the attribute information of the custom role, wherein the permission set includes a plurality of permission codes, and each permission corresponds to a permission code.

[0138] The second determination module 603 is used to determine the permission tree structure of the custom role based on the permission set of the custom role, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and the hierarchical information of the tree node corresponding to the permission code is determined based on the hierarchical information represented by the permission code.

[0139] The third determining module 604 is configured to add a user to a custom role to determine the custom role to which the user belongs.

[0140] The fourth determining module 605 is configured to determine the permission information of the user based on the permission set of the user-defined role.

[0141] The fifth determination module 606 is used to respond to the shielding operation of the target permission of any custom role, determine the permission code to be shielded based on the target permission and target permission tree structure of the custom role, and update the permission set of the custom role and the permission information of the user corresponding to the custom role based on the permission code to be shielded.

[0142] In some optional implementations, the fifth determining module 606 includes:

[0143] The first determining unit is configured to determine a target permission code corresponding to the target permission based on the target permission of the custom role.

[0144] The first acquisition unit is configured to acquire a target authority matrix corresponding to the target authority code based on the target authority code.

[0145] The second determining unit is configured to determine whether the target permission supports the configuration based on the target permission matrix.

[0146] The third determining unit is configured to determine the permission code to be blocked based on the target permission code and the target permission tree structure if the target permission supports configuration.

[0147] In some optional implementations, the third determining unit includes:

[0148] The fourth determining unit is configured to determine a target tree node of the target authority code in the target authority tree structure based on the target authority code and the target authority tree structure.

[0149] The fifth determining unit is configured to use the permission code corresponding to the descendant tree node of the target tree node and the target permission code as the permission code to be masked if the target tree node has a descendant tree node.

[0150] The sixth determining unit is configured to use the target permission code as the permission code to be masked if the target tree node does not have a descendant tree node.

[0151] In some optional implementations, the user authority configuration device further includes:

[0152] The cache unit is used to cache the permission set of the custom role to the client.

[0153] The updating unit is used to update the permission set of the custom role cached by the client based on the updated permission set of the custom role whenever the permission set of the custom role is updated, so that when any user performs a target operation, it is determined whether the user has the permission to perform the target operation based on the permission set of the custom role to which the user belongs. If the user has the permission to perform the target operation, the user is allowed to perform the target operation.

[0154] In some optional implementations, the user authority configuration device further includes:

[0155] The recording unit is used to record the update information in the audit log when the permission set of any custom role is updated, wherein the update information includes the update operator, update time and update content.

[0156] In some optional implementations, the user authority configuration device further includes:

[0157] The saving unit is used to save the historical version of the permission set of any custom role when the permission set of the custom role is updated.

[0158] The recovery unit is configured to recover the permission set of any custom role based on a historical version of the permission set of the custom role in response to a permission rollback operation after the permission set of the custom role is updated.

[0159] In some optional implementations, the second determining module 603 includes:

[0160] The seventh determining unit is configured to determine, for any permission code in the permission set, the number of separators in the permission code.

[0161] An eighth determining unit is configured to determine the level information represented by the permission code based on the number of separators in the permission code.

[0162] The ninth determining unit is configured to determine the tree node code of the tree node corresponding to the permission code based on the hierarchical information represented by the permission code, so as to obtain the tree node codes of the tree nodes corresponding to all the permission codes in the permission set.

[0163] The determining unit is configured to determine, based on the tree node codes of the tree nodes corresponding to all the permission codes in the permission set, whether the tree node code of the tree node corresponding to the first permission code in the permission set is a prefix of the tree node code of the tree node corresponding to the second permission code.

[0164] A tenth determining unit is configured to determine that the tree node corresponding to the first permission code is the parent node of the tree node corresponding to the second permission code, and the tree node corresponding to the second permission code is the child node of the tree node corresponding to the first permission code, if the tree node code of the tree node corresponding to the first permission code in the permission set is a prefix of the tree node code of the tree node corresponding to the second permission code.

[0165] The construction unit is used to construct the permission tree structure of the custom role based on the tree node codes of the tree nodes corresponding to all permission codes in the permission set and the association relationship between the tree nodes corresponding to all permission codes in the permission set, wherein the association relationship includes a parent-child relationship.

[0166] For the description of the features in the embodiment corresponding to the user authority configuration device, reference can be made to the relevant description of the embodiment corresponding to the user authority configuration method, which will not be repeated here.

[0167] The embodiment of the present application also provides an electronic device, such as Figure 7 As shown, it includes a processor 701 and a memory 702, wherein the memory 702 stores a computer program, and the processor 701 is configured to run the computer program to execute the steps in any of the above user authority configuration method embodiments.

[0168] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned user authority configuration method embodiments when running.

[0169] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0170] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned user authority configuration method embodiments are implemented.

[0171] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned user authority configuration method embodiments are implemented.

[0172] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0173] The above is a detailed introduction to a user authority configuration method, device, electronic device and storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A user authority configuration method, characterized in that: include: Create multiple custom characters; Determining a permission set of the custom role based on the attribute information of the custom role, wherein the permission set includes a plurality of permission codes, each permission corresponding to a permission code; Determining a permission tree structure of the custom role based on the permission set of the custom role, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and determining hierarchical information of the tree node corresponding to the permission code based on hierarchical information represented by the permission code; Add a user to the custom role to determine the custom role to which the user belongs; Determine the permission information of the user based on the permission set of the custom role to which the user belongs; In response to a masking operation on a target permission of any custom role, determining a permission code to be masked based on the target permission and the target permission tree structure of the custom role, and updating the permission set of the custom role and the permission information of the user corresponding to the custom role based on the permission code to be masked; The step of determining the permission code to be blocked based on the target permission and the target permission tree structure of the custom role includes: Based on the target permission of the custom role, determine the target permission code corresponding to the target permission; Based on the target permission code, obtaining a target permission matrix corresponding to the target permission code; Based on the target permission matrix, determining whether the target permission supports configuration; If the target permission supports configuration, determining the permission code to be blocked based on the target permission code and the target permission tree structure; Determining whether the target permission supports configuration based on the target permission matrix includes: If the configurable field in the target permission matrix is ​​1, the target permission is determined to support configuration. If the configurable field in the target permission matrix is ​​0, the target permission does not support configuration. The determining the permission code to be shielded based on the target permission code and the target permission tree structure includes: Based on the target permission code and the target permission tree structure, determining a target tree node of the target permission code in the target permission tree structure; If the target tree node has a descendant tree node, the permission code corresponding to the descendant tree node of the target tree node and the target permission code are used as the permission code to be masked; If the target tree node does not have a descendant tree node, the target permission code is used as the permission code to be masked.

2. The method according to claim 1, characterized in that The method further comprises: Cache the permission set of the custom role to the client; Whenever the permission set of the custom role is updated, the permission set of the custom role cached by the client is updated based on the updated permission set of the custom role, so that when any user performs a target operation, it is determined whether the user has the permission to perform the target operation based on the permission set of the custom role to which the user belongs. If the user has the permission to perform the target operation, the user is allowed to perform the target operation.

3. The method according to claim 1, characterized in that The method further comprises: When the permission set of any custom role is updated, the update information will be recorded in the audit log, where the update information includes the update operator, update time and update content.

4. The method according to claim 1, wherein The method further comprises: When the permission set of any custom role is updated, the historical version of the permission set of the custom role is saved; After the permission set of any custom role is updated, in response to a permission rollback operation, the permission set of the custom role is restored based on the historical version of the permission set of the custom role.

5. The method according to claim 1, wherein The step of determining the permission tree structure of the custom role based on the permission set of the custom role includes: For any permission code in the permission set, determine the number of separators in the permission code; Determining the level information represented by the permission code based on the number of separators in the permission code; Determining, based on the hierarchical information represented by the permission code, a tree node code of a tree node corresponding to the permission code, to obtain tree node codes of tree nodes corresponding to all permission codes in the permission set; Based on the tree node codes of the tree nodes corresponding to all the permission codes in the permission set, determining whether in the permission set the tree node code of the tree node corresponding to the first permission code is a prefix of the tree node code of the tree node corresponding to the second permission code; If there exists in the permission set a tree node corresponding to a first permission code whose tree node code is a prefix of a tree node code corresponding to a second permission code, then determining that the tree node corresponding to the first permission code is the parent node of the tree node corresponding to the second permission code, and the tree node corresponding to the second permission code is the child node of the tree node corresponding to the first permission code; A permission tree structure of the custom role is constructed based on the tree node codes of the tree nodes corresponding to all permission codes in the permission set and the association relationship between the tree nodes corresponding to all permission codes in the permission set, wherein the association relationship includes a parent-child relationship.

6. A user authority configuration device, characterized in that: include: Creation module for creating multiple custom roles; a first determining module, configured to determine a permission set of the custom role based on the attribute information of the custom role, wherein the permission set includes a plurality of permission codes, each permission corresponding to a permission code; A second determination module is configured to determine a permission tree structure of the custom role based on the permission set of the custom role, wherein each permission code in the permission set corresponds to a tree node in the permission tree structure, and hierarchical information of the tree node corresponding to the permission code is determined based on hierarchical information represented by the permission code; A third determining module is configured to add a user to the custom role to determine the custom role to which the user belongs; A fourth determining module, configured to determine permission information of the user based on a permission set of the custom role to which the user belongs; a fifth determining module configured to, in response to a masking operation on a target permission of any custom role, determine a permission code to be masked based on the target permission and the target permission tree structure of the custom role, and update a permission set of the custom role and permission information of a user corresponding to the custom role based on the permission code to be masked; The fifth determination module includes: A first determining unit is configured to determine a target permission code corresponding to the target permission based on the target permission of the custom role; A first acquiring unit is configured to acquire a target authority matrix corresponding to the target authority code based on the target authority code; A second determining unit is configured to determine whether the target permission supports the configuration based on the target permission matrix; A third determining unit is configured to determine the permission code to be blocked based on the target permission code and the target permission tree structure if the target permission supports configuration; The second determining unit is specifically configured to: If the configurable field in the target permission matrix is ​​1, the target permission is determined to support configuration. If the configurable field in the target permission matrix is ​​0, the target permission does not support configuration. The third determining unit includes: a fourth determining unit, configured to determine a target tree node of the target authority code in the target authority tree structure based on the target authority code and the target authority tree structure; a fifth determining unit, configured to use, if the target tree node has a descendant tree node, the permission code corresponding to the descendant tree node of the target tree node and the target permission code as the permission code to be masked; The sixth determining unit is configured to use the target permission code as the permission code to be masked if the target tree node does not have a descendant tree node.

7. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the user authority configuration method according to any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the user authority configuration method according to any one of claims 1 to 5.

Images