Authentication method, device and equipment

Abstract

Embodiments of the present application disclose an authentication method, apparatus, and device; wherein, the authentication method includes: determining permission information to be verified of an authenticated object in response to an authentication request; obtaining a pre-configured permission list of the authenticated object from a pre-configured authentication system; wherein, the permission list includes system permissions and / or resource permissions possessed by the authenticated object; and verifying the permission information to be verified based on the permission list.

Description

Technical Field

[0001] The embodiments of the present application relate to rights management technology, including but not limited to authentication methods, devices, and equipment. Background Art

[0002] Role-Based Access Control (RBAC) is a mature authentication management model. By adding a role model, it avoids directly binding permissions to users. Users can change permissions in batches by simply changing roles, or modify role permissions to batch modify user permissions. However, RBAC primarily addresses the authentication of system permissions. For resource-related authentication needs, it can only authenticate pre-defined resource objects. It cannot add resource objects based on authentication needs, making it impossible to achieve flexible authentication requirements for resource permissions. Summary of the Invention

[0003] In view of this, the authentication method, apparatus, and device provided in the embodiments of the present application, by setting a resource provision interface to obtain a list of resource objects, can enable an authentication system to perform both system authority authentication and flexible authentication requirements for resource permissions. The authentication method, apparatus, and device provided in the embodiments of the present application are implemented as follows:

[0004] The authentication method provided by an embodiment of the present application includes: determining permission information to be verified of an authenticated object in response to an authentication request; obtaining a pre-configured permission list of the authenticated object from a pre-configured authentication system; wherein the permission list includes system permissions and / or resource permissions possessed by the authenticated object; and verifying the permission information to be verified based on the permission list.

[0005] The authentication device provided in an embodiment of the present application includes: a determination module, used to determine the permission information to be verified of the authenticated object in response to an authentication request; an acquisition module, used to obtain a pre-configured permission list of the authenticated object from a pre-configured authentication system; wherein the permission list includes system permissions and / or resource permissions possessed by the authenticated object; and a verification module, used to verify the permission information to be verified based on the permission list.

[0006] An electronic device provided in an embodiment of the present application includes a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, the method described in the embodiment of the present application is implemented.

[0007] In an embodiment of the present application, in response to an authentication request, permission information to be verified for the authenticated object is determined; a pre-configured permission list for the authenticated object is obtained from a pre-configured authentication system; wherein the permission list includes system permissions and / or resource permissions possessed by the authenticated object; and the permission information to be verified is verified based on the permission list. In this way, during authentication, both resource permissions and system permissions can be authenticated, meeting different authentication requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The drawings herein are incorporated into and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and, together with the specification, are used to illustrate the technical solutions of the present application.

[0009] Figure 1 A schematic diagram of the implementation flow of the configuration method of the authentication system provided in the embodiment of the present application;

[0010] Figure 2 Schematic diagram of the "student management scenario" permission model provided for this application embodiment

[0011] Figure 3 A schematic diagram of another implementation flow of the configuration method of the authentication system provided in an embodiment of the present application;

[0012] Figure 4 Schematic diagram of the implementation process of the authentication method provided in the embodiment of the present application;

[0013] Figure 5 A schematic diagram of another implementation flow of the authentication method provided in an embodiment of the present application;

[0014] Figure 6 A schematic diagram of the dependency relationships among permissions, roles, and user models provided in this application embodiment;

[0015] Figure 7 A schematic diagram of the vertical classification of permissions provided in the embodiment of this application;

[0016] Figure 8 A schematic diagram of an implementation scheme for a resource provision interface provided in an embodiment of the present application;

[0017] Figure 9 A schematic diagram of the main authentication process provided in an embodiment of the present application;

[0018] Figure 10 Schematic diagram of the system permission authentication sub-process provided for this application;

[0019] Figure 11 Schematic diagram of the resource permission authentication sub-process provided for this application;

[0020] Figure 12 This is a schematic diagram of the structure of the configuration device of the authentication system according to the embodiment of the present application;

[0021] Figure 13 This is a schematic diagram of the structure of the authentication device according to an embodiment of the present application;

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

[0023] To make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the specific technical solutions of the present application will be further described in detail below in conjunction with the drawings in the embodiments of the present application. The following embodiments are used to illustrate the present application but are not intended to limit the scope of the present application.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0025] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0026] It should be pointed out that the terms "first\second\third" involved in the embodiments of the present application are used to distinguish similar or different objects, and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0027] An embodiment of the present application provides a method for configuring an authentication system. This method is applied to an electronic device. During implementation, the electronic device can be any type of device with information processing capabilities, such as a personal computer, a laptop computer, a server, or a cluster server. The functions implemented by this method can be implemented by a processor in the electronic device calling program code. Of course, the program code can be stored in a computer storage medium. Therefore, the electronic device includes at least a processor and a storage medium.

[0028] Figure 1 A schematic diagram of the implementation flow of the configuration method of the authentication system provided in the embodiment of the present application is shown as follows: Figure 1 As shown, the method may include the following steps 101 to 103:

[0029] Step 101: Configure a system permission list of objects that can be granted permissions; wherein the system permission list includes the system permissions possessed by the objects that can be granted permissions;

[0030] The object that can be authorized can be understood as the smallest unit that can be authorized. The object that can be authorized can be determined based on the scenario to be authenticated. Figure 2 This is a schematic diagram of the "student management scenario" permission model provided in the embodiment of this application, such as Figure 2 As shown in the figure, in the "student management scenario", the objects that can be granted include users, roles, and college management; in the "5G slice management scenario", the objects that can be granted include roles, users, provinces, resource pools, and menu maps. It is understandable that the objects that can be granted can be repeated in different scenarios. For example, in the "5G slice management scenario" and "student management scenario", the objects that can be granted include roles and users.

[0031] Permissions refer to a user's ability to perform actions, such as "Approve Work Orders" and "Delete Users." System permissions are permissions that don't have specific action objects, but only descriptions of the permissions. For example, the "ROLE" type has system permissions such as "Create Role (ROLE_CREATE)" and "Delete Role (ROLE_DELETE)."

[0032] Step 102: Obtain a resource object list including at least one resource object from a pre-configured database through a resource provision interface;

[0033] The so-called resource object refers to a specific object that can be operated, such as Figure 2 The resource objects in the College of Arts, College of Science, College of Computer Science, and College of Earth Sciences are listed as resource object lists. For example, the lists corresponding to these colleges are college lists. The authentication system obtains the resource object list from a preconfigured database through the resource provision interface, thereby obtaining the resource objects in the resource object list.

[0034] In some embodiments, the resource provider interface first abstracts the resource object, and the abstract resource object contains at least three attributes: ProviderModel (type, id, name). Other attributes can be added by the resource provider interface. Among them, type represents the object that can be granted to the resource, for example Figure 2 As shown in the figure, the authorized objects of the School of Arts, School of Science, School of Computer Science, and School of Earth Sciences are managed by the college; id represents the unique identifier of the resource object and represents a resource object; name represents the Chinese name of the resource object, which is generally used for display.

[0035] In some embodiments, the resource provision interface is a Structured Query Language (SQL) interface or a REST interface. Different resource provision interfaces are configured according to the type of system to which the authorized object belongs, thereby expanding the scope of application of the method.

[0036] In some embodiments, the resource provider interface is configured through ModelProvider(id, type, model_type, model_class, value). Among them, id is used to configure the unique identifier of the resource object, type represents the interface type, including SQL interface and Rest interface. The SQL interface directly connects to the database of the external system through Java Database Connectivity (JDBC) to obtain a list of resource objects; the Rest interface obtains a list of resource objects by querying the external Rest interface; model_type is used to configure the type of objects that can be authorized, such as: user (USER), role (ROLE), etc.; model_class is used to configure the class that can be instantiated by the type of the authorized object. This field can be empty, and the default implementation will be used if it is empty, such as: fnc.ac.entities.DefaultModel; value is used to configure the value of Provider. For example:

[0037] When the resource provider interface is a SQL interface, its value can be:

[0038] "SELECT KEY,VALUE FROM SYS_DICT WHERE TYPE="VENDOR'";

[0039] When the resource provider interface is a REST interface, its value can be:

[0040] {

[0041] "name":"FNC-CM-SERVICE",

[0042] "url":null,

[0043] "path":" / vim / queries",

[0044] "headers":null

[0045] }

[0046] Step 103: Configure a resource permission list for each resource object of the object that can be granted permissions; wherein the resource permission list includes the resource permissions that the object that can be granted permissions has on the resource objects.

[0047] Compared with system permissions, resource permissions refer to permissions for specific operation objects in addition to permission description information. For example, if the object that can be granted permissions is a "province", the corresponding resource permission is the permission to "read data (READ_DATA)" on the resource object (for example, "Jiangsu" and "Zhejiang").

[0048] In some embodiments, system permissions and resource permissions are configured in the authentication system in the format of Sys(Obj)PermissionItem(id, type, name, label). Sys represents the configuration of system permissions, Obj represents the configuration of resource permissions, id is used to configure the unique identifier of the object that can be granted permissions, which can be a random string; type is used to configure the type of the object that can be granted permissions, such as user (USER), role (ROLE), etc.; name is used to configure the name of the permission, which is generally an ASCII string, for example, the name of the system permission is such as USER_CREATE, and the resource permission is such as READ_DATA; label is the Chinese description of the permission, such as the Chinese description of USER_CREATE is "create user", and the resource permission is such as "read data".

[0049] In an embodiment of the present application, a system permission list of objects that can be granted is configured; wherein the system permission list includes the system permissions possessed by the objects that can be granted; a resource object list including at least one resource object is obtained through a resource provision interface; a resource permission list of each resource object of the objects that can be granted is configured; wherein the resource permission list includes the resource permissions possessed by the objects that can be granted to the resource objects. The resource object list is obtained through the resource provision interface, and it is determined what resource objects are in the resource object list, and then the resource permissions of each resource object are configured for the objects that can be granted, and the system permissions are configured for the objects that can be granted, so that an authentication system can perform system permission authentication and can also add resource objects according to authentication requirements, thereby realizing flexible authentication requirements for resource permissions.

[0050] Figure 3 Another implementation flow diagram of the configuration method of the authentication system provided in the embodiment of the present application is as follows: Figure 3 As shown, the method may include the following steps 301 to 306:

[0051] Step 301: Configure the attribute information of the object that can be granted rights;

[0052] The attribute information includes domain information of the system to which the object to be empowered belongs and identification information of the object to be empowered; wherein, the domain information is used to uniquely identify the system to which it belongs; and the identification information is used to uniquely identify the object to which it can be empowered.

[0053] In some embodiments, domain information is defined by "Zone". The Zone of each external system is uniquely named in the entire authentication system to distinguish it from other external systems, and is generally an ASCII string. In some embodiments, the Zone can be named with the English name of the external system in capital letters. For example, the student management system can be named: UNI_MNG. By setting the unique identification information of the external system, an authentication system can access multiple systems and authenticate multiple systems. And by defining the domain information of each external system, the isolation of the permissions of multiple external systems is achieved in the authentication system.

[0054] In some embodiments, after determining the domain information of the external system, the identification information of the authorized object is configured through ModelType (id, zone, type, label), where id is the unique identifier of the authorized object, Zone is the external system to which the authorized object belongs; type is the type of the authorized object, for example, USER or ROLE, etc.; label is the Chinese descriptor of the type of the authorized object, the Chinese descriptor of USER is user, the Chinese descriptor of ROLE is role, etc.; in this way, by setting unique identification information for each authorized object, the authorized objects can be shared across systems, supporting the implementation of a set of authentication systems to support multiple different systems through configuration, and ultimately ensuring that a set of authentication systems meets the authentication needs of various different systems.

[0055] Step 302: Configure a system permission list of objects that can be granted permissions; wherein the system permission list includes the system permissions possessed by the objects that can be granted permissions;

[0056] The types of objects that can be granted permissions are users or roles. This means that permissions can be granted not only to roles but also to users, bypassing roles. "Administrator" and "Auditor" are roles, while "Zhang San" and "Li Si" are users.

[0057] In a case where the type of the object to be granted authority is a user, the system authority list includes at least one of the following: creating a user, deleting a user, and modifying a user.

[0058] In a case where the type of the object that can be granted authority is a role, the system authority list includes at least one of the following: create role, delete role, and modify role.

[0059] In other words, when the objects that can be granted permissions are roles, there is also a granting relationship between roles. One role can grant permissions to multiple roles, and one role can also be granted permissions to multiple roles. Through flexible authorization between roles, flexible control of authentication is ultimately achieved.

[0060] Step 303: Configuring the authentication system to access a resource provisioning interface of a system to which the authorized object belongs; wherein the system is used to manage and maintain resource object information;

[0061] It can be understood that the resource provision interface is intended to abstract resource objects and obtain a resource object list that includes at least one resource object after abstraction. Therefore, in some embodiments, regardless of whether the authentication system and the system to which the authorized object belongs belong to the same system, a resource provision interface for the system to which the authorized object belongs is configured, and the resource object list of the system to which the authorized object belongs is obtained through the resource provision interface. This eliminates the need for manual configuration of resource objects and resource object lists, thereby improving configuration efficiency.

[0062] In other embodiments, when the authentication system and the system to which the authorized object belongs are different systems, that is, when the system to which the authorized object belongs is an external system, a resource provision interface is configured, and a resource object list of the system to which the authorized object belongs is obtained through the resource provision interface, thereby avoiding the problem of configuration errors caused by unfamiliarity with the external system during the manual configuration of resource objects and resource object lists, thereby improving the accuracy of configuration and further improving configuration efficiency. In addition, when the authentication system is connected to multiple external systems, the external resource object list is obtained through the resource provision interface, without the need to manually configure for each system, thereby improving configuration efficiency and accuracy. In addition, by connecting to the external system through the resource provision interface, when configuring the permissions of the external system, there is no need to make changes to the external system itself, thereby reducing the intrusion into the external system.

[0063] Step 304: Obtain the resource object list from the system according to the resource providing interface;

[0064] Step 305: Configure a resource permission list for each resource object of the object that can be granted permissions; wherein the resource permission list includes the resource permissions that the object that can be granted permissions has on the resource object.

[0065] In some embodiments, the system permissions and resource permissions of the system to which the accessed authorized object belongs can be configured through Sys(Obj)PermissionItem(id,zone,type,name,label); wherein, id is used to configure the unique identifier of the authorized object, which can be a random string; Zone is the external system to which the authorized object belongs; type represents the type of the authorized object, such as user (USER), role (ROLE), etc.; name is used to configure the name of the permission, which is generally an ASCII string, for example, the name of the system permission is such as USER_CREATE, and the resource permission is such as READ_DATA; label is the Chinese description of the permission, such as the Chinese description of USER_CREATE is "create user", and the resource permission is such as "read data".

[0066] Step 306: associate and store the attribute information with the system permission list; and associate and store the attribute information with the resource permission list of each resource object.

[0067] In some embodiments, the attribute information can be stored in association with the system permission list; and the attribute information can be stored in association with the resource permission list of each resource object in the authentication system. In this way, when the authentication connection receives an authentication request, the authentication request can be authenticated by obtaining the permission list of the authenticated object pre-stored in the authentication system.

[0068] The present application provides an authentication method for an electronic device. The method may be applied to an electronic device. During implementation, the electronic device may be any type of device with information processing capabilities, such as a personal computer, a laptop computer, a server, a cluster server, a mobile phone, or a tablet computer. The functions implemented by the method may be implemented by a processor in the electronic device calling program code. The program code may be stored in a computer storage medium. Therefore, the electronic device includes at least a processor and a storage medium.

[0069] Figure 4 The implementation flow diagram of the authentication method provided in the embodiment of the present application is as follows: Figure 4 As shown, the method may include the following steps 401 to 403:

[0070] Step 401: In response to the authentication request, determine the permission information to be verified of the authenticated object;

[0071] In some embodiments, the authentication system receives an authentication request from the system to which the authenticated object belongs, and the authentication request carries the authenticated object and the permission information to be verified. It is understandable that the authentication request includes a system authentication request and a resource authentication request, and the permission information to be verified carried by different authentication requests is also different. For example, the permission information to be verified carried in the system authentication request is the domain information (Zone), the identification information of the authenticated object (grantee), and the information to be verified (permissions); the information to be verified carried in the resource authentication request is the domain information (Zone), the identification information of the authenticated object (grantee), the information to be verified (permissions), and the resource object to be verified (model).

[0072] Step 402: Obtain a pre-configured permission list of the authenticated object from a pre-configured authentication system; wherein the permission list includes system permissions and / or resource permissions possessed by the authenticated object;

[0073] In some embodiments, after determining the authenticated object based on its identification information, the system permission list and resource permission list owned by the authenticated object can be directly obtained from a pre-configured authentication system without determining the type of authentication request, thereby simplifying the authentication operation.

[0074] In other embodiments, the authentication type can be first determined based on the authentication request, and the permission list corresponding to the authentication type can be obtained. For example, if the authentication type is determined to be resource authentication, a resource permission list can be obtained; if the authentication type is determined to be system authentication, a system permission list can be obtained. The authentication type can be determined based on the interface called by the authentication request or the permission information to be verified carried in the request. For example, if the information to be verified carries a resource object to be verified, the authentication type of the authentication request is determined to be resource authentication; for another example, if the interface called by the authentication request is a resource authentication interface, the authentication type of the authentication request is determined to be resource authentication. If the interface called is a system authentication interface, the authentication type of the authentication request is determined to be system authentication. By obtaining the permission list corresponding to the authentication type, when matching the information to be verified, the number of permissions to be matched can be reduced, thereby improving the authentication efficiency.

[0075] Step 403: Verify the permission information to be verified according to the permission list.

[0076] In some embodiments, the information to be verified is matched with the obtained permission list. If they match, the authentication is successful, and the authentication system sends a message of successful authentication to the system to which the authenticated object belongs. Otherwise, a message of failed authentication is sent to the system to which the authenticated object belongs.

[0077] The embodiment of the present application determines the permission information to be verified of the authenticated object in response to an authentication request; obtains a pre-configured permission list of the authenticated object; wherein the permission list includes the system permissions and / or resource permissions possessed by the authenticated object; and verifies the permission information to be verified based on the permission list. In this way, during authentication, both resource permissions and system permissions can be authenticated.

[0078] Figure 5 Another implementation flow diagram of the authentication method provided in the embodiment of the present application is as follows: Figure 5 As shown, the method may include the following steps 501 to 504:

[0079] Step 501: In response to an authentication request, determine the permission information to be verified of the authenticated object;

[0080] Step 502: Determine attribute information of the authenticated object according to the authentication request;

[0081] In some embodiments, the attribute information includes domain information of the system to which the authenticated object belongs and identification information of the authenticated object; the identification information of the authenticated object is a user identification;

[0082] It should be understood that at different stages of authentication, the identification information of the authenticated object will be assigned different values. For example, when it is necessary to determine the user permissions corresponding to the user, the identification information of the authenticated object is assigned to the user identifier. When it is necessary to determine the role permissions corresponding to the role associated with the user, the identification of the authenticated object is assigned to the role identifier.

[0083] Step 503: Acquire a permission list associated with the attribute information from a pre-configured authentication system; obtain the associated permission list through the attribute information to ensure that the acquired permission list can authenticate the current authentication request.

[0084] In some embodiments, the authentication system first determines a pre-configured list of role identifiers associated with the user identifier;

[0085] In some embodiments, a list of role identifiers associated with a user identifier is pre-configured and stored in an authentication system, and each role identifier corresponds to a role.

[0086] In some embodiments, a preconfigured role authority list associated with the domain information and the i-th role identifier in the role identifier list and a preconfigured user authority list associated with the domain information and the user identifier may be obtained; i is a positive integer.

[0087] In other words, regardless of whether the authentication request corresponds to system authentication or resource authentication, the user's corresponding user permission list and the role permission list of the user's associated role are directly obtained. This eliminates the need to determine the type of authentication request, simplifying the authentication operation.

[0088] In other embodiments, the authentication method requested by the authentication request may be determined first, and then the list associated with the attribute information may be determined according to the authentication method;

[0089] In the case where the authentication mode is a system authority verification mode, obtaining a pre-configured system authority list associated with the domain information and the role identifier or user identifier; wherein the system authority list includes the system authorities possessed by the authenticated object;

[0090] That is, when the authentication method is the system authority verification method, a pre-configured role system authority list associated with the domain information and the role identifier is obtained; and a pre-configured user system authority list associated with the domain information and the user identifier is obtained.

[0091] In the case where the authentication method is a resource permission verification method, the resource object to be verified of the authenticated object is determined; and, based on the domain information, the role identifier or the user identifier, and the resource object to be verified, an associated pre-configured resource permission list is obtained; wherein the resource permission list includes the resource permissions that the authenticated object has on the resource object.

[0092] If the authentication method is resource permission verification, a pre-configured resource system permission list associated with the domain information and the role identifier is obtained; and a pre-configured resource system permission list associated with the domain information and the user identifier is also obtained. This way, the corresponding permission list is obtained based on the authentication method, eliminating the need to simultaneously obtain both the system permission list and the resource permission list, reducing the number of permissions that need to be matched and compared, and improving authentication efficiency.

[0093] Step 504: Verify the permission information to be verified according to the permission list.

[0094] Determine whether the permission information to be verified matches the information in the currently acquired role permission list and the user permission list.

[0095] In some embodiments, the information to be verified can be directly matched with the information in the obtained permission list, that is, the information to be verified can be matched with the information in the user permission list first. If they match, the verification is successful; if they do not match, the information to be verified is matched with the information in the i-th role permission list. If they match, the verification is successful; if they do not match, the information to be verified is matched with the information in the role permission list corresponding to the i+1-th role identifier, until the permission list associated with each role identifier in the role identifier list is traversed and the result is no match, and the verification fails.

[0096] In other embodiments, the currently acquired role permission list is also merged with the user permission list to remove duplicates to obtain a target permission list; and it is determined whether the permission information to be verified matches the information in the target permission list.

[0097] By merging and deduplicating the currently acquired role permission list and user permission list, duplicate information in the role permission list and user permission list is deleted. This can reduce the amount of information that needs to be matched and compared during authentication, thereby improving authentication efficiency.

[0098] If the permission information to be verified matches the information in the target permission list, the verification is successful; if it does not match, obtain the pre-configured role permission list associated with the i+1th role identifier in the role identifier list, and determine whether the permission information to be verified matches the role permission list corresponding to the i+1th role identifier and the information in the user permission list, until the permission lists associated with each role identifier in the role identifier list are traversed and the results are all mismatched, and the verification fails.

[0099] For example, assuming that the external system wants to identify whether user A has permission B, then an exemplary process for verifying the permission information to be verified is to determine the role identifier corresponding to user A, such as "1", "2", and "3", which correspond to role 1, role 2, and role 3 respectively. First, obtain the user permission list of user A and the role permission list of role 1. Assuming that the information in the user permission table or the role permission list of role 1 can match permission B, the verification is successful. If role 1, role 2, role 3, or the user permission table does not match permission B, the verification fails. In this way, in a recursive manner, it is determined in turn whether the user and its corresponding color-coded permission list match the permission information to be verified; only the role permission list of the role corresponding to one user is obtained for matching each time. If a match can be made, there is no need to continue to obtain the role permission list, nor is there any need to obtain the role permission lists of all the roles corresponding to the user for matching, which reduces the amount of permission information that needs to be matched and improves authentication efficiency.

[0100] With the promotion and application of microservice frameworks, the functions of different systems are broken down into smaller parts, and modules with the same functions are continuously integrated. However, due to the different authentication requirements of different systems, the barriers of their certification and authentication modes are difficult to break. In the context of the continuous promotion of microservices, authentication modules are difficult to integrate, and the phenomenon of repeated design, development, deployment and maintenance is becoming increasingly serious. The role-based authentication model (RBAC) avoids the solution of directly binding permissions to users by adding a layer of role model. Users can directly change permissions in batches by changing roles, or they can modify role permissions to achieve the purpose of batch modifying the permissions owned by users. The RBAC authentication model has many implementation solutions for solving authentication needs in specific business scenarios, but it has certain shortcomings in responding to multiple different needs through a unified model in multi-system scenarios. The present invention provides a new method of decentralization and domain division that is applicable to different authentication needs in multi-system situations.

[0101] (1) Related RBAC-based decentralized management solutions have strong domain relevance, such as private cloud, home business, or enterprise file systems. They are highly targeted. The permission models of different systems need to be designed, developed, deployed, and maintained separately. There are natural barriers between the authentication modules of different systems. At the same time, the user systems of different systems are also independent of each other. Logins to different systems can only use single sign-on authentication using a third-party authentication system.

[0102] (2) In order to improve the flexibility of permission control, a method that is relatively close to the present invention is to introduce the concepts of user groups, collaborators and permission sets, set the subjects as users and groups, and a group contains multiple users. The permissions on the user or group are used to determine whether the relevant permissions are possessed.

[0103] (3) Regarding the authority management of resource objects, a method that is relatively close to the present invention in related solutions is to achieve resource authority management by constructing a resource object management module, an authorization and authentication management module, and a authority resource management module. First, based on the object management module, the entities of the application system are associated, and the associated objects only contain abstract features; then, based on the authority resource management module, the authority is modeled, and the resources are decentralized and managed by domains; finally, based on the authorization and authentication management module, the authority resources are authorized to entity objects containing identity features, and authentication is performed when the entity objects access the authority resources.

[0104] The shortcomings of related technologies are mainly as follows:

[0105] (1) By pre-defining permissions and assigning different permissions to different roles and users, it is impossible to handle the integrated development of different authentication requirements in multi-system scenarios. The authentication module needs to be repeatedly designed, coded, deployed, and maintained. Since the authentication system is independent, the user and authentication system must also be independent of each other. It is necessary to introduce a third-party authentication system such as CAS single sign-on to achieve cross-system authentication operations, which further increases the workload of system development and maintenance.

[0106] (2) Most of the related authentication schemes are highly invasive. When the business system is connected to the authentication function, a lot of new code needs to be developed, which increases the development difficulty and maintenance cost of the system.

[0107] (3) The role-based permission management model mainly solves the problem of system permission authentication, while the resource-related authentication requirements are mostly handled in a pre-fixed form, such as only processing permissions for resources such as menus and provinces.

[0108] Based on this, the following describes an exemplary application of the embodiment of the present application in a practical application scenario.

[0109] The improved RBAC general decentralization and domain division method studied in the present invention refers to the "authority-role-user" design concept of the RBAC model, and proposes a new decentralization and domain division method based on the improved RBAC. In terms of authority design, the authority is vertically divided into system authority (Permission) and resource authority (ACL, or object authority), and horizontally divided into different business types according to business and scenarios, such as province (PROVINCE), user (USER), menu (MENU), etc. In order to ensure the flexibility of design, authority can not only be assigned to roles, but also bypass the role and directly assigned to the user. In terms of role design, a role can be granted to multiple roles, and a role can also be granted to multiple roles. Through the flexible empowerment between roles, flexible control of authority is ultimately achieved. The isolation of system authority and resource authority of different systems is achieved through "domain", and loose coupling with each system is achieved through resource provider, which ultimately ensures that a set of authentication systems meets the authentication requirements of various different systems.

[0110] 1. Definition of key concepts

[0111] (1) Permissions, roles, and users

[0112] In the RBAC permission management model, permissions, roles, and users are the three core models. When these three models are mapped to real life, permissions are used to describe the ability of a user to perform an action, such as "approving work orders" or "deleting users." Roles such as "administrator" and "auditor" are roles, and users such as "Zhang San" are users. Figure 6The diagram of the dependency relationship among permissions, roles and user models provided in the embodiment of this application is as follows: Figure 6 As shown, the line 1 between permissions and roles indicates that permissions are associated with roles, and the line 2 between roles and users indicates that users gain permissions from roles by becoming members of those roles. The relationship between users and roles is many-to-many; that is, a user can be assigned to multiple roles, and a role can be assigned to multiple users. Similarly, the relationship between roles and permissions is many-to-many.

[0113] In order to improve the flexibility of the model, in the embodiment of the present application, Figure 6 As shown, the line 3 between roles indicates that there is a grant relationship between roles. That is, one role can be assigned to another role; the assigned role has all the permissions of the assigned role. For example, if role A is assigned to role B, then B has all the permissions of A. In addition, the line 4 between permissions and users indicates that permissions can be directly assigned to specific users, and there is also a many-to-many relationship between users and permissions.

[0114] (2) System permissions and resource permissions

[0115] Figure 7 A schematic diagram of vertical classification of permissions provided in the embodiment of this application is shown as follows: Figure 7 As shown in the figure, based on whether the authentication target has specific object information, permissions are vertically divided into two categories: system permissions (Permission) and resource permissions (ACL, also known as object permissions) (for details on horizontal and vertical classification, see later).

[0116] System permissions: These permissions are not specific to the operation object, but only have permission description information. For example, the "ROLE" type has system permissions such as "Create Role (ROLE_CREATE)" and "Delete Role (ROLE_DELETE)".

[0117] Resource permissions: have specific operation objects. For example, the permissions of the "province (PROVINCE)" type include the "read data (READ_DATA)" permissions of "Jiangsu", "Zhejiang", etc.

[0118] (3)Zone

[0119] "Domain" is called "Zone" in English. Zone names are globally unique and are used to isolate the permission models of different systems. Therefore, when integrating a new system's permission model, a zone must be defined. To achieve consistent user architectures across different systems and support unified login, the zones in this invention only isolate permissions, including system permissions and resource permissions, while roles and users can access permissions across zones.

[0120] (4) Horizontal and vertical classification

[0121] Horizontal Classification: Each zone's permissions can be categorized horizontally based on different resource models or scenarios. For example, in the 5G Slice Management System (Zone = NSMF), permissions can be divided into five categories: role, user, province, resource pool, and menu, representing five resource models. Permission categorization can overlap across different zones. For example, both the Zone = NSMF and the Zone = Student Management System have role and user categorization.

[0122] Vertical classification: System permissions and resource permissions are vertical classifications of permissions. Each category in the horizontal type can have system permissions or resource permissions.

[0123] The following will use a specific case to illustrate the relationship and usage of several models. Figure 2 The university management system's permissions model is shown in Figure 1. Users, roles, and college management are horizontally categorized, while system permissions and resource permissions are vertically categorized. Both system permissions and resource permissions for each horizontal permission type can be left blank. The "College Management" permission type includes three resource permissions: "Manage College Information," "Publish News," and "Manage Students." These three specific permissions can be assigned to different colleges.

[0124] (5) Resource Provider

[0125] Resource permissions require access to different resource list details, and resource lists in different systems are also different, and resource management is often managed by each system. The present invention achieves docking with external systems through the Provider interface, reducing intrusion into other systems.

[0126] Figure 8 Schematic diagram of the implementation scheme of the resource provider interface (Provider) provided in the embodiment of this application, such as Figure 8 As shown, there are two specific implementation solutions: SqlProvider and RestProvider. SqlProvider directly connects to the database of the external system through JDBC, and RestProvider (HTTP interface) obtains resource details by querying the Rest interface provided externally.

[0127] The resource provider first needs to abstract the resource object. Regardless of the type of provider, its abstract resource object contains at least three attributes: ProviderModel (type, id, name). Other attributes can be added by the provider. The provider obtains the list of abstracted resource objects from the external system through the provider. Among them:

[0128] type: the horizontal type of the resource;

[0129] id: the primary key of the resource. This attribute uniquely represents a resource object.

[0130] name: the Chinese name of the resource object, generally used for display, etc.

[0131] Permission design and access:

[0132] The design phase occurs before a new system is implemented, while the operation and maintenance of the new system after implementation constitutes the operational phase. The design phase primarily involves the design of relevant metadata, including zones, system permissions, resource permissions, and resource providers. The operational phase primarily involves the creation of roles and users. This section primarily describes the tasks required during the design phase.

[0133] Step 1: Define a zone. A zone is an ASCII string and must be globally unique across all systems. Zones are typically named after the system's English name in capital letters. For example, a university management system might be named UNI_MNG.

[0134] Step 2: Define the resource model type ModelType (i.e. horizontal classification). Model types are divided by Zone, and each Zone has a set of resource model definitions, the format of which is:

[0135] ModelType(id,zone,type,label)

[0136] in:

[0137] id: primary key, globally unique, can be a random string

[0138] zone: the domain to which the model belongs

[0139] type: model type, such as USER, ROLE, etc.

[0140] label: Chinese descriptor of the model, such as user, role, etc.

[0141] Step 3: Define system permissions and resource permissions. System permissions and resource permissions are defined in the same way, and the format is:

[0142] Sys(Obj)PermissionItem(id,zone,type,name,label)

[0143] in:

[0144] id: primary key, globally unique, can be a random string

[0145] zone: the domain to which the model belongs

[0146] type: model type, such as USER, ROLE, etc.

[0147] name: The name of the permission, an ASCII string, unique within the same zone. System permissions such as USER_CREATE, resource permissions such as READ_DATA

[0148] label: Chinese descriptor of the model, system permissions such as "create user", resource permissions such as "read data"

[0149] Step 4: Define the resource provider. The format is:

[0150] ModelProvider(id,type,model_type,model_class,value)

[0151] in:

[0152] id: primary key, globally unique, can be a random string

[0153] type: Provider type, SQL or REST

[0154] model_type: model type, such as USER, ROLE, etc.

[0155] model_class: The class that the model can be instantiated. This field can be empty, otherwise the default implementation will be used. For example: fnc.ac.entities.DefaultModel

[0156] value: The value of the provider. Example:

[0157] SqlProvider, the value of its value can be:

[0158] "SELECT KEY,VALUE FROM SYS_DICT WHERE TYPE="VENDOR'";

[0159] RestProvider, its value can be:

[0160] {

[0161] "name":"FNC-CM-SERVICE",

[0162] "url":null,

[0163] "path":" / vim / queries",

[0164] "headers":null

[0165] }

[0166] Authentication process:

[0167] Both users (USER) and roles (ROLE) are carriers of permissions, so both users and roles can be authenticated. This invention abstracts users and roles into grantees, or "entity objects," with USER → Grantee and ROLE → Grantee (an example of an object identifier to be authenticated). The authentication process is uniformly abstracted into authenticating grantees.

[0168] The main authentication process for system permissions and resource permissions is the same: both recursively find all roles included in the current grantee and then determine whether the permissions are met. Therefore, the authentication process is divided into three sub-sections: the main authentication process, the system authentication sub-process, and the resource permission sub-process.

[0169] Figure 9 A schematic diagram of the main authentication process provided in the embodiment of the present application is shown as follows: Figure 9 As shown, during authentication, it is necessary to determine the zone, grantee, and Checker (authentication method). The zone is to determine the domain where the current authentication is located; the grantee is to determine the user or role information currently used for verification, mainly the ID of the user or role; and the Checker is the authentication method, which belongs to a sub-process and includes two categories: system permissions and resource permissions. The two types of authentication methods are detailed in the following two sections: System Authentication Sub-Process and Resource Permission Sub-Process.

[0170] Step 1: Determine whether it is system permission verification or resource permission authentication, and name it Checker.

[0171] Step 2: Initialize an empty list named visited to store the Grantees (IDs) that have been checked, including roles and users.

[0172] Step 3: Determine the input parameters Input (zone, grantee, Checker).

[0173] Step 4: Recursively authenticate all roles contained in the current (zone, grantee) state. If a role is found to pass authentication during the recursive process, the entire recursion ends and authentication passes. If all roles fail authentication during the recursive process, the entire authentication fails. The recursive process is as follows:

[0174] Recursive process:

[0175] Step 1: Check whether the visited list contains the grantee to be checked. If so, the current grantee authentication fails and this recursion ends; if not, the current grantee is added to the visited list.

[0176] Step 2: Execute the Checker sub-process. If the Checker passes, the current Grantee authentication passes, and the recursive process ends. If the Checker authentication fails, proceed to Step 3.

[0177] Step 3: Get the list of roles owned by the current grantee. If roles is empty, the current grantee fails authentication and the recursion ends. If it is not empty, each role in the list is taken out in turn, assigned to grantee, and the recursion is continued.

[0178] System permission authentication sub-process:

[0179] Figure 10 The schematic diagram of the system permission authentication sub-process provided for this application is as follows: Figure 10 As shown;

[0180] Step 1: Determine the input parameters CheckerInput(zone, grantee, permissions), where permissions is the permission information to be checked.

[0181] Step 2: Determine the grantee type. If it is a USER type, call the user interface to obtain the current user's permission list; if it is a ROLE type, call the role interface to obtain the current role's permission list.

[0182] Step 3: Merge and de-duplicate the obtained permission list. Determine whether the de-duplicate permission list contains all the permissions information. If it does, authentication succeeds; otherwise, authentication fails.

[0183] Figure 11 The schematic diagram of the resource permission authentication sub-process provided for this application is as follows: Figure 11 As shown;

[0184] Step 1: Determine the input parameters CheckerInput (zone, grantee, model, permissions), where model is the resource information to be verified and permissions is the permission information to be verified.

[0185] Step 2: Determine the grantee type. If it is a USER type, call the user interface to obtain the resource permissions list of the current user on the model resource; if it is a ROLE type, call the role interface to obtain the resource permissions list of the current role on the model resource.

[0186] Step 3: Merge and de-duplicate the obtained permission list. Determine whether the de-duplicate permission list contains all the permissions information. If it does, authentication succeeds; otherwise, authentication fails.

[0187] (1) Based on the existing RBAC solution, the relationship between permissions, roles, and users is improved to achieve flexible control of permissions. Permissions can be assigned not only to roles but also to users directly, bypassing roles. In terms of role design, one role can be assigned to multiple roles, and one role can also be assigned to multiple roles. There is a many-to-many relationship between roles. Users or roles assigned to relevant roles or permissions have all the permissions contained therein.

[0188] (2) By isolating the permission models of different systems through "Zones", a decentralized and domain-based management system can be implemented to meet the authentication needs of multiple systems. At the same time, users and roles can be shared across domains, achieving the purpose of cross-system login authentication and authorization for the same user. When connecting to a new system, it is only necessary to configure Zone (ModelType, Sys(Obj)PermissionItem, ModelProvider) to quickly meet the system's authentication needs without the need for redevelopment and deployment, or restarting the system.

[0189] (3) Permissions are divided vertically into system permissions and resource permissions, and horizontally into different business types according to business and scenarios, such as province (PROVINCE), user (USER), menu (MENU), etc., which can simultaneously meet the authentication of system type permissions and resource object type authentication.

[0190] (4) ModelProvider is introduced to achieve docking with resource objects maintained by external systems, reducing the intrusion into other systems. Different types of interfaces can be accessed through different providers: if the business system database can be directly connected, resources can be introduced through SqlProvider; if a Rest interface is provided, resources can be introduced through RestProvider.

[0191] Based on the foregoing embodiments, an embodiment of the present application provides a configuration device for an authentication system, which includes the modules included and the units included in each module, and can be implemented by a processor; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP) or a field programmable gate array (FPGA), etc.

[0192] Figure 12 This is a schematic diagram of the configuration device of the authentication system according to the embodiment of the present application. Figure 12 As shown, the apparatus 120 includes a configuration module 121 and a first acquisition module 122, wherein:

[0193] Configuration module 121 is used to configure a system permission list of objects that can be granted permissions; wherein, the system permission list includes the system permissions possessed by the objects that can be granted permissions; in some embodiments, the type of the objects that can be granted permissions is a user or a role; when the type of the objects that can be granted permissions is a user, the system permission list includes at least one of the following: creating a user, deleting a user, and modifying a user; when the type of the objects that can be granted permissions is a role, the system permission list includes at least one of the following: creating a role, deleting a role, and modifying a role.

[0194] A first acquisition module 122 is configured to acquire a resource object list including at least one resource object through a resource provision interface;

[0195] The configuration module 121 is further configured to configure a resource permission list for each resource object of the object that can be granted permissions; wherein the resource permission list includes the resource permissions that the object that can be granted permissions has on the resource object.

[0196] In some embodiments, the configuration module 121 is further configured to configure attribute information of the authorized object; store the attribute information in association with the system permission list; and store the attribute information in association with the resource permission list of each resource object. The attribute information includes domain information of the system to which the authorized object belongs and identification information of the authorized object; wherein the domain information is used to uniquely identify the system to which it belongs; and the identification information is used to uniquely identify the authorized object.

[0197] In some embodiments, the configuration module 121 is configured to configure a resource provisioning interface for the authentication system to access the system to which the authorized object belongs; wherein the system is used to manage and maintain resource object information; and to obtain the resource object list from the system according to the resource provisioning interface. In some embodiments, the resource provisioning interface is a SQL interface or a REST interface.

[0198] Based on the foregoing embodiments, an embodiment of the present application provides an authentication device, which includes the modules included and the units included in each module, and can be implemented by a processor; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP) or a field programmable gate array (FPGA), etc.

[0199] Figure 13 This is a schematic diagram of the structure of the authentication device according to the embodiment of the present application. Figure 13 As shown, the device 130 includes a determination module 131, a second acquisition module 132 and a verification module 133, wherein:

[0200] A determination module 131 is configured to determine, in response to an authentication request, permission information to be verified of the authenticated object;

[0201] The second acquisition module 132 is configured to acquire a pre-configured permission list of the authenticated object from a pre-configured authentication system; wherein the permission list includes system permissions and / or resource permissions possessed by the authenticated object;

[0202] The verification module 133 is configured to verify the permission information to be verified according to the permission list.

[0203] In some embodiments, the second acquisition module 132 is configured to determine attribute information of the authenticated object according to the authentication request; and acquire a permission list associated with the attribute information.

[0204] In some embodiments, the attribute information includes domain information of the system to which the authenticated object belongs and identification information of the authenticated object; the second acquisition module 132 is configured to determine a pre-configured role identification list associated with the user identification; obtain a pre-configured role permission list associated with the domain information and the i-th role identification in the role identification list and a pre-configured user permission list associated with the domain information and the user identification; i is a positive integer;

[0205] Correspondingly, the verification module 133 is used to determine whether the permission information to be verified matches the information in the currently obtained role permission list and the user permission list; if they match, the verification is successful; if they do not match, the pre-configured role permission list associated with the i+1th role identifier in the role identifier list is obtained, and it is determined whether the permission information to be verified matches the role permission list corresponding to the i+1th role identifier and the information in the user permission list, until the permission list associated with each role identifier in the role identifier list is traversed and the result is no match, and the verification fails.

[0206] In some embodiments, the verification module 133 is used to merge and de-duplicate the currently acquired role permission list and the user permission list to obtain a target permission list; and determine whether the permission information to be verified matches the information in the target permission list.

[0207] In some embodiments, the second acquisition module 132 is used to determine the authentication method requested by the authentication request; when the authentication method is a system permission verification method, obtain a pre-configured system permission list associated with the domain information and the role identifier or user identifier; wherein the system permission list includes the system permissions possessed by the authenticated object; when the authentication method is a resource permission verification method, determine the resource object to be verified of the authenticated object; and, based on the domain information, the role identifier or user identifier and the resource object to be verified, obtain the associated pre-configured resource permission list; wherein the resource permission list includes the resource permissions possessed by the authenticated object over the resource object.

[0208] The description of the above device embodiment is similar to the description of the above method embodiment and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of this application, please refer to the description of the method embodiment of this application for understanding.

[0209] It should be noted that in the embodiments of this application Figure 12 The configuration device of the authentication system shown and Figure 13 The module division of the authentication device described above is schematic and represents only a logical functional division. Different division methods may be used in actual implementation. Furthermore, the functional units in the various embodiments of this application may be integrated into a single processing unit, exist physically as separate units, or two or more units may be integrated into a single unit. These integrated units may be implemented in hardware or software functional units. Alternatively, they may be implemented in a combination of software and hardware.

[0210] It should be noted that, in the embodiment of the present application, if the above method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling an electronic device to execute all or part of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific combination of hardware and software.

[0211] An embodiment of the present application provides an electronic device, Figure 14 This is a schematic diagram of the hardware entity of the electronic device according to the embodiment of the present application, such as Figure 14 As shown, the electronic device 140 includes a memory 141 and a processor 142. The memory 141 stores a computer program that can be run on the processor 142. When the processor 142 executes the program, the steps in the method provided in the above embodiment are implemented.

[0212] It should be noted that the memory 141 is configured to store instructions and applications executable by the processor 142, and can also cache data to be processed or processed by the processor 142 and various modules in the electronic device 140 (for example, image data, audio data, voice communication data and video communication data), which can be implemented through flash memory (FLASH) or random access memory (Random Access Memory, RAM).

[0213] An embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the method provided in the above embodiment are implemented.

[0214] An embodiment of the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the steps of the method provided in the above method embodiment.

[0215] It should be noted that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium, storage medium, and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0216] It should be understood that "one embodiment" or "an embodiment" or "some embodiments" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are for description only and do not represent the advantages and disadvantages of the embodiments. The above description of the various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced to each other. For the sake of brevity, they will not be repeated here.

[0217] The term "and / or" in this article is only a description of the association relationship between associated objects, indicating that there can be three relationships. For example, object A and / or object B can mean: object A exists alone, object A and object B exist at the same time, and object B exists alone.

[0218] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0219] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The embodiments described above are merely illustrative. For example, the division of the modules is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or modules can be electrical, mechanical or other forms.

[0220] The modules described above as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules; they may be located in one place or distributed across multiple network units; some or all of the modules may be selected according to actual needs to achieve the purpose of this embodiment.

[0221] In addition, all functional modules in the embodiments of the present application can be integrated into one processing unit, or each module can be a separate unit, or two or more modules can be integrated into one unit; the above-mentioned integrated modules can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0222] Those skilled in the art will understand that all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, and other media that can store program codes.

[0223] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling an electronic device to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks or optical disks.

[0224] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0225] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0226] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0227] The above is merely an embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. An authentication method, characterized in that: The method comprises: In response to the authentication request, determining the permission information to be verified of the authenticated object; Obtaining a pre-configured permission list of the authenticated object from a pre-configured authentication system; wherein the permission list includes system permissions and resource permissions possessed by the authenticated object; Verifying the permission information to be verified according to the permission list; Wherein, the obtaining of the pre-configured permission list of the authenticated object comprises: determining attribute information of the authenticated object according to the authentication request; obtaining the permission list associated with the attribute information; The configuration process of the authentication system includes: configuring a system permission list of objects that can be granted; wherein the system permission list includes the system permissions possessed by the objects that can be granted; obtaining a resource object list including at least one resource object through a resource provision interface; configuring a resource permission list for each resource object of the objects that can be granted; wherein the resource permission list includes the resource permissions possessed by the objects that can be granted on the resource objects; The method also includes: configuring attribute information of the object that can be granted authority; storing the attribute information in association with the system permission list; and storing the attribute information in association with the resource permission list of each resource object; the attribute information includes domain information of the system to which the object that can be granted authority belongs and identification information of the object that can be granted authority; wherein the domain information is used to uniquely identify the system to which it belongs; and the identification information is used to uniquely identify the object that can be granted authority.

2. The method according to claim 1, characterized in that The attribute information includes domain information of the system to which the authenticated object belongs and identification information of the authenticated object; The identification information of the authenticated object is the user identification; The obtaining of a permission list associated with the attribute information includes: determining a list of preconfigured role identifiers associated with the user identifier; Obtaining a pre-configured role authority list associated with the domain information and the i-th role identifier in the role identifier list and a pre-configured user authority list associated with the domain information and the user identifier; i is a positive integer; Accordingly, verifying the permission information to be verified according to the permission list includes: Determine whether the permission information to be verified matches the information in the currently acquired role permission list and the user permission list; If they match, the verification is successful; if they do not match, obtain the pre-configured role permission list associated with the i+1th role identifier in the role identifier list, and determine whether the permission information to be verified matches the role permission list corresponding to the i+1th role identifier and the information in the user permission list, until the permission lists associated with each role identifier in the role identifier list are traversed and the results are all mismatched, and the verification fails.

3. The method according to claim 1, characterized in that The obtaining of a resource object list including at least one resource object through a resource providing interface includes: Configuring the authentication system to access a resource provision interface of a system to which the authorized object belongs; wherein the system is used to manage and maintain resource object information; According to the resource providing interface, the resource object list is obtained from the belonging system.

4. The method according to claim 1, wherein The type of the object that can be granted authority is user or role; In the case where the type of the object to be granted authority is a user, the system authority list includes at least one of the following: creating a user, deleting a user, and modifying a user; In a case where the type of the object that can be granted authority is a role, the system authority list includes at least one of the following: create role, delete role, and modify role.

5. An authentication device, characterized in that: include: A configuration module, for configuring a system permission list of objects that can be granted authority; wherein the system permission list includes the system permissions possessed by the objects that can be granted authority; further configured with a resource permission list for each resource object of the objects that can be granted authority; wherein the resource permission list includes the resource permissions possessed by the objects that can be granted authority over the resource objects; further configured with attribute information of the objects that can be granted authority; storing the attribute information in association with the system permission list; and storing the attribute information in association with the resource permission list of each resource object; the attribute information includes domain information of the system to which the objects that can be granted authority belong and identification information of the objects that can be granted authority; wherein the domain information is used to uniquely identify the belonging system; and the identification information is used to uniquely identify the objects that can be granted authority; A first acquisition module is configured to acquire a resource object list including at least one resource object through a resource provision interface; A determination module, configured to determine, in response to an authentication request, permission information to be verified of the authenticated object; a second acquisition module, configured to acquire a pre-configured permission list of the authenticated object from a pre-configured authentication system; wherein the permission list includes system permissions and resource permissions possessed by the authenticated object; and further configured to determine attribute information of the authenticated object based on the authentication request; and acquire a permission list associated with the attribute information; A verification module is used to verify the permission information to be verified according to the permission list.

6. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 1 to 4 is implemented.

Images