Authority management method and device, storage medium and electronic equipment

Abstract

The invention relates to an authority management method and device, a storage medium and electronic equipment. The authority management method comprises the steps of obtaining an authority verification request which is used for requesting to verify whether a first object has an operation authority for a first resource, the permission verification request comprises a first object identifier of the first object, a first resource identifier of the first resource, and a first permission identifier for representing an operation permission for the first resource; according to the first object identifier and the first resource identifier, determining a first permission verification identifier of the first object for the first resource; and performing verification according to the first permission verification identifier and the first permission identifier to obtain a verification result for the permission verification request. According to the technical scheme, on the basis of not influencing the permission verification precision, the permission verification efficiency and flexibility can be improved, and the permission verification difficulty can be reduced.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular, to a permission management method, device, storage medium and electronic device. Background Art

[0002] In most existing business systems, permission management is directly or indirectly involved. For example, permission management can be used to manage user operation permissions for resources. Through permission management, the security of resources can be guaranteed. Summary of the invention

[0003] The purpose of the present disclosure is to provide a permission management method, device, storage medium and electronic device to improve the efficiency and flexibility of permission verification and reduce the difficulty of permission verification without affecting the accuracy of permission verification.

[0004] In order to achieve the above-mentioned objectives, in a first aspect, the present disclosure provides a permission management method, including: obtaining a permission verification request, the permission verification request is used to request verification of whether a first object has operation permission for a first resource, the permission verification request includes a first object identifier of the first object, a first resource identifier of the first resource, and a first permission identifier used to characterize the operation permission for the first resource; determining a first permission verification identifier of the first object for the first resource based on the first object identifier and the first resource identifier; and performing verification based on the first permission verification identifier and the first permission identifier to obtain a verification result for the permission verification request.

[0005] In a second aspect, the present disclosure provides a permission management device, comprising: an acquisition unit, used to acquire a permission verification request, the permission verification request is used to request verification of whether a first object has operation permission for a first resource, the permission verification request includes a first object identifier of the first object, a first resource identifier of the first resource, and a first permission identifier used to characterize the operation permission for the first resource; a determination unit, used to determine the first permission verification identifier of the first object for the first resource based on the first object identifier and the first resource identifier; a verification unit, used to perform verification based on the first permission verification identifier and the first permission identifier to obtain a verification result for the permission verification request.

[0006] In a third aspect, the present disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the permission management method described in the first aspect.

[0007] In a fourth aspect, the present disclosure provides an electronic device, comprising: a memory on which a computer program is stored; and a processor, configured to execute the computer program in the memory to implement the permission management method described in the first aspect.

[0008] It can be seen that in the embodiment of the present application, the permission verification identifier of the object for the resource is determined through the object identifier and the resource identifier, and then the permission verification identifier is used to implement the object's operation permission verification for the resource, without considering other excessive information of the object, thereby improving the efficiency of permission verification. In addition, since there is no need to consider other excessive information of the object, on the basis of considering less information, the configuration of the object information, or the configuration of the permission identifier and the permission verification identifier, etc. are relatively simple, and the configuration method can also be flexibly selected, which can reduce the difficulty of permission verification and improve the flexibility of permission verification. In addition, although there is no need to consider other excessive information of the object, the information associated with the permission verification identifier is the object identifier and the resource identifier, and the object identifier and the resource identifier can realize the division of the operation permission according to the object and the resource, so that the verification granularity of the operation permission is finer, which will not affect the accuracy of the permission verification and can ensure the security of the resource. Therefore, the technical solution can improve the efficiency and flexibility of permission verification and reduce the difficulty of permission verification on the basis of not affecting the accuracy of permission verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The accompanying drawings are used to provide a further understanding of the present disclosure and constitute a part of the specification. Together with the following specific embodiments, they are used to explain the present disclosure but do not constitute a limitation of the present disclosure. In the accompanying drawings:

[0010] Figure 1 The invention is a structural block diagram of a rights management system according to an exemplary embodiment.

[0011] Figure 2 The present invention is a flowchart of a method for rights management according to an exemplary embodiment.

[0012] Figure 3 The diagram is a schematic diagram of a strategy tree structure according to an exemplary embodiment.

[0013] Figure 4 The diagram is a schematic diagram of a permission tree structure according to an exemplary embodiment.

[0014] Figure 5 The diagram is a schematic diagram of a traversal process based on a permission tree according to an exemplary embodiment.

[0015] Figure 6 The flowchart of another method for managing rights is shown according to an exemplary embodiment.

[0016] Figure 7The present invention is a schematic diagram of a permission update process based on a permission tree according to an exemplary embodiment.

[0017] Figure 8 The figure is a flow chart of authentication of a Ranger component according to an exemplary embodiment.

[0018] Fig. 9 The figure is a structural block diagram of a rights management device according to an exemplary embodiment.

[0019] Fig.10 It is a block diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0020] The specific implementation of the present disclosure is described in detail below in conjunction with the accompanying drawings. It should be understood that the specific implementation described herein is only used to illustrate and explain the present disclosure, and is not used to limit the present disclosure.

[0021] It should be noted that all actions of acquiring signals, information or data in the present disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the device is located and with the authorization given by the owner of the corresponding device.

[0022] At present, in most business systems, permission management is directly or indirectly involved. Through permission management, data security can be guaranteed. These business systems may belong to different industries or different fields. For example, business systems of different enterprises may belong to the financial industry, education industry, Internet industry, etc.

[0023] Permission management can include: permission verification and permission configuration. Permission configuration is the basis of permission verification. After permission configuration is completed, permission verification can be performed based on the configured permissions.

[0024] For example, for companies in the financial industry, the business system will involve batch tasks, which may be Hive Sql (Structured Query Language) type or Spark Sql type, and need to pass permission verification before they can continue to be processed. Batch tasks may be counted in units of ten thousand. In addition, these batch tasks are usually submitted to the permission management end for verification during a fixed time period. For example, batch tasks are generated by processing the data generated the day before in the early morning and flow to downstream applications or reports. Therefore, these tasks will be submitted in batches during the time period from 0:00 to 2:00. At the same time, there may be thousands of tasks submitted, resulting in a lot of processing pressure on the permission management end.

[0025] In the related technology, the permission verification logic adopted is: a single task of the client requests all permissions of the corresponding user from the permission management server, the permission management server queries the database and returns it to the client, and after the client obtains the permission data, it compares the permissions of the resource in the memory for permission verification.

[0026] This permission verification method requires obtaining all permissions of the user. For scenarios where permissions are divided into fine divisions and batch permission verification tasks are performed, the amount of permission data obtained for a single task will also be large, increasing the pressure on the permission management server. In addition, in the scenario of batch tasks, a large amount of permission data needs to be obtained multiple times, which will affect the efficiency of permission verification.

[0027] Based on this, the embodiment of the present disclosure provides a technical solution, in which the permission verification identifier of the object for the resource is determined through the object identifier and the resource identifier, and then the permission verification identifier is used to implement the object's operation permission verification for the resource, without considering too much other information of the object, thereby improving the efficiency of the permission verification.

[0028] Furthermore, since there is no need to consider too much other information about the object, the configuration of the object information, or the configuration of the permission identifier and the permission verification identifier, etc. are relatively simple based on the consideration of less information, and the configuration method can also be flexibly selected, which can reduce the difficulty of permission verification and improve the flexibility of permission verification.

[0029] In addition, although there is no need to consider too much other information about the object, the information associated with the permission verification identifier is the object identifier and resource identifier. The object identifier and resource identifier can realize the division of operation permissions according to objects and resources, making the verification granularity of operation permissions finer, which will not affect the accuracy of permission verification and can ensure the security of resources.

[0030] Figure 1 is a structural block diagram of a rights management system according to an exemplary embodiment. Figure 1 As shown, the rights management system includes: a client 101 and a server 102 .

[0031] The server 102 may be connected to the client 101 via a network. The network is used to provide a medium for a communication link between the server 102 and the client 101. The network may include various connection types, such as a wired communication link, a wireless communication link, etc., which is not limited in the embodiments of the present disclosure.

[0032] It should be understood that Figure 1The server 102, network and client 101 are merely illustrative. Depending on the implementation requirements, there may be any number of servers 102, networks and clients 101. Exemplarily, the server 102 may be a physical server or a server cluster composed of multiple servers, and the client 101 may be installed on electronic devices such as mobile phones, tablets, desktop computers, and laptop computers. It is understood that the embodiments of the present disclosure may also allow multiple clients 101 to access the server 102 at the same time.

[0033] For the server 102 or the client 101, it can be equipped with an authentication component, through which not only the verification of permissions (authentication) but also the management of permission information (authorization) can be realized.

[0034] For example, the authentication component can be Apache Ranger, hereinafter referred to as Ranger. Ranger is a big data component that provides authorization and authentication, and its permission model is PBAC (Policy-Based Access Control). In this permission model, the policy is the largest carrier, under which a set of resources is bound to describe the resources corresponding to the policy, such as libraries and tables. Then, the policy is bound to multiple sets of permission information, and a set of permission information describes the relationship between a user, group or role and a set of permissions.

[0035] It can be seen that Ranger's permission model requires binding a large number of permissions to policies. Furthermore, when applied, a single authentication task needs to request all permissions of the corresponding user (i.e., a set of permission information) from Ranger, resulting in very low authentication efficiency of Ranger.

[0036] Therefore, in the disclosed embodiment, the form of Ranger's permission model is improved, and the policy is no longer bound to multiple sets of permission information. Then, when requesting permission, a single authentication task does not need to request all permission information. The specific improvement method will be described in detail in the subsequent embodiments.

[0037] In addition, the authentication component can be not only a Ranger component, but also a component such as Apache Sentry, which can apply a permission tree structure or have corresponding authentication functions.

[0038] Figure 2 The following is a flowchart of a method for managing rights according to an exemplary embodiment. The method for managing rights includes the following steps:

[0039] Step S21, obtain a permission verification request, the permission verification request is used to request verification of whether the first object has the operation permission for the first resource, the permission verification request includes a first object identifier of the first object, a first resource identifier of the first resource, and a first permission identifier used to characterize the operation permission for the first resource.

[0040] Step S22: determining a first permission verification identifier of the first object with respect to the first resource according to the first object identifier and the first resource identifier.

[0041] Step S23: perform verification according to the first authority verification identifier and the first authority identifier to obtain a verification result for the authority verification request.

[0042] It can be understood that steps S21 to S23 correspond to the permission verification process, which can be applied to Figure 1 The authority management system shown may be executed by a server 102 or a client 101 .

[0043] In some application scenarios, the permission management method is applied to the server 102. In step S21, the server 102 receives the permission verification request sent by the client 101. In step S22, the server 102 determines the first permission verification identifier of the first object for the first resource based on the first object identifier and the first resource identifier. In step S23, the server 102 performs verification based on the first permission verification identifier and the first permission identifier to obtain a verification result for the permission verification request. Finally, the server 102 feeds back the verification result for the permission verification request to the client 101.

[0044] In these application scenarios, the client 101 initiates a permission verification request, the server 102 performs permission verification, and feeds back the permission verification result, which can reduce the pressure on the client 101.

[0045] In other application scenarios, the permission management method is applied to the client 101. In step S21, the client 101 receives a permission verification request initiated by the first object. In step S22, the client 101 synchronizes the first object identifier and the first resource identifier to the server 102, so that the server 102 determines the first permission verification identifier of the first object for the first resource based on the first object identifier and the first resource identifier. In step S23, the client 101 performs verification based on the first permission verification identifier and the first permission identifier fed back by the server 102 to obtain a verification result for the permission verification request.

[0046] In these application scenarios, the server 102 determines the first permission verification identifier, and the client 101 performs verification according to the first permission verification identifier, which can reduce the pressure on the server 102.

[0047] In other application scenarios, the permission management method is applied to the client 101. In step S21, the client 101 receives a permission verification request initiated by the first object. In step S22, the client 101 determines the first permission verification identifier of the first object for the first resource based on the first object identifier and the first resource identifier. In step S23, the client 101 performs verification based on the first permission verification identifier and the first permission identifier to obtain a verification result for the permission verification request.

[0048] In these application scenarios, the first permission verification identifier is determined by the client 101, and the client 101 performs verification according to the first permission verification identifier without the help of the server 102, thereby reducing hardware costs.

[0049] Permission verification requests can come from external objects or from local upstream applications or upstream tasks.

[0050] The first object may be a user or an application, etc. Correspondingly, the first object identifier may represent a user or an application, etc. For example, the first object identifier may be a user identity identifier, an application name identifier, etc.

[0051] The first resource may be a resource requested by the first object, and the first resource may be different types of business data, such as user data, device data, application data, etc. In addition, the first resource may be stored in the authentication component in the form of a library table.

[0052] Correspondingly, the first resource identifier may represent the first resource. For example, the first resource identifier may be a library table identifier.

[0053] In some embodiments, the number of the first resource identifier may be one, and the permission verification request may be used to verify the operation permission of the first object for the one resource.

[0054] In other embodiments, there may be multiple first resource identifiers, and the permission verification request may be used to verify the first object's respective operating permissions for the multiple resources.

[0055] The first permission identifier may represent the operation permission of the first object on the first resource. For example, the operation permission may include but is not limited to: access, read, write, and download.

[0056] Correspondingly, the first authority identifier may represent the operation authority, for example, the first authority identifier may be an operation authority code, etc. The operation authority code may be a digital code such as “0”, “1”, etc.

[0057] In some embodiments, the number of the first permission identifier may be one, and the permission verification request may be used to verify the one operation permission of the first object on the first resource.

[0058] In other embodiments, there may be multiple first permission identifiers, and the permission verification request may be used to verify the multiple operation permissions of the first object with respect to the first resource.

[0059] According to the introduction of the aforementioned application scenario, if the permission management method is applied to the client 101, then as an implementation mode, in step S21, the client 101 receives a permission verification request initiated by the first object.

[0060] If the permission management method is applied to the server 102 , then as an implementation mode, in step S21 , the server 102 receives the permission verification request sent by the client 101 .

[0061] Alternatively, in other application scenarios, other implementations may be adopted according to different execution entities or different hardware layouts, which are not limited here.

[0062] In some embodiments, the request involved may be a permission verification request or a permission update request. Therefore, a communication protocol agreement may be made in advance, for example, different requests may be agreed to use different communication messages. Alternatively, it may be agreed that a message field for characterizing the request type is added to the communication message. Thus, the type of permission management request may be identified according to the communication protocol agreement.

[0063] In some embodiments, the permission check request may be generated based on first object information, first resource information, and first permission information, wherein the first object information may include the name of the first object, the first resource information may include the name of the first resource, and the first permission information may include the name of the operation permission for the first resource.

[0064] For example, the first object identifier is first determined based on the first object information, the first resource identifier is determined based on the first resource information, and the first permission identifier is determined based on the first permission information. Then, a permission verification request is generated according to the first object identifier, the first resource identifier, and the first permission identifier.

[0065] Therefore, for objects such as users or applications, relevant information can be input, and based on the input relevant information, a corresponding permission verification request can be generated.

[0066] For example, the first resource identifier can be determined based on the first object information and a preset database, where the preset database includes multiple object information and object identifiers corresponding to the multiple object information. The first resource identifier can be determined based on the first resource information and a preset database, where the preset database also includes multiple resource information and resource identifiers corresponding to the multiple resource information. The first permission identifier can be determined based on the first permission information and a preset identifier correspondence relationship, where the preset identifier correspondence relationship is used to characterize the correspondence between the permission information and the permission identifier.

[0067] The preset database may be a database maintained by the server 102 or the client 101, wherein the plurality of object information is respectively unique object information, such as a unique user name. The plurality of resource information is respectively unique resource information, such as a unique resource name. Furthermore, the object information corresponds to an object identifier, and the resource information corresponds to an object identifier. By querying the preset database, the object identifier and the resource identifier can be determined.

[0068] The preset identification correspondence may also be an identification correspondence maintained by the server 102 or the client 101. The permission information may be the name of the operation permission, and the permission identification may represent the operation permission. For example, the permission identification of the access permission is 1, the permission identification of the read and write permission is 2, and the permission identification of the download permission is 3.

[0069] In other embodiments, an object identifier may be directly generated based on object information, a resource identifier may be generated based on resource information, and a permission identifier may be generated based on permission information. The identifier generation algorithm may be a hash algorithm or other string generation algorithm, which may make the generated object identifier, resource identifier, and permission identifier all distinguishable identifiers.

[0070] In some embodiments, if the corresponding object identifier cannot be found in a preset database based on the object information, or the corresponding resource identifier cannot be found in a preset database based on the resource information, information characterizing the information error can be generated and fed back to the initiator of the permission verification request so that the initiator of the permission verification request can verify whether there is any error in the information.

[0071] In addition, the above-mentioned implementation method of converting information into an identifier can be applied to the client 101 or the server 102 .

[0072] As an example, the client 101 sends a request carrying the first object information, the first resource information and the first permission information to the server 102, and the server 102 generates a permission verification request based on the request. As another example, the first object initiates a request carrying the first object information, the first resource information and the first permission information, and the client 101 or the server 102 generates a permission verification request based on the request.

[0073] It can be understood that here is an introduction to the content included in a permission verification request. In actual applications, if multiple permission verification requests are received, the multiple permission verification requests can correspond to corresponding information respectively, and the processing methods corresponding to these multiple permission verification requests are the same.

[0074] In step S22, a first permission verification identifier of the first object with respect to the first resource is determined according to the first object identifier and the first resource identifier.

[0075] The first permission verification mark is used to verify whether the first object has the operation permission for the first resource. The first permission verification mark can be generated in advance according to the operation permission of the first object for the first resource.

[0076] For example, assuming that the first object has two kinds of operation permissions for the first resource, the first permission verification identifier can be generated according to the two kinds of operation permissions. Furthermore, the first permission verification identifier can verify whether the first object has the relevant operation permissions for the first resource.

[0077] In some embodiments, step S22 may include: searching in a preset permission correspondence relationship according to the first object identifier and the first resource identifier to determine a first permission verification identifier of the first object with respect to the first resource.

[0078] The preset permission correspondence relationship is used to characterize the correspondence between the object identifier, the resource identifier and the permission verification identifier.

[0079] In some embodiments, one object identifier corresponds to at least one resource identifier, and one resource identifier corresponds to one permission verification identifier.

[0080] In some embodiments, the permission verification identifier is a permission verification identifier generated according to at least one permission identifier. Therefore, one permission verification identifier can be used to verify at least one permission identifier. Therefore, in the case where there are multiple operation permissions that need to be verified, the first permission verification identifier can be used to verify these multiple permissions that need to be verified.

[0081] For example, in Ranger, the resource identifier may be a library table identifier, and the library table identifier may be the same as the policy identifier. Therefore, in the embodiment of the present disclosure, the library table identifier may be understood as an instance of the resource identifier in Ranger.

[0082] In addition, when there are multiple first resource identifiers, the first permission verification identifier can be the first permission verification identifiers corresponding to the multiple first resource identifiers respectively, and the first permission verification identifier corresponding to each first resource identifier is used to verify the operation authority of the first object for the first resource.

[0083] As an optional implementation, the preset permission correspondence is a permission tree, which includes three layers of nodes, wherein the first layer of nodes in the permission tree are object identifiers, the second layer of nodes are resource identifiers, and the third layer of nodes are permission verification identifiers. Moreover, one object identifier corresponds to at least one resource identifier, and one resource identifier corresponds to one permission verification identifier.

[0084] Figure 3 FIG. 1 is a schematic diagram of a strategy tree structure according to an exemplary embodiment. The strategy tree structure is a structure adopted by a Ranger component in the related art. Figure 3 As shown, a Ranger policy corresponds to a library or a table (ie, a resource). Also, a resource corresponds to at least one user, and a user corresponds to a permission information, in which all permissions of the user are included, that is, at least one permission identifier.

[0085] It can be seen that if the Figure 3 The policy tree structure needs to configure all the user's permissions in the policy tree structure. Furthermore, since one user corresponds to all permission identifiers, when verifying permissions, it is necessary to query all the permissions of a user.

[0086] For example, assuming that the number of policies is n and the number of objects under each policy is m, to retrieve a user's permissions for a table, a large amount of network resources must be consumed to synchronize all permissions to client 101. In addition, the time complexity of authentication by client 101 is O(nm), resulting in low efficiency in permission management.

[0087] In addition, in related technologies, policies are directly stored in memory as objects. If there are 100,000 tables, each corresponding to different levels of permissions for 100 users, and a total of 10,000 users, and each user is evaluated based on the permissions of 50 tables, then all policies will take up about 300G in memory. That is, the policy tree method occupies a large amount of memory, causing great pressure on the permission management service.

[0088] Figure 4is a schematic diagram of a permission tree structure according to an exemplary embodiment. Figure 4 In the example, the object is the user and the resource is the library table of the authentication component's policy.

[0089] like Figure 4 As shown, the user identifier is used as the first-level node of the permission tree, the library table identifier is used as the second-level node of the permission tree, and the permission verification identifier is used as the third-level node. User A-library table a-permission verification identifier x1 represents the first corresponding relationship, user B-library table a-permission verification identifier x2 represents the second corresponding relationship, user C-library table b-permission verification identifier x3 represents the third corresponding relationship, and user C-library table c-permission verification identifier x4 represents the fourth corresponding relationship. Among them, the permission verification identifiers x1-x4 can be the same or different.

[0090] In some embodiments, the data type of each layer node in the permission tree is int (byte) type, rather than string type. For some combined permissions or single permissions, they are encoded into an int type permission verification identifier. Furthermore, using this permission tree structure, compared with the aforementioned policy tree structure, the same data, using the permission tree, only requires about 5G of memory.

[0091] Comparing the two storage structures, the policy tree structure needs to store the policy and library table as the first-level nodes, the user ID as the second-level node, and all the permission codes as the third-level nodes. The policy tree structure not only needs to store the permission information of all users for a policy or a library table, but also needs to store all the permission codes. The permission tree structure stores the user ID as the first-level node, the library table ID as the second-level node, and encodes at least one permission as a permission verification ID and stores it as a third-level node. The permission tree structure divides the permission information according to the user and library table, instead of storing all the permission information for one user. In addition, the permission information is encoded as a permission verification ID.

[0092] Therefore, through this implementation, the memory occupied by the preset permission correspondence can be significantly reduced; and when verifying permissions, there is no need to obtain all the user's permissions, only the user's permission information for specific resources needs to be obtained, which significantly improves the efficiency of permission verification.

[0093] In some embodiments, the permission tree structure may adopt a hash storage structure. The hash storage structure can map keywords to a continuous and limited address space through a hash function. That is, the node data of the permission data structure can be mapped to a continuous and limited address space. When traversing the permission tree, based on the characteristics of the hash storage structure, the storage address of the data to be searched can be calculated through the hash function, and the data to be searched can be quickly located without a complex traversal search algorithm.

[0094] In the embodiments of the present disclosure, a hash storage structure may be used for user identifiers and resource identifiers; whereas a hash storage structure may not be used for permission verification identifiers.

[0095] Further, based on the introduction of the preset permission correspondence relationship, as an optional implementation method, step S22 includes: determining the object identifier that matches the first object identifier in the preset permission correspondence relationship; determining the resource identifier that matches the first resource identifier in the resource identifier corresponding to the object identifier that matches the first object identifier; and determining the permission verification identifier corresponding to the resource identifier that matches the first resource identifier as the first permission verification identifier.

[0096] The object identifiers match, which may be the same as the object identifiers; and the resource identifiers match, which may be the same as the resource identifiers.

[0097] Taking the permission tree as an example, traverse the permission tree according to the first user identifier. If a user identifier matching the first user identifier is found, continue to traverse the resource identifier under the user identifier matching the first user identifier. If a resource identifier matching the first resource identifier is found, the permission verification identifier under the resource identifier matching the first resource identifier is determined as the first permission verification identifier.

[0098] In some embodiments, if the preset permission correspondence does not include an object identifier that matches the first object identifier, or the preset permission correspondence does not include a resource identifier that matches the first resource identifier, a prompt message indicating that the permission check failed is fed back. The prompt message may be, for example, "verification denied", "verification failed", "error identifier" or the like.

[0099] Continuing with the permission tree as an example, if the traversal is performed based on the first user identifier and a matching user identifier cannot be found, it can be directly determined that the permission verification has failed. If the traversal is performed based on the first user identifier and a matching user identifier is found, but the traversal is performed based on the first resource identifier and a matching resource identifier cannot be found, it can also be determined that the permission verification has failed. Therefore, in the case where a matching user identifier cannot be found or a matching resource identifier cannot be found, a prompt message indicating that the permission verification has failed can be fed back.

[0100] Figure 5 is a schematic diagram of a traversal process based on a permission tree according to an exemplary embodiment. Figure 5 In the example, the object is the user and the resource is the library table of the authentication component's policy.

[0101] like Figure 5As shown, first obtain the user ID and the library table ID; then, first find out whether the user ID is in the permission tree. If the user ID is in the permission tree, continue to traverse the library table ID of the permission tree; if the user ID is not in the permission tree, directly return the corresponding prompt information. Further, find out whether the library table ID is in the permission tree. If the library table ID is in the permission tree, verify it according to the corresponding permission verification ID; if the library table ID is not in the permission tree, return the corresponding prompt information. In addition, during the entire traversal process, it is also possible to determine whether the traversal is complete, and return information based on the judgment result; or continue traversing.

[0102] It can be seen that in the embodiment of the present disclosure, compared with the related art, the permissions to be verified are not distributed in all policies (library tables), and there is no need to scan the entire table. Therefore, the number of policies to be scanned can be greatly reduced, and by traversing the two-layer nodes of the permission tree, the permission verification identifier can be located based on the traversal results, and then verification can be started, thereby improving verification efficiency.

[0103] Further, in step S23, verification is performed according to the first authority verification identifier and the first authority identifier to obtain a verification result for the authority verification request.

[0104] As an optional implementation, the first permission verification identifier is represented by a first code. The first code may be obtained by encoding the permission identifier corresponding to the operation permission of the first object on the first resource in a corresponding encoding manner.

[0105] It can be understood that the operation permission of the first object on the first resource is a permission that can be verified. Therefore, if the operation permission represented by the first permission identifier belongs to the operation permission of the first object on the first resource, the verification can pass; otherwise, the verification fails.

[0106] It can be understood that each permission verification identifier in the preset permission correspondence relationship may be a code determined according to the permission identifier corresponding to the operation permission that the object has for the resource.

[0107] Therefore, step S23 may include: encoding the first authority identifier to obtain a second code, the encoding method corresponding to the first code and the encoding method corresponding to the second code being the same; and verifying according to the first code and the second code to obtain a verification result.

[0108] In this implementation, since the second code is determined by coding based on the first authority identifier, and the coding method is the same as the coding method of the first code, the authority verification result can be determined by the first code and the second code.

[0109] By adopting this implementation, on the one hand, the permission verification identifier is represented by the permission code, and in the scenario involving a large number of permission verification identifiers, the memory size occupied by the permission verification identifier can be significantly reduced. On the other hand, during verification, the permissions to be verified can also be encoded in the same encoding method, and then the verification result can be quickly determined by comparing the encoding result with the permission verification identifier.

[0110] Therefore, the encoding method may be an encoding method capable of encoding at least one permission identifier.

[0111] In some embodiments, the number of operation permissions that an object has for a resource may be greater than 0 and less than 10.

[0112] In some embodiments, if the number of operation permissions that the object requests to verify for a resource is equal to the number of operation permissions that the object has for the resource, the encoding method may be a relatively simple mathematical encoding method, such as power encoding, summation encoding, multiplication encoding, etc. Correspondingly, when determining the verification result, if the first encoding and the second encoding are equal, it means that the verification is passed.

[0113] This implementation is suitable for scenarios where the number of operation permissions that need to be verified is relatively stable, for example, each time the operation permissions requested for verification are two operation permissions.

[0114] In other embodiments, if the number of operation permissions that the object requests to verify for resources is not necessarily equal to the number of operation permissions that the object has for resources, the encoding method can be a specific mathematical encoding method. With this implementation, during verification, only one of the multiple operation permissions can be verified, or any number of the multiple operation permissions can be verified. Thus, with this implementation, the flexibility of permission verification can be improved.

[0115] Therefore, as an optional implementation, verification is performed according to the first code and the second code to obtain a verification result, including: performing a logical AND operation on the first code and the second code to obtain a first result, and determining the verification result according to the first result and the second code.

[0116] Determining the verification result based on the first result and the first code may include: if the first result and the second code match, determining the verification result is that the first object has the operation permission for the first resource; if the first result and the second code do not match, determining the verification result is that the first object does not have the operation permission for the first resource.

[0117] Regarding the matching of the first result and the second encoding, it may be that the first result and the second encoding are consistent; regarding the mismatching of the first result and the second encoding, it may be that the first result and the second encoding are inconsistent.

[0118] As an optional implementation, the encoding method is a bit operation encoding method based on power operation; this encoding method can realize the verification of any number of operation permissions.

[0119] Therefore, determining the first code may include: performing a power operation on the preset authority identifier to obtain a power result corresponding to the preset authority identifier; and performing a sum operation on the power results corresponding to the preset authority identifier to obtain the first code.

[0120] The preset permission identifier may be a permission identifier corresponding to the operation permission that the first object has for the first resource, and the number of the preset permission identifier may be one or more.

[0121] And, encoding the first authority identifier to obtain the second code may include: performing a power operation on the first authority identifier to obtain a power result corresponding to the first authority identifier; and summing the power results corresponding to the first authority identifier to obtain the second code.

[0122] The number of the first authority identifiers may be one or more.

[0123] For example, the encoding method can be expressed as: 编码 =K n1 +K n2 +K n3 +...+K nx Among them, n 编码 represents the code, n1~nx represent different permission identifiers respectively, K is a preset parameter, that is, the parameter that needs to be exponentially calculated with the permission identifier, and the value of the preset parameter can be 2.

[0124] Taking the first code as an example, the first code can be expressed as: n 第一编码 =2 n1 +2 n2 +2 n3 +...+2 nx Among them, n 第一编码 represents a first code, and n1-nx represent permission identifiers corresponding to the operation permissions that the first object has on the first resource.

[0125] Taking the second encoding as an example, the second encoding can be expressed as: n 第二编码 =2 m1 +2 m2 +2 m3 +...+2 mx Among them, n 第二编码 represents the second code, and m1~mx represent the first authority identifier.

[0126] For example, the encoding method can also be expressed as:编码 =K n1-1 +K n2-1 +K n3-1 +...+K nx-1 Among them, n 编码 represents the code, n1~nx represent different permission identifiers respectively, K is a preset parameter, that is, the parameter that needs to be exponentially calculated with the permission identifier, and the value of the preset parameter can be 4.

[0127] As a further example, if n 第一编码 &n 第二编码 =n 第二编码 , it means the verification is passed; if n 第一编码 &n 第二编码 ! =n 第二编码 , it means the verification failed. Among them, n 第一编码 Represents the first code, n 第二编码 Represents the second encoding, “&” represents the logical AND operation, and “!=” represents not equal to.

[0128] It can be understood that, using the encoding method of the embodiment of the present disclosure, the permission verification identifier encoded can be regarded as a permission verification code.

[0129] For example, in Ranger, the relevant operation permissions for data tables (library tables) include create, select, insert, and delete. The relevant operation permissions for file systems include read and write. These permissions are usually not too many, and for a group of users and resources, there are usually less than 10 permissions.

[0130] Furthermore, the permission check code can be obtained by encoding using the properties of bit operations, so that the sum of multiple positive integer powers of 2 and any original positive integer power of 2 undergo a logical AND operation, and the result obtained is equal to the positive integer power of 2.

[0131] Therefore, suppose there are four types of operation permissions for the library table, namely: select, create, insert, and delete. The permission identifiers (which can be called permission codes) corresponding to these four operation permissions are: 1, 2, 3, and 4.

[0132] Assuming that the user has the following three operation permissions for the database table: select, create, and delete, the corresponding permission codes are determined as 1, 2, and 4 respectively according to these three permissions. By encoding these three permission codes according to the encoding method, the permission verification code (i.e., the first permission verification identifier) ​​can be obtained as: 2 1 +2 2 +24 =22.

[0133] Further, according to the permission verification code, the following example of a single operation permission verification passing is shown: 22&2 1 =2 1 , select permission verification passed; 22&2 2 =2 2 , create permission verification passed; 22&2 4 =2 4 , the delete permission check passed. Among them, 2 1 Indicates the code corresponding to the select permission, 2 2 Indicates the code for create permission, 2 4 Indicates the code corresponding to the delete permission.

[0134] It can be understood that passing the operation permission check means determining that the check result is that the first object has the operation permission for the first resource.

[0135] And, the following example of combined permissions (i.e., multiple permissions) passing the verification is shown: 22&(2 1 +2 2 )=(2 1 +2 2 ), select and create permissions are verified; 2&(2 2 +2 4) =(2 2 +2 4) , create and delete permissions have been verified. Among them, (2 1 +2 2 ) represents the codes corresponding to the select permission and create permission. (2 2 +2 4) Represents the codes corresponding to create and delete permissions.

[0136] And, an example of a permission check failing is shown: 22&2 3 ! =2 3 , the insert permission check fails. Among them, 2 3 Indicates the code corresponding to the insert permission.

[0137] The code corresponding to the above authority can be understood as the authority identifier corresponding to the authority, that is, the first authority identifier, which is encoded in the same encoding method as the authority verification code.

[0138] From the above examples, it can be seen that the above encoding method can realize the verification of any number of operation permissions. Moreover, without a complicated verification process, the consistency between the requested operation permissions and the actual operation permissions can be verified, which can improve the accuracy and efficiency of permission verification.

[0139] Furthermore, based on the combination of the above encoding method and the permission tree, this verification method can be applied to scenarios with a large number of users and a large number of permissions, greatly saving memory pressure. In addition, based on the above encoding method, complex encoding or verification methods such as deserialization of permission-related information and string comparison can be avoided, and the authentication speed is also significantly improved.

[0140] Figure 6 is a flow chart of another permission management method according to an exemplary embodiment, the permission management method comprising:

[0141] Step S61, obtain a permission update request, the permission update request is used to request to update the permission verification identifier of the second object for the second resource, the permission update request includes the second object identifier of the second object, the second resource identifier of the second resource, and the second permission identifier used to represent the operation authority updated for the second resource.

[0142] Step S62: Determine, according to the second object identifier and the second resource identifier, a second permission verification identifier for the second object to request update of the second resource.

[0143] Step S63: Update the second authority verification identifier according to the second authority identifier.

[0144] It can be understood that steps S61 to S63 are the permission update process. The update process here can be the process of configuring permissions for the first time, or it can be the permission update process after the first permission configuration. That is, the first configuration of the permission correspondence relationship can also be called an update, representing an update from scratch.

[0145] In some application scenarios, the permission management method is applied to the server 102. In step S61, the server 102 receives the permission update request sent by the client 101. In step S62, the server 102 determines the second permission verification identifier of the second object for the second resource request update based on the second object identifier and the second resource identifier. In step S63, the server 102 updates the second permission verification identifier based on the second permission identifier. Finally, the server 102 can also feedback the update result to the client 101.

[0146] In these application scenarios, the client 101 initiates a permission update request, and the server 102 performs the permission update, which is equivalent to the server 102 maintaining the permission verification identifier, which can reduce the pressure on the client 101.

[0147] In other application scenarios, the permission management method is applied to the client 101. In step S61, the client 101 receives a permission update request initiated by the second object. In step S62, the client 101 determines the second permission verification identifier that the second object requests to update for the second resource based on the second object identifier and the second resource identifier. In step S63, the client 101 updates the second permission verification identifier based on the second permission identifier.

[0148] In these application scenarios, the second object initiates a permission update request, and the client 101 performs permission update according to the permission update request without the help of the server 102, thereby reducing hardware costs.

[0149] Permission update requests can come from external objects or from local upstream applications or upstream tasks.

[0150] The second object may be a user or an application, etc. Accordingly, the second object identifier may represent a user or an application, etc. For example, the second object identifier may be a user identity identifier, an application name identifier, etc.

[0151] The second resource may be a resource for which the second object requests to update the permission verification identifier, and the second resource may be different types of business data, such as user data, device data, application data, etc. In addition, the second resource may be stored in the form of a library table in the authentication component.

[0152] Correspondingly, the second resource identifier may represent the second resource. For example, the second resource identifier may be a library table identifier.

[0153] In some embodiments, the number of the second resource identifiers may be one, and the permission update request may be used to update the permission verification identifier of the first object for the one resource.

[0154] In other embodiments, the number of second resource identifiers may be multiple, and the permission update request may be used to update the permission verification identifiers of the first object for the multiple resources respectively.

[0155] The second permission identifier may represent the operation permission of the first object to update the first resource. For example, the updated operation permission may include but is not limited to: access, read, write, and download.

[0156] Correspondingly, the second authority identifier may represent the operation authority requested to be updated, for example, the second authority identifier may be an operation authority code, etc. The operation authority code may be a digital code such as “0”, “1”, etc.

[0157] In some embodiments, the number of the second permission identifier may be one, and the permission verification identifier of the second object for the second resource is updated by the one permission identifier.

[0158] In some other embodiments, the number of the second permission identifiers may be multiple, and the permission verification identifier of the second object for the second resource is updated using the multiple permission identifiers.

[0159] According to the introduction of the aforementioned application scenario, if the permission management method is applied to the client 101, then as an implementation mode, in step S61, the client 101 receives a permission update request initiated by the second object.

[0160] If the permission management method is applied to the server 102 , then as an implementation mode, in step S61 , the server 102 receives the permission update request sent by the client 101 .

[0161] Alternatively, in other application scenarios, other implementations may be adopted according to different execution entities or different hardware layouts, which are not limited here.

[0162] The second object identifier may be the same as or different from the first object identifier, the second resource identifier may be the same as or different from the first resource identifier, and the second permission identifier may be the same as or different from the first permission identifier. The distinction between the first and second methods here only reflects the corresponding information applied to different permission management processes.

[0163] Regarding the permission update request, it can be generated based on the second object information, the second resource information and the second permission information. The generation method of the permission update request can refer to the generation method of the aforementioned permission verification request, which will not be repeated here.

[0164] In the disclosed embodiment, the permission update request is used to update the permission verification identifier of the second object for the second resource. Since the permission verification identifier is obtained according to the corresponding permission identifier encoding, when updating the permission verification identifier, only the permission identifier needs to be carried in the permission update request without carrying the specific permission verification identifier, and the permission verification identifier can be updated based on the permission identifier.

[0165] In addition, the updated permission verification mark can also be used to verify the operation permission corresponding to the second permission mark. Therefore, the update of the permission verification mark can be understood as the update of the operation permission from the perspective of the object; from the perspective of permission maintenance, it is the update of the permission verification mark.

[0166] The permission update request may also include information for characterizing the permission update type, and the information for characterizing the permission update type may be used to select a subsequent method for updating the second permission verification identifier. In addition, if the updated permission verification identifier is not an existing permission verification identifier, the information for characterizing the permission update type may not be included in the permission update request.

[0167] In step S62, a second permission verification identifier requested to be updated by the second object with respect to the second resource is determined according to the second object identifier and the second resource identifier.

[0168] As an optional implementation, step S62 includes: searching, in a preset permission correspondence relationship, for a second permission verification identifier that the second object requests to update with respect to the second resource, according to the second object identifier and the second resource identifier.

[0169] It can be understood that the implementation of the preset permission correspondence relationship here can refer to the aforementioned embodiment, and will not be repeated here.

[0170] In some embodiments, an object identifier that matches the second object identifier can be first searched for in a preset permission correspondence relationship, and then a resource identifier that matches the second resource identifier can be searched for in the resource identifier corresponding to the object identifier that matches the second object identifier, and then the permission verification identifier corresponding to the resource identifier that matches the second resource identifier can be determined as the second permission verification identifier.

[0171] In this implementation, if an object identifier that matches the second object identifier is not found, the second permission identifier can be used to encode a second permission verification identifier, and then the second object identifier, second resource identifier and second permission verification identifier are added to the preset permission correspondence relationship, and the correspondence between the three is stored.

[0172] Alternatively, if an object identifier matching the second object identifier is found, but a resource identifier matching the second resource identifier is not found, the second permission identifier can also be used to encode the second permission verification identifier. Then, the second resource identifier and the second permission verification identifier are added to the preset permission correspondence relationship, and the correspondence between the three is stored.

[0173] It can be understood that if it is necessary to use the second authority identifier to encode the second authority verification identifier, the encoding can be performed according to the encoding method introduced in the above embodiment.

[0174] It can be understood that when the second authority verification identifier is found, step S63 is executed.

[0175] The above-mentioned search implementation method can refer to the search method based on the permission tree in the previous embodiment, which will not be repeated here.

[0176] In combination with the encoding method of the aforementioned permission verification identifier, the second permission verification identifier can be represented by a third encoding.

[0177] Therefore, step S63 may include: encoding the second authority identifier to obtain a fourth code, the encoding method corresponding to the third code is the same as the encoding method corresponding to the fourth code; determining the fifth code based on the third code and the fourth code; and updating the second authority verification identifier based on the fifth code.

[0178] In this implementation, the second authority identifier is first encoded according to the second authority identifier and the same encoding method as the third encoding to obtain a fourth code, and then the fifth code is determined according to the third code and the fourth code, and then the second authority verification identifier is updated according to the fifth code.

[0179] For example, updating the second permission verification identifier according to the fifth code may include: updating the second permission verification identifier from being represented by the third code to being represented by the fifth code.

[0180] In addition, the implementation method of encoding the second authority identifier to obtain the fourth code can refer to the implementation method of encoding the first authority identifier to obtain the second code in the aforementioned embodiment, which will not be repeated here.

[0181] As a first optional implementation, determining the fifth code according to the third code and the fourth code includes: performing a logical OR operation on the third code and the fourth code to obtain a second result; and determining the fifth code according to the second result and the fourth code.

[0182] This implementation is applicable to the application scenario of deleting the operation permission based on the second permission verification identifier. For example, before the second permission verification identifier is updated, the second permission verification identifier can be used to verify three operation permissions; after the second permission verification identifier is updated, the updated second permission verification identifier can be used to verify two operation permissions. Therefore, for the second object, its operation permission for the second resource is also reduced accordingly.

[0183] Determining the fifth code according to the second result and the fourth code may include: subtracting the second result from the fourth code to obtain the fifth code, that is, the fifth code is the difference between the second result and the fourth code.

[0184] In this implementation, through the logic OR operation, it is not limited to whether the third code uses the code corresponding to the second authority verification identifier during encoding.

[0185] For example, the fifth encoding can be expressed as: N5 = (N3|N4) - N4; wherein N5 represents the fifth encoding, "|" represents a logical OR operation, N4 represents the fourth encoding, N3 represents the third encoding, and N3|N4 represents the second result.

[0186] As a second optional implementation, determining the fifth code according to the third code and the fourth code includes: performing a logical AND operation on the third code and the fourth code to obtain a third result; performing a logical AND operation on the third result and the fourth code to obtain a fourth result; and determining the fifth code according to the fourth result and the third code.

[0187] This implementation is suitable for application scenarios where operating permissions are increased based on the second permission verification identifier. For example, before the second permission verification identifier is updated, the second permission verification identifier can be used to verify one operating permission; after the second permission verification identifier is updated, the updated second permission verification identifier can be used to verify two operating permissions. Therefore, for the second object, its operating permissions for the second resource are also increased accordingly.

[0188] Determining the fifth code according to the fourth result and the third code may include: summing the fourth result and the third code to obtain the fifth code, that is, the fifth code is the sum of the second result and the fourth code.

[0189] In this implementation, through the logical OR operation and the logical AND operation, it is not limited to whether the third code uses the code corresponding to the second authority verification identifier during encoding.

[0190] For example, the fifth encoding can also be expressed as: N5=N3+(N3^N4)&N4; wherein N5 represents the fifth encoding, N3 represents the third encoding, N4 represents the fourth encoding, "^" represents the logical AND operation, N3^N4 represents the third result, and "&" represents the logical AND operation, (N3^N4)&N4 represents the fourth result.

[0191] In the above two implementations, the fifth code can be obtained by adding or deleting the code corresponding to the second permission identifier on the basis of the third code. It can be understood that the aforementioned information used to characterize the permission update type can be used in this process. For example, if the permission update type is increase, the above second implementation is adopted.

[0192] In other embodiments, if the third code does not utilize the code corresponding to the second authority verification identifier when encoding, determining the fifth code according to the third code and the fourth code may include: summing the third code and the fourth code to obtain the fifth code. Alternatively, subtracting the third code from the fourth code to obtain the fifth code.

[0193] In some embodiments, corresponding approval may also be performed for permission update requests. For example, if the second object identifier is an object identifier in a preset blacklist, it is determined that the permission update request is not approved, and relevant prompt information that the update is not allowed is returned. For another example, if the second resource identifier is a resource identifier in a preset list of resource identifiers that need to be kept confidential, it is determined that the permission update request is not approved, and relevant prompt information that the update is not allowed is returned.

[0194] In some embodiments, after step S63, information characterizing the update status may also be fed back to enable the second object to understand the permission update status. For example, if the update is successful, feedback information indicating the success of the update is returned. If the update fails, feedback information indicating the update failure and / or the reason for the update failure is returned.

[0195] Figure 7 is a schematic diagram of a permission update process based on a permission tree according to an exemplary embodiment. Figure 7 In the example, the object is the user and the resource is the library table.

[0196] like Figure 7 As shown, after receiving the permission update request, first obtain the user ID and library table ID according to the permission update request. Then, first traverse whether the user ID exists in the permission tree. If the user ID exists in the permission tree, continue to traverse whether the corresponding library table ID exists in the corresponding subtree; if the user ID does not exist in the permission tree, a new user ID node can be created. If the corresponding library table ID does not exist in the corresponding subtree, create a corresponding library table ID node. Further, if the corresponding library table ID exists in the corresponding subtree, update the permission verification ID node by deleting or adding new permissions. Finally, for the case of newly creating a user ID node and a library table ID node, a new permission verification ID node is created accordingly.

[0197] It is understandable that in the permission update process, if some situations that do not conform to the update logic occur, a prompt message indicating that the update failed may be returned. Situations that do not conform to the update logic include: the user ID has not passed the approval, the resource ID is a resource ID that needs to be kept confidential, etc.

[0198] Figure 8 is an authentication flow chart of a Ranger component according to an exemplary embodiment. Figure 8 As shown, the Ranger component configures a policy update monitoring module, which can monitor policy updates. For example, when a policy (authority) update request is monitored, it is determined that the permission tree needs to be updated. Figure 8 In the example, the object is the user and the resource is the library table.

[0199] For users, there are two processes involved. The first process is the permission update process. In the permission update process, users can apply for permissions (i.e., initiate permission update requests) through the permission system. The permission system can include a client 101 and a server 102. Users can apply for permissions on the client 101. Then, the permission system generates a permission update request, and the server 102 processes the permission update request. Among them, the server 102 can obtain the permission update request through the request monitoring of the Ranger component.

[0200] In addition, in the first part of the process, after updating the permission tree, the Ranger component of the server 102 will also feedback to the user information indicating that the permission application has been approved, so that the user knows that the permission application has been approved. Figure 8 Not shown in FIG.

[0201] It is understandable that the result of the permission application is: updating the corresponding permission verification mark, but for the user, it can be regarded as a successful application for the corresponding operation permission. Therefore, when the user's operation permission is verified using the updated permission verification mark, the corresponding verification result is that the user has the corresponding operation permission.

[0202] The second part of the process is the permission verification process. In the permission verification process, the client 101 where the user is located can generate an authentication request (i.e., a permission verification request) corresponding to the task type that requires authentication by executing a computing task, which carries the user name, library table name, and permission code, etc. Then, the Ranger component of the server 102 receives the authentication request and processes it based on the permission tree. The final processing result can be a direct authentication result or feedback permission information (such as a permission verification code), so that the client 101 can authenticate based on the permission information. Therefore, in Figure 8 The flow and specific content of the processing results are not shown.

[0203] It can be seen that the technical solution of the embodiment of the present disclosure can significantly improve the authentication efficiency, and therefore can be applied to scenarios that require a large number of task authentications, such as: financial big data batch task authentication scenarios.

[0204] Through the introduction of the embodiments of the present disclosure, the permission verification identifier of the object for the resource is determined through the object identifier and the resource identifier, and then the permission verification identifier is used to implement the object's operation permission verification on the resource, without considering other excessive information of the object, thereby improving the efficiency of permission verification. In addition, since there is no need to consider other excessive information of the object, on the basis of considering less information, the configuration of the object information, or the configuration of the permission identifier and the permission verification identifier are relatively simple, and the configuration method can also be flexibly selected, which can reduce the difficulty of permission verification and improve the flexibility of permission verification.

[0205] In addition, although there is no need to consider too much other information about the object, the information associated with the permission verification identifier is the object identifier and resource identifier. The object identifier and resource identifier can realize the division of operation permissions according to objects and resources, making the verification granularity of operation permissions finer, which will not affect the accuracy of permission verification and can ensure the security of resources. Therefore, this technical solution can improve the efficiency and flexibility of permission verification and reduce the difficulty of permission verification without affecting the accuracy of permission verification.

[0206] Furthermore, a preset permission correspondence is configured in the form of a permission tree to determine the permission verification identifier of an object for a resource through an object identifier and a resource identifier. When performing permission verification, only two layers of nodes of the permission tree need to be traversed to locate the corresponding permission verification identifier, and then verification is performed according to the permission verification identifier. Also, when updating permissions, the permission verification identifier that needs to be updated can be located by traversing the permission tree, and then updated according to the permission verification identifier. It can be seen that based on the permission tree, both permission update and permission verification can significantly improve efficiency.

[0207] In addition, by encoding the permission identifier into a permission verification identifier according to the corresponding encoding method, the storage space (memory) occupied by the preset permission correspondence relationship can be saved. In addition, more flexible permission verification and update can be achieved. Moreover, through the corresponding encoding method, combined with the corresponding operations between the encodings, permission verification and update can be achieved, reducing the difficulty of permission management and improving the efficiency of permission management.

[0208] Therefore, the technical solution of the embodiment of the present disclosure can improve the efficiency and flexibility of permission verification and reduce the difficulty of permission verification without affecting the accuracy of permission verification, thereby reducing the pressure on permission management services, improving the stability of permission management services, and ensuring the security of resource access.

[0209] Fig. 9 : is a structural block diagram of a rights management device according to an exemplary embodiment, the rights management device comprising:

[0210] The acquisition unit 901 is used to obtain a permission verification request, wherein the permission verification request is used to request verification of whether the first object has the operation permission for the first resource, and the permission verification request includes a first object identifier of the first object, a first resource identifier of the first resource, and a first permission identifier used to represent the operation permission for the first resource.

[0211] The determining unit 902 is configured to determine a first permission verification identifier of the first object with respect to the first resource according to the first object identifier and the first resource identifier.

[0212] The verification unit 903 is used to perform verification according to the first permission verification identifier and the first permission identifier to obtain a verification result for the permission verification request.

[0213] Optionally, the first authority verification identifier is represented by a first code; the verification unit 903 is also used to: encode the first authority identifier to obtain a second code, the encoding method corresponding to the first code is the same as the encoding method corresponding to the second code; verify according to the first code and the second code to obtain the verification result.

[0214] Optionally, the verification unit 903 is also used to: perform a logical AND operation on the first code and the second code to obtain a first result; if the first result and the second code match, determine that the verification result is that the first object has the operation permission for the first resource; if the first result and the second code do not match, determine that the verification result is that the first object does not have the operation permission for the first resource.

[0215] Optionally, the device also includes an update unit, and the acquisition unit 901 is also used to: obtain a permission update request, the permission update request is used to request an update of a permission verification identifier of the second object for a second resource, the permission update request includes a second object identifier of the second object, a second resource identifier of the second resource, and a second permission identifier used to characterize the operation authority updated for the second resource; the determination unit 902 is also used to: determine the second permission verification identifier requested to be updated by the second object for the second resource based on the second object identifier and the second resource identifier; the update unit is used to: update the second permission verification identifier based on the second permission identifier.

[0216] Optionally, the updating unit is also used to: represent the second authority verification identifier through a third code, encode the second authority identifier to obtain a fourth code, the encoding method corresponding to the third code is the same as the encoding method corresponding to the fourth code; determine a fifth code according to the third code and the fourth code; and update the second authority verification identifier according to the fifth code.

[0217] Optionally, the updating unit is further used to: perform a logical OR operation on the third code and the fourth code to obtain a second result; and determine the fifth code according to the second result and the fourth code.

[0218] Optionally, the update unit is also used to: perform a logical AND operation on the third code and the fourth code to obtain a third result; perform a logical AND operation on the third result and the fourth code to obtain a fourth result; and determine the fifth code based on the fourth result and the third code.

[0219] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0220] Fig.10 FIG. 1 is a block diagram of an electronic device 1000 according to an exemplary embodiment. Fig.10 As shown, the electronic device 1000 may include: a processor 1001 and a memory 1002. The electronic device 1000 may also include one or more of a multimedia component 1003, an input / output (I / O) interface 1004, and a communication component 1005.

[0221] The processor 1001 is used to control the overall operation of the electronic device 1000 to complete all or part of the steps in the above-mentioned permission management method. The memory 1002 is used to store various types of data to support the operation of the electronic device 1000, and these data may include, for example, instructions for any application or method used to operate on the electronic device 1000, and application-related data, such as contact data, sent and received messages, pictures, audio, video, etc. The memory 1002 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (Static Random Access Memory, referred to as SRAM), electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, referred to as EEPROM), erasable programmable read-only memory (Erasable Programmable Read-Only Memory, referred to as EPROM), programmable read-only memory (Programmable Read-Only Memory, referred to as PROM), read-only memory (Read-Only Memory, referred to as ROM), magnetic memory, flash memory, disk or optical disk. The multimedia component 1003 may include a screen and an audio component. The screen may be, for example, a touch screen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone, which is used to receive external audio signals. The received audio signal may be further stored in the memory 1002 or sent through the communication component 1005. The audio component also includes at least one speaker for outputting audio signals. The I / O interface 1004 provides an interface between the processor 1001 and other interface modules, and the above-mentioned other interface modules may be keyboards, mice, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 1005 is used for wired or wireless communication between the electronic device 1000 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IOT, eMTC, or other 5G, etc., or a combination of one or more of them, is not limited here. Therefore, the corresponding communication component 1005 may include: Wi-Fi module, Bluetooth module, NFC module, etc.

[0222] In an exemplary embodiment, the electronic device 1000 can be implemented by one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), controllers, microcontrollers, microprocessors or other electronic components to execute the above-mentioned permission management method.

[0223] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, and when the program instructions are executed by a processor, the steps of the above-mentioned rights management method are implemented. For example, the computer-readable storage medium can be the above-mentioned memory 1002 including program instructions, and the above-mentioned program instructions can be executed by the processor 1001 of the electronic device 1000 to complete the above-mentioned rights management method.

[0224] In another exemplary embodiment, a computer program product is further provided. The computer program product includes a computer program that can be executed by a programmable device. The computer program has a code portion for executing the above-mentioned rights management method when executed by the programmable device.

[0225] The preferred embodiments of the present disclosure are described in detail above in conjunction with the accompanying drawings; however, the present disclosure is not limited to the specific details in the above embodiments. Within the technical concept of the present disclosure, a variety of simple modifications can be made to the technical solution of the present disclosure, and these simple modifications all fall within the protection scope of the present disclosure.

[0226] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, the present disclosure will not further describe various possible combinations.

[0227] In addition, various embodiments of the present disclosure may be arbitrarily combined, and as long as they do not violate the concept of the present disclosure, they should also be regarded as the contents disclosed by the present disclosure.

Claims

1. A rights management method, characterized in that: include: Obtain a permission verification request, where the permission verification request is used to request verification of whether the first object has operation permission for the first resource, and the permission verification request includes a first object identifier of the first object, a first resource identifier of the first resource, and a first permission identifier used to represent the operation permission for the first resource; Determine, according to the first object identifier and the first resource identifier, a first permission verification identifier of the first object with respect to the first resource; A verification is performed according to the first authority verification identifier and the first authority identifier to obtain a verification result for the authority verification request.

2. The method according to claim 1, characterized in that The first permission verification identifier is represented by a first code; and the verifying the first permission identifier according to the first permission verification identifier to obtain a verification result for the permission verification request includes: Encode the first authority identifier to obtain a second code, wherein the encoding method corresponding to the first code is the same as the encoding method corresponding to the second code; A verification is performed according to the first code and the second code to obtain the verification result.

3. The rights management method according to claim 2, characterized in that: The verifying according to the first code and the second code to obtain the verification result includes: Performing a logical AND operation on the first code and the second code to obtain a first result; If the first result and the second code match, determining that the verification result is that the first object has the operation permission for the first resource; If the first result and the second code do not match, it is determined that the verification result is that the first object does not have the operation permission for the first resource.

4. The rights management method according to claim 1, characterized in that: The rights management method further includes: Obtain a permission update request, where the permission update request is used to request to update a permission verification identifier of a second object for a second resource, and the permission update request includes a second object identifier of the second object, a second resource identifier of the second resource, and a second permission identifier used to represent the operation authority updated for the second resource; Determine, according to the second object identifier and the second resource identifier, a second permission verification identifier requested by the second object to update the second resource; The second authority verification identifier is updated according to the second authority identifier.

5. The rights management method according to claim 4, characterized in that: The second permission verification identifier is represented by a third code, and the updating of the second permission verification identifier according to the second permission identifier includes: Encode the second authority identifier to obtain a fourth code, wherein the encoding method corresponding to the third code is the same as the encoding method corresponding to the fourth code; Determine a fifth code according to the third code and the fourth code; The second authority verification identifier is updated according to the fifth code.

6. The rights management method according to claim 5, characterized in that: The determining the fifth code according to the third code and the fourth code comprises: Performing a logical OR operation on the third code and the fourth code to obtain a second result; The fifth code is determined according to the second result and the fourth code.

7. The rights management method according to claim 5, characterized in that: The determining the fifth code according to the third code and the fourth code comprises: Performing a logical AND operation on the third code and the fourth code to obtain a third result; Performing a logical AND operation on the third result and the fourth code to obtain a fourth result; The fifth code is determined according to the fourth result and the third code.

8. A rights management device, characterized in that: include: an acquisition unit, configured to acquire a permission verification request, wherein the permission verification request is used to request verification of whether the first object has the operation permission for the first resource, and the permission verification request includes a first object identifier of the first object, a first resource identifier of the first resource, and a first permission identifier used to represent the operation permission for the first resource; a determining unit, configured to determine a first permission verification identifier of the first object with respect to the first resource according to the first object identifier and the first resource identifier; A verification unit is used to perform verification according to the first authority verification identifier and the first authority identifier to obtain a verification result for the authority verification request.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the permission management method described in any one of claims 1 to 7 is implemented.

10. An electronic device, characterized in that: include: a memory having a computer program stored thereon; A processor, configured to execute the computer program in the memory to implement the rights management method according to any one of claims 1 to 7.

Images