Authority management method and device, electronic equipment, storage medium and program product

Abstract

The invention discloses an authority management method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of authority management, and the method comprises the following steps: obtaining a category instance according to an association relationship between user information and role information, so that the user information is associated with a role type through the category instance; configuring access control authorities based on the role types, so that the access control authorities of the same role type corresponding to different category instances are the same; and obtaining user information of a target user, and determining the access control authority of the target user according to the role type associated with the user information of the target user. By adopting the scheme, the authority management efficiency can be greatly improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of permission management, and particularly relate to a permission management method and device, electronic equipment, storage medium and program product. BACKGROUND

[0002] With the acceleration of enterprise digital transformation, the business system of an enterprise is increasingly complex. In the business system of an enterprise, different data processing permissions need to be configured for different users.

[0003] In a traditional permission management scheme, an RBAC (Role-Based Access Control) permission management system is usually adopted. In the RBAC permission management system, the system is centered on the roles to which users are assigned, and different permissions are assigned to different roles one by one.

[0004] However, in actual application scenarios, due to the complexity of the business system, a large number of users and roles are involved in the system, and the relationship between the users and the roles is complex. Therefore, a large amount of time is required to configure permissions for a large number of roles one by one. Moreover, there may be a large number of overlaps between the permissions of different roles, which leads to repeated configuration of a large number of permission points in the process of creating and maintaining a large number of roles, thereby reducing the permission management efficiency. SUMMARY

[0005] Embodiments of the present application provide a permission management method and device, electronic equipment, storage medium and program product, which can improve the efficiency of permission management.

[0006] In a first aspect, embodiments of the present application provide a permission management method, including: obtaining a category instance according to an association relationship between user information and role information, so that the user information is associated with a role type through the category instance; configuring access control permissions based on the role type, so that the access control permissions of the same role type corresponding to different category instances are the same; obtaining user information of a target user, and determining access control permissions of the target user according to a role type associated with the user information of the target user.

[0007] Optionally, obtaining a category instance according to an association relationship between user information and role information, so that the user information is associated with a role type through the category instance, includes: determining a role type based on the role information, and establishing a first mapping relationship between the user information and the category instance, and a second mapping relationship between the category instance and the role type; and establishing an association relationship between the user information and the role type based on the first mapping relationship and the second mapping relationship.

[0008] Optionally, after determining the access control authority of the target user according to the role type associated with the user information of the target user, the method further includes: receiving an operation request of the target user, and authenticating the operation request based on the access control authority of the target user.

[0009] Optionally, determining the access control authority of the target user according to the role type associated with the user information of the target user includes: obtaining the role type associated with the user information of the target user, and determining the access control authority of the target user based on the access control authority corresponding to the role type, wherein the access control authority of the target user is a set of permission points, and the set of permission points includes one or more permission point codes.

[0010] Optionally, authenticating the operation request based on the access control authority of the target user includes: obtaining a category instance associated with the user information of the target user to obtain a set of category instances; obtaining a target category instance and a target permission point code from the operation request, and determining whether the target category instance is a category instance in the set of category instances; if the target category instance is a category instance in the set of category instances, determining whether the target permission point code is a permission point code in the set of permission points; and if the target permission point code is a permission point code in the set of permission points, executing the operation request.

[0011] Optionally, the set of permission points includes at least one of a function permission point and a data permission point, the data permission point is used to limit the data range that the target user can operate, and the function permission point is used to limit the operation type that the target user can execute.

[0012] Optionally, authenticating the operation request based on the access control authority of the target user further includes: if the target category instance is not a category instance in the set of category instances, or if the target permission point code is not a permission point code in the set of permission points, not executing the operation request.

[0013] In a second aspect, an embodiment of the present application provides a permission management apparatus, including: an information association module configured to obtain a category instance according to an association relationship between user information and role information, so that the user information is associated with a role type through the category instance; a permission configuration module configured to configure an access control authority based on the role type, so that the access control authorities of the same role type corresponding to different category instances are the same; and a permission acquisition module configured to obtain user information of a target user, and determine an access control authority of the target user according to a role type associated with the user information of the target user.

[0014] Optionally, the apparatus further includes an operation authentication module configured to receive an operation request of the target user, and authenticate the operation request based on the access control authority of the target user.

[0015] In a third aspect, an electronic device is provided, including a processor and a memory storing program instructions, wherein the processor is configured to execute the permission management method as described above when running the program instructions.

[0016] In a fourth aspect, a storage medium is provided, storing program instructions, wherein the program instructions, when executed, perform the permission management method as described above.

[0017] In a fifth aspect, a computer program product is provided, including a computer program, which, when executed by a processor, implements the permission management method as described above.

[0018] The permission management method provided by the embodiments of the present application associates user information with role types through category instances, sets access control permissions according to role types, ensures that the same role type has the same access control permissions in different category instances, and then determines the access control permissions of a target user according to the role type associated with the user information of the target user. By uniformly configuring access control permissions based on role types, the cumbersome process of configuring permissions for a large number of roles one by one is avoided, and the time and labor cost required for permission configuration is significantly reduced. Furthermore, since the same role type has consistent permissions in different category instances, the access control permissions of a target user can be determined according to the role type associated with the user information of the target user, which greatly improves the efficiency of permission management. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0020] Figure 1 is a traditional RBAC model architecture diagram; Figure 2 is a flowchart of a permission management method provided by an embodiment of the present application; Figure 3 is a permission management model architecture diagram provided by an embodiment of the present application; Figure 4 is an access control flowchart provided by an embodiment of the present application; Figure 5 is a schematic diagram of a permission management device provided by an embodiment of the present application; Figure 6 is a schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0021] In order to make the purposes, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.

[0022] It should be clear that the described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0023] The following description refers to the accompanying drawings. Unless otherwise indicated, same numbers in different drawings indicate same or similar elements. The embodiments described in the following example embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of apparatuses and methods consistent with some aspects of the present application as detailed in the appended claims.

[0024] In the description of the present application, it should be understood that the terms "first", "second", "third" and the like are only used to distinguish similar objects, and do not necessarily indicate a specific order or sequence, nor can they be understood as indicating or implying relative importance. For those of ordinary skill in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances. In addition, in the description of the present application, "a plurality of" means two or more, unless otherwise specified. "And / or", which describes the association between objects, means that there can be three relationships, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone. The character " / " generally represents that the associated objects before and after are in an "or" relationship.

[0025] With the acceleration of enterprise digital transformation, the business system of the enterprise is becoming increasingly complex. In the business system of the enterprise, different data processing permissions need to be configured for different users. In the traditional permission management scheme, the RBAC permission management model is usually used. RBAC permission management is an access control mechanism that realizes permission management through role allocation. By binding users with specific roles, the operation permissions of system resources are controlled, such as Figure 1 As shown in Figure 1 is a traditional RBAC model architecture diagram, where the role is the allocation unit and carrier of the permission. By assigning a user with a certain role, the user obtains the permission of the role. The association between users and roles, and the association between roles and permission points are both many-to-many. Specifically, a user can correspond to multiple roles, and a role can also correspond to multiple users. At the same time, a role can correspond to multiple permission points.

[0026] However, in actual application scenarios, due to the complexity of the business system, a large number of users and roles are involved in the system, so a large number of roles need to be configured with permissions one by one, which will consume a lot of time. Moreover, there is a many-to-many association relationship between users and roles, and when a large number of roles are superimposed, the role permission points will be crossed, for example, two or more different roles may contain exactly the same permission points, resulting in repeated configuration of permission points, further reducing the efficiency of permission management, and making it extremely difficult to maintain permissions later.

[0027] In the traditional permission management method, taking the education scene as an example, as shown in the following table: User U Role R Permission Point P Teacher A (User 1) Class 1 Year 1 Head Teacher (Role 1) Manage Visit Records (Permission Point 1) Teacher A (User 1) Class 1 Year 2 Chinese Teacher (Role 2) Register Chinese Scores (Permission Point 2) Teacher B (User 2) Class 1 Year 2 Head Teacher (Role 3) Manage Visit Records (Permission Point 1) Teacher C (User 3) Class 1 Year 3 Chinese Teacher (Role 4) Register Chinese Scores (Permission Point 2) Table 1 Different teachers may play different educational roles in different classes, and there is a cross relationship between users and classes, for example, user 1 plays the role of class teacher of class 1 and Chinese teacher of class 2. As shown in Table 1, if the traditional RBAC model is used, four roles need to be constructed, namely class teacher of class 1 (role 1), Chinese teacher of class 2 (role 2), class teacher of class 2 (role 3), and Chinese teacher of class 3 (role 4), and the corresponding permission points need to be configured for the roles. For these four roles, four configurations are needed, and the relationship between the 4 roles and the permission points also needs to be maintained. However, in actual scenarios, the permission points of class teachers in different classes are similar, and the permission points of Chinese teachers in different classes are also similar, so for the permission point of managing home visit records (permission point 1), role 1 and role 3 are configured respectively, and for the permission point of registering Chinese scores (permission point 2), role 2 and role 4 are configured respectively. As can be seen, the permission points of role 1 and role 3 are repeatedly configured, and the permission points of role 2 and role 4 are also repeatedly configured. Therefore, this traditional permission management method will lead to a large number of repeated configurations of permission points in actual application.

[0028] Based on this, the embodiments of the present application provide a permission management method, device, electronic equipment, storage medium and program product. By uniformly configuring access control permissions based on role types, the tedious process of configuring permissions for a large number of roles one by one is avoided, and the time and labor cost required for permission configuration is significantly reduced. Further, since the same role type has consistent permissions in different category instances, the access control permissions of the target user can be determined according to the role type associated with the user information of the target user, which greatly improves the efficiency of permission management.

[0029] The electronic device is, for example, a notebook computer, a desktop computer, a mobile phone, a tablet computer, etc. The embodiments of the present application are not limited. The permission management system is deployed on the electronic device. The permission management system provides a permission management interface. An administrator or a business personnel configures corresponding permission points for different role types in the graphical permission management interface through dragging and clicking.

[0030] Next, the permission management method of the embodiments of the present application is described in detail. For example, refer to Figure 2 , Figure 2 is a flowchart of a permission management method provided by the embodiments of the present application. The embodiments include: S101: obtaining a category instance according to an association relationship between user information and role information, so that the user information is associated with a role type through the category instance.

[0031] In the embodiments, first, the association relationship between the user information and the role information of the user is obtained. The user information is the unique identity of the user in the system, and the specific form can be determined according to the application scenario. For example, in an enterprise scenario, it can be a username, a user ID, or an employee number, etc. In an education scenario, it can be a student number or a teacher number, etc. The role information is used to represent one or more responsibility identities of the user in the permission system. For example, user 1 is associated with two role information, which are “class teacher of class 1 year 1” and “Chinese teacher of class 1 year 2”, and user 2 is associated with “class teacher of class 1 year 2”.

[0032] After determining the association relationship between the user information and the role information, the category instance is further obtained. The category instance is an abstract representation of various entities in the system, which can be obtained by the developers according to the inherent characteristics of the business function. For example, in an education scenario, “class” can be a category, and its specific category instances include “class 1 year 1” and “class 1 year 2”, as shown in Table 2.

[0033] User U Category C Category Instance CI Role Type Teacher A (User 1) Class 1 Year 1 Head Teacher (Role Type 1) Teacher A (User 1) Class 1 Year 2 Chinese Teacher (Role Type 2) Teacher B (User 2) Class 1 Year 2 Head Teacher (Role Type 1) Teacher C (User 3) Class 1 Year 3 Chinese Teacher (Role Type 2) Table 2 For example, in a wind power scenario, “wind turbine” can be a category, and the corresponding category instances can be “wind turbine a” and “wind turbine b”, as shown in Table 3. In addition, in order to adapt to the changing business needs, the category instance can be added, modified, deleted, etc. to ensure the clarity and scalability of the permission system.

[0034] User U Category C Category Instance CI Role Type Engineer A (User 1) Fan Fan a Model Development Leader (Role Type 1) Engineer B (User 2) Fan Fan a Hub Architect (Role Type 2) Engineer C (User 3) Fan Fan a Transmission Chain Architect (Role Type 3) Table 3 In this embodiment, the role type is an abstract classification of roles with the same set of permission points. Referring to Tables 2 and 3, the role type is, for example, "class teacher", "Chinese teacher", or "model development manager", "wheel hub architect", etc.

[0035] S102: Configure access control permissions based on role type so that the access control permissions for the same role type corresponding to different types of instances are the same.

[0036] Reference Figure 3 As shown, Figure 3 This is a diagram of the permission management model architecture provided in this application embodiment. This embodiment manages access control permissions for different role types uniformly by configuring permission points for role types, ultimately ensuring that users under the same role type inherit the permission points associated with that role type. Based on this, the following architecture is constructed: Figure 3 The four-layer dynamic association architecture of "user-category-role type-permission point" shown means that the same role type has the same set of permission points in different category instances.

[0037] For example, as shown in Table 4, configuring the "Manage Home Visit Records" permission point only once for the "Class Teacher" role type will grant all users belonging to this role type the corresponding permissions. In this way, regardless of which class (category instance) the class teacher belongs to, they will have the same access control permissions.

[0038] User U Category C Category Instance CI Role Type Permission Point P Teacher A (User 1) Class 1 Year 1 Head Teacher (Role Type 1) Manage Visit Records (Permission Point 1) Teacher A (User 1) Class 1 Year 2 Chinese Teacher (Role Type 2) Register Chinese Scores (Permission Point 2) Teacher B (User 2) Class 1 Year 2 Head Teacher (Role Type 1) Manage Visit Records (Permission Point 1) Teacher C (User 3) Class 1 Year 3 Chinese Teacher (Role Type 2) Register Chinese Scores (Permission Point 2) Table 4 For example, as shown in Table 5, configuring the "Edit all attribute data under this model" permission point for the "Model Development Manager" role type will grant all users belonging to this role type the corresponding permission. In this way, regardless of which wind turbine the Model Development Manager manages, there is no need to repeatedly configure permissions.

[0039] User U Category C Category Instance CI Role Type Permission Point P Engineer A (User 1) Fan Fan a Model Development Leader (Role Type 1) Edit all attribute data under the model (Permission Point 1) Engineer B (User 2) Fan Fan a Hub Architect (Role Type 2) Edit attribute data of the hub under the model (Permission Point 2) Engineer C (User 3) Fan Fan a Transmission Chain Architect (Role Type 3) Edit attribute data of the transmission chain under the model (Permission Point 3) Table 5 This approach allows permissions for the same role type to be configured only once and reused throughout the entire system, effectively avoiding duplicate configurations and omissions, and reducing human error. This method not only significantly improves the efficiency of permission configuration but also substantially reduces subsequent maintenance costs.

[0040] S103: Obtain the target user's user information and determine the target user's access control permissions based on the role type associated with the target user's user information.

[0041] In this embodiment, a certain user (i.e., a target user) logs in by inputting login information such as an account and a password in the permission management system. When the permission management system detects that the target user logs in, the user information of the target user is obtained from the login information, and then the role type of the target user is obtained according to the user information of the target user. Subsequently, the permission management system finds the corresponding set of permission points according to the role type, and the set of permission points represents the access control permission of the target user. For example, if the role type of the target user is "class teacher", the corresponding set of permission points includes "manage home visit records", "view class student information", and the like, then the target user has the permissions corresponding to these permission points.

[0042] Specifically, the permission management system queries the permission points by calling a permission query interface, which is an application programming interface (API). After obtaining the user information of the target user, the permission management system calls the permission query interface to query all the role types associated with the user information, and aggregates the permission points corresponding to these role types to obtain the access control permission of the target user.

[0043] The permission management method provided by the embodiments of the present application associates the user information with the role type through the category instance, sets the access control permission according to the role type, ensures that the same role type has the same access control permission in different category instances, and determines the access control permission of the target user according to the role type associated with the user information of the target user after obtaining the user information of the target user. By using this scheme, the access control permission is uniformly configured based on the role type, avoiding the tedious process of configuring the permission for a large number of roles one by one, and significantly reducing the time and labor cost required for permission configuration. Furthermore, since the same role type has consistent permissions in different category instances, the access control permission of the target user can be determined according to the role type associated with the user information of the target user, and the permission management efficiency is improved.

[0044] Optionally, in the above embodiments, the permission management system obtains the category instance according to the association relationship between the user information and the role information, so that in the process of associating the user information with the role type through the category instance, the permission management system determines the role type based on the role information, establishes a first mapping relationship between the user information and the category instance, and a second mapping relationship between the category instance and the role type. Subsequently, the permission management system establishes the association relationship between the user information and the role type based on the first mapping relationship and the second mapping relationship.

[0045] In this embodiment, the first mapping relationship represents the corresponding relationship between the user information and the category instance, and the mapping relationship supports the form of many-to-many. For example, "engineer A" can simultaneously establish a mapping relationship with two category instances "fan a" and "fan b"; similarly, "fan a" can also simultaneously establish a mapping relationship with "engineer A", "engineer B", and "engineer C". The second mapping relationship represents the corresponding relationship between the category instance and the role type, such as "fan a" simultaneously establishing a mapping relationship with "model development leader", "hub architect", and "transmission chain architect". Based on the first mapping relationship and the second mapping relationship, the association structure of "user information-category instance-role type" is finally formed. In this association structure, a user can assume different role types in different category instances, realizing the arbitrary combination of users, category instances, and role types.

[0046] It should be noted that each role type has its corresponding role code, role name, description information, and other attributes, and the role type can be added, modified, deleted, and the like according to the actual scene.

[0047] With this scheme, by introducing the intermediate layer of role type, the decoupling of user and permission is realized, and the association relationship between user and permission point is indirectly constructed, so that the permission change does not need to be directly associated with a specific user, thereby significantly improving the efficiency of permission configuration.

[0048] Optionally, in the above embodiment, after determining the access control permission of the target user according to the role type associated with the user information of the target user, the permission management system receives an operation request of the target user, and authenticates the operation request based on the access control permission of the target user.

[0049] In this embodiment, the operation request initiated by the target user can include operations such as adding, deleting, modifying, or querying the target data. For example, the target user can initiate an operation request by clicking the "edit" button, the "delete" button, and the like on the user interface. After receiving the operation request, the permission management system authenticates the operation request and determines whether to execute the operation. For example, when the permission management system receives the operation request of deleting the target data initiated by the target user, it determines whether the operation request is within the access control permission of the target user. If yes, the permission management system allows the deletion operation to be executed; if not, the permission management system does not allow the deletion operation to be executed, and does not respond to the operation request or returns a prompt message such as insufficient permission.

[0050] With this scheme, the permission management system will authenticate each operation request according to the access control permission of the target user that has been determined, and only the operations within the permission range will be executed, thereby ensuring the security of system data and the compliance of operations.

[0051] Optionally, in the process of determining the access control permission of the target user according to the role type associated with the user information of the target user in the above embodiments, the permission management system acquires the role type associated with the user information of the target user, and determines the access control permission of the target user based on the access control permission corresponding to the role type, wherein the access control permission of the target user is a permission point set, and the permission point set includes one or more permission point codes.

[0052] In this embodiment, the permission point codes contained in the permission point set corresponding to the target user represent all the permissions possessed by the target user. Specifically, to realize unified configuration and management of permission points, a unique permission point code is set as the permission point identifier when the permission point is first created, and description information is added to the permission point, and subsequent modifications are only allowed to be made to the description information of the permission point to ensure the stability of the permission identifier. When the business requirements change and some permission points need to be added, modified or deleted, the administrator or the developer performs corresponding operations on the permission points in the permission management interface to update the permission point set of the related role type.

[0053] By using this scheme, the permission points can be centrally managed through the permission point codes, and the precise identification of permissions can be realized through the unique permission point codes, thereby ensuring the accuracy of the permission management system in the permission configuration process.

[0054] Optionally, in the above embodiments, the permission point set at least includes one of a function permission point and a data permission point, the data permission point is used to limit the data range that the target user can operate, and the function permission point is used to limit the operation type that the target user can execute.

[0055] In this embodiment, the permission management system defines the permission points from two dimensions of function level and data level, wherein the data permission point is used to limit the permission data that the target user can operate, and the data that can be operated by different role types is different, for example, the user with the role type of "hub architect" can only operate the attribute data of the hub, and the user with the role type of "transmission chain architect" can only operate the attribute data of the transmission chain. The function permission point is used to limit the operation that can be executed by the target user, and the operation that can be executed by different role types is different, for example, the user with the role type of "class teacher" has the operation permission of managing the home visit record, and the user with the role type of "Chinese teacher" has the operation permission of registering the Chinese score. For another example, the role type of "data entry clerk" only has the operation permission of editing data, and the role type of "data auditor" has the operation permissions of data viewing, rejecting and approving.

[0056] With this scheme, the permission is divided from the function level and the data level, which conforms to the principle of least privilege, meets the diversity demand of business operation, ensures the security and compliance of data, and improves the overall security of the system.

[0057] Optionally, in the above embodiment, in the process of authenticating the operation request based on the access control permission of the target user, the permission management system obtains the category instance associated with the user information of the target user to obtain a category instance set, then obtains the target category instance and the target permission point code according to the operation request, and judges whether the target category instance is a category instance in the category instance set. If the target category instance is a category instance in the category instance set, it is judged whether the target permission point code is a permission point code in the permission point set. If the target permission point code is a permission point code in the permission point set, the operation request is executed.

[0058] In this embodiment, the operation request of the target user carries the target category instance and the target permission point code. The target category instance is the category instance that the target user intends to access. For example, if the target user wants to edit the Chinese score of Class 1 Year 2, then "Class 1 Year 2" is the target category instance. The target permission point code is the permission point code corresponding to the specific operation that the target user wants to perform. As described above, the target permission point code is the permission point code corresponding to the permission point of "editing Chinese score".

[0059] Specifically, referring to Figure 4 , Figure 4 is an access control flowchart provided by the embodiment of the application. After the target user logs in the permission management system, the permission management system obtains all category instances associated with the user information of the target user, which together constitute a category instance set. After receiving an operation request, the permission management system parses the operation request to obtain a target category instance and a target permission point code. Further, the permission management system performs double permission verification. First, the permission management system judges whether the target category instance is a category instance in the category instance set. If the target category instance is not a category instance in the category instance set, the operation request is not executed. If the target category instance is a category instance in the category instance set, it is further judged whether the target permission point code is a permission point code in the permission point set. If the target permission point code is not a permission point code in the permission point set, the operation request is not executed. If the target permission point code is a permission point code in the permission point set, the operation request is executed.

[0060] With this scheme, the permission management system will only allow the operation request to be executed when both the target category instance and the target permission point code pass the verification. This authentication method ensures the security of system data and the compliance of operation, effectively preventing unauthorized access and operation.

[0061] To illustrate the beneficial effects brought by the present embodiment, the following is described in conjunction with a specific example: Suppose there are currently 5 classes, and for each class, the composition of the teacher role is consistent, with 3 types of teacher roles in each class, namely the class monitor, the Chinese teacher, and the mathematics teacher. In the traditional permission management scheme, the number of roles that need to be maintained = 5 (number of classes) x 3 (number of teacher roles) = 15, i.e. the access control permissions need to be configured and maintained for each of the 15 roles.

[0062] In the present embodiment, the user is associated with the role type through the category instance, and the access control permissions are configured based on the role type, so that the access control permissions are only related to the role type. At this time, the number of role types that need to be maintained is only the number of teacher roles, which is only 3. Compared with the number of 15 roles in the traditional scheme, the present embodiment greatly reduces the maintenance cost.

[0063] Therefore, by using the present embodiment, the number of roles that need to be maintained can be significantly reduced, and when the number of category instances increases, the maintenance cost remains almost unchanged. Even if the number of classes increases while the number of role types in each class remains unchanged, the maintenance cost will not increase. In addition, the more category instances there are, the more maintenance cost is saved, thereby greatly reducing the role management complexity and being suitable for complex permission management scenarios.

[0064] The following is an apparatus embodiment of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the apparatus embodiments of the present application, please refer to the method embodiments of the present application.

[0065] Figure 5 is a schematic diagram of a permission management apparatus provided by the present embodiment, which apparatus 500 comprises: an information association module 51, a permission configuration module 52, and a permission acquisition module 53.

[0066] The information association module 51 is configured to obtain a category instance according to an association relationship between user information and role information, so that the user information is associated with a role type through the category instance.

[0067] The permission configuration module 52 is configured to configure access control permissions based on the role type, so that the access control permissions of the same role type corresponding to different category instances are the same.

[0068] The permission acquisition module 53 is configured to obtain user information of a target user, and determine the access control permissions of the target user according to the role type associated with the user information of the target user.

[0069] In a feasible implementation manner, the permission management apparatus 500 further comprises: The operation authentication module 54 is configured to receive an operation request of a target user, and authenticate the operation request based on the access control permission of the target user.

[0070] In an implementation, the information association module 51 is configured to: acquire a category instance according to an association relationship between the user information and the role information, so that when the user information is associated with the role type through the category instance, the role type is determined based on the role information, and a first mapping relationship between the user information and the category instance and a second mapping relationship between the category instance and the role type are established; and the association relationship between the user information and the role type is established based on the first mapping relationship and the second mapping relationship.

[0071] In an implementation, the permission acquisition module 53 is configured to: acquire the role type associated with the user information of the target user when the role type of the target user is determined based on the user information of the target user, and determine the access control permission of the target user based on the access control permission corresponding to the role type, where the access control permission of the target user is a permission point set, and the permission point set includes one or more permission point codes.

[0072] In an implementation, the operation authentication module 54 is configured to: acquire the category instance associated with the user information of the target user when the operation request is authenticated based on the access control permission of the target user, to obtain a category instance set; acquire a target category instance and a target permission point code according to the operation request, and determine whether the target category instance is a category instance in the category instance set; if the target category instance is a category instance in the category instance set, determine whether the target permission point code is a permission point code in the permission point set; and if the target permission point code is a permission point code in the permission point set, execute the operation request.

[0073] In an implementation, the permission point set includes at least one of a function permission point and a data permission point, the data permission point is used to limit a data range that can be operated by the target user, and the function permission point is used to limit an operation type that can be executed by the target user.

[0074] In an implementation, the operation authentication module 54 is configured to: if the target category instance is not a category instance in the category instance set, or if the target permission point code is not a permission point code in the permission point set, the operation request is not executed when the operation request is authenticated based on the access control permission of the target user.

[0075] The permission management apparatus provided by the embodiments of the present application is used to execute the permission management method in the above embodiments, and has similar implementation principles and technical effects, which will not be described herein again.

[0076] In combination with Figure 6As shown, the electronic device 600 provided by the embodiments of the present application includes a processor 601 and a memory 602. Optionally, the device can further include a communication interface 603 and a bus 604. The processor 601, the memory 602 and the communication interface 603 can communicate with each other through the bus 604. The communication interface 603 can be used for information transmission. The processor 601 can invoke the logic instructions in the memory 602 to execute the permission management method in the above embodiments.

[0077] In addition, the logic instructions in the memory 602 described above can be implemented in the form of a software function unit and sold or used as an independent product, which can be stored in a computer readable storage medium.

[0078] The memory 602 as a computer readable storage medium can be used to store software programs, computer executable programs, such as program instructions / modules corresponding to the method in the embodiments of the present application. The processor 601 executes the function application and data processing by running the program instructions / modules stored in the memory 602, that is, implements the permission management method in the above embodiments.

[0079] The memory 602 can include a program storage area and a data storage area, wherein the program storage area can store an operating system and at least one application required by a function; the data storage area can store data created according to the use of the terminal device, etc. In addition, the memory 602 can include a high-speed random access memory and can also include a non-volatile memory.

[0080] The embodiments of the present application provide a storage medium, which stores computer executable instructions, and the computer executable instructions are set to execute the permission management method in the above embodiments.

[0081] The storage medium described above can be a transitory computer readable storage medium or a non-transitory computer readable storage medium.

[0082] The technical solutions of the embodiments of the present application can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes one or more instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in the embodiments of the present application. The storage medium described above can be a non-transitory storage medium, including a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc. various media that can store program codes, or a transitory storage medium.

[0083] The embodiment of the present application provides a computer program product, comprising a computer program, when the computer program is executed by a processor, the computer program realizes the permission management method in the above embodiment.

[0084] The above description and drawings sufficiently illustrate the embodiments of the present disclosure to enable one skilled in the art to practice them. Other embodiments can include structural, logical, electrical, process, and other changes. The embodiments merely represent some possibilities. Unless explicitly required, individual components and functions are optional and the order of operations can be changed. Parts and features of some embodiments can be included in or replace parts and features of other embodiments. Also, the words used in this application are only used to describe the embodiments and not to limit the claims. As used in the description of the embodiments and the claims, unless the context clearly requires otherwise, the singular forms "a", "an", and "the" are intended to include the plural forms as well. Similarly, the term "and / or" as used in this application refers to any and all possible combinations of one or more associated listed items. In addition, when used in this application, the term "comprise" and its variants "comprises" and / or comprises" and the like mean the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Without more limitations, the element defined by the phrase "comprising a" does not exclude the presence of additional identical elements in the process, method, or device including the element. In this document, each embodiment focuses on the differences from other embodiments, and the same or similar parts between embodiments can be referred to each other. For the method, product, etc. disclosed by the embodiments, if it corresponds to the method part disclosed by the embodiments, the relevant part can be referred to the description of the method part.

[0085] Those skilled in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software, it can depend on the specific application and design constraints of the technical solution. The skilled person can use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of the embodiments of the present application. The skilled person can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0086] In the embodiments disclosed herein, the disclosed methods, products (including but not limited to apparatuses, devices, etc.), can be implemented in other manners. For example, the apparatus embodiments described above are merely schematic. For example, the division of the units is merely logical function division. There can be other division manners in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, apparatuses, or units, and can be in electrical, mechanical, or other forms. The units described as separated components can or can not be physically separated, and components displayed as units can or can not be physical units. Some or all of the units can be selected according to actual needs to achieve the embodiments.

[0087] The flowcharts and block diagrams in the drawings show the possible implementation architectures, functions, and operations of the systems, methods, and computer program products according to the embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing the specified logical functions. In some alternative implementations, the functions noted in the blocks can occur in different orders than those noted in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the drawings, the operations or steps corresponding to different blocks can also occur in different orders than those disclosed in the descriptions, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved. Each block in the block diagrams and / or flowcharts, and the combination of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

Claims

1. A method for managing access permissions, characterized in that, include: Category instances are obtained based on the association between user information and role information, so that the user information is associated with the role type through the category instances; Configure access control permissions based on the role type so that the access control permissions for the same role type corresponding to different category instances are the same; Obtain the target user's user information, and determine the target user's access control permissions based on the role type associated with the target user's user information.

2. The method according to claim 1, characterized in that, The step of obtaining a category instance based on the association between user information and role information, so that the user information is associated with the role type through the category instance, includes: The role type is determined based on the role information, and a first mapping relationship is established between the user information and the category instance, and a second mapping relationship is established between the category instance and the role type; Based on the first mapping relationship and the second mapping relationship, an association relationship is established between the user information and the role type.

3. The method according to claim 1, characterized in that, After determining the access control permissions of the target user based on the role type associated with the target user's user information, the method further includes: The system receives the operation request from the target user and authenticates the operation request based on the target user's access control permissions.

4. The method according to claim 3, characterized in that, The step of determining the access control permissions of the target user based on the role type associated with the target user's user information includes: Obtain the role type associated with the user information of the target user, and determine the access control permissions of the target user based on the access control permissions corresponding to the role type, wherein the access control permissions of the target user are a set of permission points, and the set of permission points includes one or more permission point codes.

5. The method according to claim 4, characterized in that, The authentication of the operation request based on the access control permissions of the target user includes: Obtain category instances associated with the user information of the target user to obtain a set of category instances; Based on the operation request, obtain the target category instance and the target permission point code, and determine whether the target category instance is a category instance in the category instance set; If the target category instance is a category instance in the category instance set, then determine whether the target permission point code is a permission point code in the permission point set; If the target permission point code is a permission point code in the permission point set, then the operation request is executed.

6. The method according to claim 4 or 5, characterized in that, The set of permission points includes at least one of functional permission points and data permission points. The data permission points are used to limit the range of data that the target user can operate on, and the functional permission points are used to limit the types of operations that the target user can perform.

7. The method according to claim 5, characterized in that, The authentication of the operation request based on the access control permissions of the target user also includes: If the target category instance is not a category instance in the set of category instances, or if the target permission point code is not a permission point code in the set of permission points, then the operation request will not be executed.

8. A permission management device, characterized in that, include: The information association module is used to obtain category instances based on the association relationship between user information and role information, so that the user information is associated with the role type through the category instance; The permission configuration module is used to configure access control permissions based on the role type, so that the access control permissions for the same role type corresponding to different category instances are the same; The permission acquisition module is used to acquire the user information of the target user and determine the access control permissions of the target user based on the role type associated with the user information.

9. The apparatus according to claim 8, characterized in that, Also includes: The operation authentication module is used to receive the operation request from the target user and authenticate the operation request based on the target user's access control permissions.

10. An electronic device comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to perform the method as described in any one of claims 1 to 7 when executing the program instructions.

11. A storage medium storing program instructions, characterized in that, When the program instructions are executed, they perform the method as described in any one of claims 1 to 7.

12. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images