Horizontal permission verification method and device and electronic equipment

Abstract

The embodiment of the invention discloses a horizontal permission checking method and device and electronic equipment, which are used for realizing horizontal permission checking in a simple and efficient manner on the premise of not invading services. The method comprises the following steps: encrypting a user identifier of a first user and a resource identifier of an accessible resource of the first user, and feeding back an obtained resource identifier ciphertext of the accessible resource to the first user; receiving a resource access request from a second user, and decrypting the resource identifier ciphertext carried in the resource access request; based on a matching state between a first user identifier and a second user identifier, permission verification is performed on the resource access request, the first user identifier is a user identifier obtained by decrypting a resource identifier ciphertext, and the second user identifier is a user identifier of a second user; and if the permission verification is passed, acquiring corresponding resources based on a resource identifier obtained by decrypting the resource identifier ciphertext, and feeding back the corresponding resources to the second user.

Description

Technical Field

[0001] This document relates to the field of network technology, and in particular to a horizontal authority verification method, device and electronic device. Background Art

[0002] In a multi-user network system, in order to prevent users from illegally obtaining resources they do not have access to through methods such as blind guessing or brute force cracking of resource identifiers, it is necessary to perform horizontal permission verification on the user's resource access request, that is, to verify whether the user has the permission to access the resource he requested.

[0003] There are currently two main horizontal permission verification schemes: one is to add corresponding verification logic at each interface based on the business logic of each interface. When the interface receives a resource access request, the resource access request is verified horizontally according to the verification logic at the interface; the other is to add corresponding business logic fields to the resource library table based on the business logic of each interface, such as the user to whom the resource belongs, the historical sharing record of the resource between different users, whether the resource is a public resource, etc. When a resource access request is received from a user, it is verified based on the business logic fields in the resource library table whether the user has the permission to access the resource.

[0004] However, the first method requires the transformation of the original backend system, which is labor-intensive, risky, and prone to omissions. In addition, when the business logic of the interface is more complex, the verification logic will also become extremely complex. The second method requires sorting out the business logic involved in all interfaces, which is not only cumbersome and prone to omissions, but also leads to excessive data volume in the resource library table due to the overly complex business logic, and even causes business intrusion. Summary of the invention

[0005] The purpose of the embodiments of this specification is to provide a horizontal authority verification method, device and electronic device for implementing horizontal authority verification in a simple and efficient manner without intruding on the business.

[0006] In order to achieve the above purpose, the embodiments of this specification adopt the following technical solutions:

[0007] In a first aspect, a horizontal authority verification method is provided, comprising:

[0008] Encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user, and feeding back the obtained ciphertext of the resource identifier of the accessible resource to the first user;

[0009] receiving a resource access request from a second user, and decrypting a resource identification ciphertext carried in the resource access request;

[0010] Based on the matching status between the first user identifier and the second user identifier, the resource access request is subjected to permission verification; the first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user;

[0011] If the authority check passes, the corresponding resource is obtained based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and fed back to the second user.

[0012] In a second aspect, a device is provided, comprising:

[0013] An encryption processing module, used to encrypt the user identification of the first user and the resource identification of the resource accessible to the first user, and feed back the obtained ciphertext of the resource identification of the accessible resource to the first user;

[0014] A decryption processing module, used to receive a resource access request from a second user, and decrypt the resource identification ciphertext carried in the resource access request;

[0015] An authority verification module, used to perform authority verification on the resource access request based on a matching status between a first user identifier and a second user identifier; the first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user;

[0016] The acquisition module is used to acquire the corresponding resource based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and feed it back to the second user when the authority verification is passed.

[0017] According to a third aspect, an electronic device is provided, including:

[0018] Processor; and

[0019] a memory arranged to store computer executable instructions which, when executed, cause the processor to:

[0020] Encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user, and feeding back the obtained ciphertext of the resource identifier of the accessible resource to the first user;

[0021] receiving a resource access request from a second user, and decrypting a resource identification ciphertext carried in the resource access request;

[0022] Based on the matching status between the first user identifier and the second user identifier, the resource access request is subjected to permission verification; the first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user;

[0023] If the authority check passes, the corresponding resource is obtained based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and fed back to the second user.

[0024] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores one or more programs, and when the one or more programs are executed by an electronic device including a plurality of application programs, the electronic device performs the following operations:

[0025] Encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user, and feeding back the obtained ciphertext of the resource identifier of the accessible resource to the first user;

[0026] receiving a resource access request from a second user, and decrypting a resource identification ciphertext carried in the resource access request;

[0027] Based on the matching status between the first user identifier and the second user identifier, the resource access request is subjected to permission verification; the first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user;

[0028] If the authority check passes, the corresponding resource is obtained based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and fed back to the second user.

[0029] The scheme of the embodiment of the present specification encrypts the user identification of the first user and the resource identification of the accessible resource of the first user, and feeds back the obtained resource identification ciphertext of the accessible resource to the first user. On the one hand, the first user can directly use the resource identification ciphertext to access his own accessible resources without directly using the plaintext of the resource identification, thereby preventing the first user from illegally obtaining resources that he is not authorized to access by blind guessing or brute force cracking based on the plaintext of the existing resource identification; on the other hand, the resource identification ciphertext fed back to the first user carries the user identification of the first user, and changes in the user identification or resource identification will cause changes in the resource identification ciphertext. If the user identification obtained by decrypting the resource identification ciphertext used by the second user to access the resource does not match the user identification of the second user, it can be determined that the resource identification ciphertext was illegally obtained by the second user, and then based on this layer of simple verification logic, the permission verification of the resource access request can be implemented, and when the permission verification passes, the corresponding resource is obtained based on the decrypted resource identification and fed back to the second user, which is equivalent to transplanting the business logic of the second user's accessible resources to the front end, so that the back-end system no longer needs to execute complex business logic, thereby reducing business intrusion on the back-end system, and this method is relatively fast and significantly improves the efficiency of horizontal permission verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The drawings described herein are used to provide a further understanding of this specification and constitute a part of this specification. The illustrative embodiments and descriptions of this specification are used to explain this specification and do not constitute an improper limitation on this specification. In the drawings:

[0031] Figure 1 An application scenario diagram of a horizontal authority verification method provided by an embodiment of this specification;

[0032] Figure 2 A flowchart of a horizontal authority verification method provided for an embodiment of this specification;

[0033] Figure 3 One of the application diagrams of a horizontal authority verification method provided by an embodiment of this specification;

[0034] Figure 4 A second diagram of an application method of a horizontal authority verification method provided by an embodiment of this specification;

[0035] Figure 5 FIG. 3 is a diagram of an application method of a horizontal authority verification method provided by an embodiment of this specification;

[0036] Figure 6 A schematic diagram of the structure of a horizontal authority verification device provided for one embodiment of this specification;

[0037] Figure 7 A schematic diagram of the structure of an electronic device provided for one embodiment of the present specification. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical solutions and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in combination with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this document.

[0039] The terms "first", "second", etc. in this specification and claims are used to distinguish similar objects, and are not used to describe a particular order or precedence. It should be understood that the terms used in this way are interchangeable where appropriate so that the embodiments of this specification can be implemented in an order other than those illustrated or described herein. In addition, "and / or" in this specification and claims means at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0040] The terms involved in the embodiments of this specification include:

[0041] Horizontal permission check: In a multi-tenant system or multi-user system, an access control check is required to prevent users from obtaining other users' resources by guessing resource identifiers.

[0042] Resources: Information owned by tenants or users, including but not limited to user orders, uploaded documents, etc. Resources belong to users.

[0043] Horizontal permission brute force attack: An attack method that attempts to obtain resources by using a large number of guesses and exhaustive resource identifiers.

[0044] Symmetric encryption: An encryption method that uses a single password system, that is, the same key is used to encrypt and decrypt information.

[0045] The technical solutions provided by the embodiments of this specification are described in detail below in conjunction with the accompanying drawings.

[0046] The horizontal authority verification method provided by one or more embodiments of this specification can be applied to Figure 1 In the illustrated scenario, the scenario includes a client 11 and a backend system 12 .

[0047] The client 11 refers to a client of an application (Application, APP), such as a web client. The client 11 is usually installed on an electronic device, which may include, but is not limited to, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, etc., or a combination of any of these devices.

[0048] The backend system 12 refers to a system for providing services to the client 11, which may include one or more servers. The resource library of the backend system 12 stores various resources, which may include but are not limited to: documents, user orders, pictures, etc. The client 11 and the backend system 12 are connected via a network.

[0049] Specifically, the user 20 can log in to the backend system 12 through the client 11 to access resources, such as sending a resource access request to the interface provided by the backend system 12 to request access to a resource in the backend system 12. At this time, the backend system 12 needs to perform a horizontal permission check, such as checking whether the user 12 has access rights to the resource.

[0050] Furthermore, the above scenario may also include a configuration management platform 13, which is connected to the back-end system 12 via a network. The configuration management platform 13 may be used to manage and configure the back-end system 12, such as providing the back-end system 12 with permission verification configuration information for horizontal permission verification. Specifically, the administrator 30 may log in to the configuration management platform 13 to set the permission verification configuration information, so that when the back-end system 12 receives a resource access request from the client 11, it may determine whether to perform horizontal permission verification on the resource access request and how to perform horizontal permission verification based on the permission verification configuration information.

[0051] Furthermore, the above scenario may also include a preset processing module 14 for performing encryption and decryption operations. The preset processing module 14 may be a pre-deployed functional module with encryption and decryption functions, which may be deployed in the back-end system 12 or in other systems. By having the preset processing module 14 perform encryption and decryption processing, the encryption and decryption process and the permission verification process may be isolated, thereby further improving the security of resource access.

[0052] The horizontal authority verification method provided in the embodiments of this specification will describe in detail how the back-end system 12 performs horizontal authority verification.

[0053] Please refer to Figure 2 , is a flow chart of a horizontal authority verification method provided by an embodiment of the present specification, which can be applied to a back-end system (such as Figure 1 The backend system 12 shown in FIG. Figure 2 As shown, the method may include the following steps:

[0054] S202: Encrypt the user identifier of the first user and the resource identifier of the accessible resource of the first user, and feed back the obtained ciphertext of the resource identifier of the accessible resource to the first user.

[0055] The first user may be the currently logged-in user, or may be the user who requests to obtain the resource identifier of the accessible resource, or may be any other user. The user identifier of the user indicates an identifier that uniquely identifies the user, such as a user name, a user identifier (ID) assigned by a backend system corresponding to the user name, etc.

[0056] The user's accessible resources refer to the resources that the user has the right to access. The resource identifier of a resource refers to the identifier used to uniquely identify the resource, which may include, but is not limited to, the business primary key of the resource, the logical primary key of the resource in the resource table to which it belongs, etc. In a specific application, the resource library table used to store resources records fields such as the resource identifier of the resource, the user identifier of the owner of the resource, and the name of the resource. By querying the resource library table based on the user identifier of the first user, the resource identifier of the first user's accessible resource can be obtained.

[0057] In specific applications, the back-end system can use a variety of encryption methods to encrypt the user identifier of the first user and the resource identifier of the accessible resources. In an optional implementation method, in order to prevent other parties except the back-end system from understanding the processing logic of horizontal permission verification and to prevent other parties from forging resource identifier ciphertext and illegally obtaining protected resources, a symmetric encryption method can be used. Specifically, a preset symmetric key can be used to encrypt the user identifier of the first user and the resource identifier of the accessible resources of the first user. More specifically, the user identifier of the first user and the resource identifier of the accessible resources of the first user can be concatenated, and then the concatenated string can be encrypted using a preset symmetric key to obtain the resource identifier ciphertext of the accessible resources.

[0058] For example, the user ID of the first user is zhangsan, and the accessible resources include document aaa and document bbb, wherein the resource ID docId of document aaa is 1, and the resource ID docId of document bbb is 2. The resource ID ciphertexts of document aaa and document bbb obtained in the above manner are as follows:

[0059] encrypt(“zhangsan”+”#”+1)=123saasy18s7f7vj2;

[0060] encrypt(“zhangsan”+”#”+2)=d9dkw7d5ewskjreis.

[0061] Of course, it should be understood that in some other optional implementations, other encryption methods may also be used for encryption, such as asymmetric keys, and the embodiments of this specification do not limit this.

[0062] It should be noted that the key used in the above encryption process may be pre-set for the resource, and the keys corresponding to different resources may be the same or different, and the embodiments of this specification do not limit this. In addition, considering that the same resource can be uniquely identified by different information, that is, one resource may correspond to multiple resource identifiers, such as a user order can be uniquely identified by an order number or a waybill number. In this case, for each resource identifier, the resource identifier and the user's user identifier can be encrypted separately to obtain the resource identifier ciphertext of the resource identifier. Of course, when the same resource corresponds to multiple resource identifiers, the multiple resource identifiers can also be concatenated to obtain a new resource identifier, and then the new resource identifier and the user's user identifier can be encrypted to obtain the resource identifier ciphertext.

[0063] In the embodiments of the present specification, the back-end system can proactively feed back the resource identifier ciphertext of the first user's accessible resources to the first user to ensure that the first user can more conveniently use the resource identifier ciphertext to access resources even when the resource identifier is not known, thereby preventing users from illegally obtaining other people's resource identifiers and resources through a large number of blind guesses or brute force cracking of existing resource identifiers.

[0064] In order to improve the reliability of horizontal permission verification and further improve the security of resource access, in another more preferred implementation method, the back-end system can feedback the ciphertext of the resource identifier of the first user's accessible resources to the first user when the first user requests to obtain the resource identifier.

[0065] For example, Figure 3 As shown, the first user Zhang San sends an accessible resource acquisition request " / lisMydocs" to the business interface of the back-end system through the client to request the resource identification of his own accessible resources. In response to receiving the accessible resource acquisition request, the back-end system queries from the resource library table that Zhang San's accessible resources include documents aaa and bbb, and then encrypts Zhang San's user ID "zhangsan" and the resource identification "1" of document aaa to obtain the resource identification ciphertext "123saasy18s7f7vj2" of document aaa, and encrypts Zhang San's user ID "zhangsan" and the resource identification "2" of document bbb to obtain the resource identification ciphertext "d9dkw7d5ewskjreis" of document bbb; then, the back-end system feeds back the resource identification ciphertexts of document aaa and document bbb to the client for display.

[0066] Furthermore, in order to realize dynamic and flexible horizontal permission verification, in another more preferred embodiment, the back-end system can determine whether to encrypt the resource identifier of the accessible resource of the first user and the encryption method used for encryption, etc. according to the preset permission verification configuration information. Specifically, when the back-end system receives the accessible resource acquisition request from the first user, it can determine the target encryption policy corresponding to the accessible resource acquisition request based on the preset first permission verification configuration information, wherein the first permission verification configuration information includes the correspondence between different types of resource acquisition requests and encryption policies, and the encryption policy is used to indicate whether to perform permission verification on the resource requested by the corresponding resource acquisition request and the encryption method used for permission verification; if the target encryption policy indicates that the accessible resource is to be verified, the resource identifier of the accessible resource is obtained from the resource library, and the user identifier of the first user and the resource identifier of the accessible resource are encrypted based on the encryption method indicated by the target encryption policy. Wherein, the encryption method may, for example, include but is not limited to the key used for encryption, such as a symmetric key.

[0067] For example, continue with Figure 3 Taking the accessible resource acquisition request shown as an example, the back-end system can determine by querying the first permission configuration information that the target encryption policy corresponding to the accessible resource acquisition request indicates to perform permission verification on the accessible resource, and then obtain the resource identifier of the accessible resource from the resource library, and encrypt the user identifier of the first user and the resource identifier of the accessible resource.

[0068] In the embodiments of this specification, in specific applications, the encryption processing of S202 can be performed by the encryption processing module of the backend system itself, or can also be performed by a preset processing module independent of the backend system (such as Figure 3 The preset processing module may be a pre-deployed functional module with encryption and decryption functions, which may be deployed in a back-end system or in other systems. By performing encryption processing on the resource identifier by the preset processing module, the encryption process and the permission verification process may be isolated, thereby further improving the security of resource access.

[0069] Specifically, the process of performing encryption processing of resource identifiers by the preset processing module is as follows: the back-end system sends an encryption request to the preset processing module, and the encryption request carries the user identifier of the first user and the resource identifier of the first user's accessible resources; then, the back-end system receives a first response message returned by the preset processing module for the encryption request, and the first response message carries the ciphertext of the resource identifier of the first user's accessible resources.

[0070] More specifically, when performing encryption processing, the preset processing module may also determine whether to encrypt the resource identifier of the accessible resource of the first user and the encryption method used for encryption according to the preset permission verification configuration information.

[0071] S204: Receive a resource access request from a second user, and decrypt the resource identification ciphertext carried in the resource access request.

[0072] The second user refers to the user who initiates the resource access request.

[0073] In a specific application, the second user may send a resource access request to the backend system through the client to request to obtain the resource to be accessed, wherein the resource access request carries a ciphertext of a resource identifier of the resource to be accessed.

[0074] When the back-end system decrypts the resource identification ciphertext carried in the resource access request, it may use a decryption method corresponding to the encryption method for encrypting the resource identification ciphertext. Specifically, the resource identification ciphertext is obtained by encrypting the user identification and the resource identification ciphertext with a preset symmetric key. Accordingly, the back-end system may decrypt the resource identification ciphertext using the preset symmetric key to obtain the first user identification and the resource identification ciphertext.

[0075] More specifically, the back-end system can match the resource identification ciphertext with the resource identification ciphertext stored in the resource library to determine the symmetric key used to obtain the resource identification ciphertext, and then use the symmetric key corresponding to the matched resource identification ciphertext to decrypt the resource identification ciphertext. Of course, if the corresponding resource identification ciphertext is not matched, it can be determined that the decryption of the resource identification ciphertext carried in the resource access request has failed, and then it can be determined that the resource identification ciphertext carried in the resource access request is an illegal resource identification ciphertext.

[0076] For example, the resource identification ciphertext "123saasy18s7f7vj2" carried in the resource access request is obtained by encrypting the user identification "zhangsan" and the resource identification "1", that is, encrypt("zhangsan"+"#"+1)=123saasy18s7f7vj2. Therefore, the resource identification ciphertext can be decrypted by the corresponding decryption method, that is, decrypt(123saasy18s7f7vj2)="zhangsan"+"#"+1; for another example, the resource identification ciphertext "d9dkw7d5ewskjreis" is obtained by encrypting the user identification "zhangsan" and the resource identification "2", that is, encrypt("zhangsan"+"#"+2)=d9dkw7d5ewskjreis. Therefore, the resource identification ciphertext can be decrypted by the corresponding decryption method, that is, decrypt(d9dkw7d5ewskjreis)="zhangsan"+"#"+2.

[0077] Furthermore, in order to realize dynamic and flexible horizontal permission verification, in another more preferred embodiment, the back-end system can determine whether to perform permission verification on the resource access request of the second user and the decryption method used for the permission verification according to the preset permission verification configuration information. Specifically, the back-end system can determine the target decryption policy corresponding to the resource access request based on the preset second permission verification configuration information, wherein the second permission configuration information includes the correspondence between different access requests and decryption policies, and the decryption policy is used to indicate whether to perform permission verification on the corresponding access request and the decryption method used for the permission verification; then, based on the target decryption policy, the resource identification ciphertext is decrypted. The decryption method may, for example, include but is not limited to the key used for decryption, such as a symmetric key.

[0078] For example, Figure 4 As shown, the second user Zhang San sends a resource access request " / viewDoc?id=123saasy18s7f7vj2" to the business interface of the back-end system through the client, and the request accesses the required resources. In response to receiving the resource access request, the back-end system can determine by querying the second permission configuration information that the target decryption policy corresponding to the resource access request indicates that the resource access request should be subjected to permission verification, and decrypts the resource identification ciphertext carried in the resource access request based on the decryption method indicated by the target decryption policy.

[0079] In the embodiments of this specification, in specific applications, the decryption process of S204 can be performed by the decryption processing module of the backend system itself, or can also be performed by a preset processing module independent of the backend system (such as Figures 3 to 5The preset processing module may be a pre-deployed functional module with encryption and decryption functions, which may be deployed in a back-end system or in other systems. By performing the decryption processing of the resource identification ciphertext by the preset processing module, the decryption process and the permission verification process may be isolated, thereby further improving the security of resource access.

[0080] Specifically, the process of encryption processing of the resource identifier performed by the preset processing module is as follows: the back-end system sends a decryption request to the preset processing module, and the decryption request carries the resource identifier ciphertext; then, the back-end system receives a second response message returned by the preset processing module for the decryption request, and the second response message carries the decryption result of the resource identifier ciphertext, such as a message indicating whether the decryption is successful and the user identifier and resource identifier obtained after the decryption is successful.

[0081] More specifically, when performing decryption processing, the preset processing module may also determine whether to decrypt the resource identification ciphertext and the decryption method used for decryption according to the preset authority verification configuration information.

[0082] S206: Perform permission verification on the resource access request based on the matching status between the first user identifier and the second user identifier.

[0083] The first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user.

[0084] The above matching status is used to indicate whether the first user identifier matches the second user identifier. Because before receiving the resource access request from the second user, the back-end system feeds back the resource identifier ciphertext of the first user's accessible resources to the first user, and the resource identifier ciphertext of the accessible resources is obtained by encrypting the user identifier of the first user and the resource identifier of the first user's accessible resources, so that the resource identifier ciphertext actually carries the user identifier of the first user, and changes in the user identifier or the resource identifier will cause the resource identifier ciphertext to change. If the resource identifier ciphertext used by the second user to access the resource cannot obtain the user identifier of the second user, it can be determined that the resource identifier ciphertext was illegally obtained by the second user. Based on this, based on the matching status between the first user identifier and the second user identifier, it can be determined whether the resource identifier ciphertext carried in the resource access request from the second user is the resource identifier ciphertext of the second user's available accessible resources, and then it can be determined whether the resource access request passes the authority check.

[0085] If so, it can be determined that the resource access request passes the permission check; otherwise, it can be determined that the resource access request fails the permission check.

[0086] Specifically, if the first user identifier matches the second user identifier, it can be determined that the resource identifier ciphertext carried in the resource access request from the second user is the resource identifier ciphertext of the accessible resource of the second user, and further it can be determined that the resource access request passes the authority check.

[0087] If the first user identifier does not match the second user identifier, it can be determined that the resource identifier ciphertext carried in the resource access request from the second user is not the resource identifier ciphertext of the accessible resource available to the second user, and further it can be determined that the resource access request fails the authority check.

[0088] S208: If the authority check passes, the corresponding resource is obtained based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and fed back to the second user.

[0089] For example, Figure 4 For example, the second user Zhangsan sends a resource access request " / viewDoc?id=123saasy18s7f7vj2" to the business interface of the backend system through the client. The resource access request carries the resource identification ciphertext "123saasy18s7f7vj2". The backend system decrypts the resource identification ciphertext to obtain the user identification "zhangsan" and the resource identification "1". Since the first user identification obtained by decryption is consistent with the user identification of the second user Zhangsan, it can be determined that the resource access request has passed the permission verification, and then the content of the document aaa corresponding to the resource identification "1" is obtained from the resource library and fed back to the second user Zhangsan.

[0090] Further, after the above S208, the horizontal permission verification method provided in the embodiment of this specification may also include: if the resource access request from the second user fails the permission verification, rejecting the resource access request. Further, the backend system may also feed back a notification message to the second user indicating that the permission verification has not passed.

[0091] like Figure 5As shown, the second user Zhang San sends a resource access request " / viewDoc?id=XXXXX" to the business interface of the back-end system through the client. The resource access request carries the resource identification ciphertext "XXXXX". If the first user identification obtained by decrypting the resource identification ciphertext is inconsistent with the user identification of the second user Zhang San, the back-end system can determine that the resource access request has not passed the permission check, and then feedback a notification message indicating that the permission check has not passed can be sent to the second user Zhang San. Further, considering that the resource identification ciphertext carried in the received resource access request is not necessarily the resource identification ciphertext of the accessible resource of the second user, such as the resource identification ciphertext obtained by the second user through blind guessing or brute force cracking, it is possible that the resource identification ciphertext cannot be decrypted. In this case, it can also be determined that the received resource access request has not passed the permission check. That is, after the above S206, the horizontal permission verification method provided in the embodiment of this specification may also include: if the resource identification ciphertext carried in the received resource access request fails to be decrypted, the resource access request is rejected.

[0092] The horizontal authority verification method provided in the embodiments of this specification encrypts the user identifier of the first user and the resource identifier of the first user's accessible resources, and feeds back the obtained resource identifier ciphertext of the accessible resources to the first user. On the one hand, this enables the first user to directly use the resource identifier ciphertext to access his own accessible resources without directly using the plaintext of the resource identifier, thereby preventing the first user from illegally obtaining resources that he does not have the right to access by blind guessing or brute force cracking based on the plaintext of the existing resource identifier; on the other hand, the resource identifier ciphertext fed back to the first user carries the user identifier of the first user, and changes in the user identifier or resource identifier will cause the resource identifier ciphertext to change. If the user identifier obtained by decrypting the resource identifier ciphertext used by the second user to access the resource does not match the user identifier of the second user, it can be determined that the resource identifier ciphertext was obtained illegally by the second user. Subsequently, based on this layer of simple verification logic, the permission verification of the resource access request can be implemented, and when the permission verification passes, the corresponding resource is obtained based on the decrypted resource identifier and fed back to the second user. This is equivalent to transplanting the business logic of the accessible resources for the second user to the front end, so that the back-end system no longer needs to execute complex business logic, thereby reducing business intrusion on the back-end system. In addition, this method is relatively fast and significantly improves the efficiency of horizontal permission verification.

[0093] In addition, Figure 2 Corresponding to the horizontal authority verification method shown, the embodiment of this specification also provides a horizontal authority verification device. Figure 6 6 is a schematic diagram of a horizontal authority verification device 600 provided in an embodiment of the present specification, including:

[0094] The encryption processing module 610 is used to encrypt the user identification of the first user and the resource identification of the resource accessible to the first user, and feed back the obtained ciphertext of the resource identification of the accessible resource to the first user;

[0095] The decryption processing module 620 is used to receive a resource access request from a second user and decrypt the resource identification ciphertext carried in the resource access request;

[0096] The permission verification module 630 is used to perform permission verification on the resource access request based on the matching status between the first user identifier and the second user identifier; the first user identifier is the user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is the user identifier of the second user;

[0097] The acquisition module 640 is used to acquire the corresponding resource based on the resource identifier obtained by decrypting the resource identifier ciphertext and feed it back to the second user if the authority check passes.

[0098] The horizontal authority verification device provided in the embodiment of this specification encrypts the user identifier of the first user and the resource identifier of the first user's accessible resources, and feeds back the obtained resource identifier ciphertext of the accessible resources to the first user. On the one hand, it enables the first user to directly use the resource identifier ciphertext to access his own accessible resources without directly using the plaintext of the resource identifier, thereby preventing the first user from illegally obtaining resources that he does not have the right to access by blind guessing or brute force cracking based on the plaintext of the existing resource identifier; on the other hand, the resource identifier ciphertext fed back to the first user carries the user identifier of the first user, and changes in the user identifier or resource identifier will cause the resource identifier ciphertext to change. If the user identifier obtained by decrypting the resource identifier ciphertext used by the second user to access the resource does not match the user identifier of the second user, it can be determined that the resource identifier ciphertext was obtained illegally by the second user. Subsequently, based on this layer of simple verification logic, the permission verification of the resource access request can be implemented, and when the permission verification passes, the corresponding resource is obtained based on the decrypted resource identifier and fed back to the second user. This is equivalent to transplanting the business logic of the accessible resources for the second user to the front end, so that the back-end system no longer needs to execute complex business logic, thereby reducing business intrusion on the back-end system. In addition, this method is relatively fast and significantly improves the efficiency of horizontal permission verification.

[0099] Optionally, the encryption processing module includes:

[0100] an encryption policy determination submodule, configured to determine, upon receiving an accessible resource acquisition request from the first user, a target encryption policy corresponding to the accessible resource based on preset first permission verification configuration information, wherein the first permission verification configuration information includes a correspondence between different types of resource acquisition requests and encryption policies, the encryption policy being used to indicate whether to perform permission verification on the resource requested by the corresponding resource acquisition request and an encryption method used for the permission verification, and the accessible resource acquisition request being used to request to obtain the accessible resource of the first user;

[0101] an identification acquisition submodule, configured to acquire a resource identification of the accessible resource from a resource library if the first encryption policy indicates to perform permission verification on the accessible resource;

[0102] The encryption processing submodule is used to encrypt the user identifier of the first user and the resource identifier of the accessible resource based on the encryption method indicated by the target encryption policy.

[0103] Optionally, the encryption method includes a symmetric key.

[0104] Optionally, the decryption processing module includes:

[0105] a decryption strategy determination submodule, configured to determine a target decryption strategy corresponding to the resource access request based on preset second permission verification configuration information, wherein the second permission verification configuration information includes a correspondence between different access requests and decryption strategies, and the decryption strategy is used to indicate whether to perform permission verification on the corresponding access request and the decryption method used for the permission verification;

[0106] The decryption processing submodule is used to decrypt the resource identification ciphertext carried in the resource access request based on the target decryption policy.

[0107] Optionally, the encryption processing module includes:

[0108] An encryption request sending submodule, used for sending an encryption request to a preset processing module, wherein the encryption request carries a user identifier of the first user and a resource identifier of the accessible resource;

[0109] An encryption result receiving submodule, used for receiving a first response message returned by the preset processing module in response to the encryption request, wherein the first response message carries a ciphertext of a resource identification of the accessible resource;

[0110] The decryption processing module comprises:

[0111] A decryption request sending submodule, used for sending a decryption request to the preset processing module, wherein the decryption request carries the resource identification ciphertext;

[0112] The decryption result receiving submodule is used to receive a second response message returned by the preset processing module in response to the decryption request, wherein the second response message carries a decryption result of decrypting the resource identifier ciphertext.

[0113] Optionally, the horizontal authority verification device further includes:

[0114] The first rejection module is used to reject the resource access request when the decryption of the resource identification ciphertext fails.

[0115] Optionally, the horizontal authority verification device further includes:

[0116] The second rejection module is used to reject the resource access request if the permission verification fails after the permission verification module performs permission verification on the resource access request based on the first user identifier and the second user identifier.

[0117] Obviously, the horizontal authority verification device in the embodiment of this specification can be used as the above Figure 2 The execution subject of the horizontal authority verification method shown in FIG. Figure 2 The functions realized are as follows. Since the principles are the same, they will not be described here.

[0118] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 7 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0119] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0120] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0121] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a horizontal authority verification device at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0122] Encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user, and feeding back the obtained ciphertext of the resource identifier of the accessible resource to the first user;

[0123] receiving a resource access request from a second user, and decrypting a resource identification ciphertext carried in the resource access request;

[0124] Based on the matching status between the first user identifier and the second user identifier, the resource access request is subjected to permission verification; the first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user;

[0125] If the authority check passes, the corresponding resource is obtained based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and fed back to the second user.

[0126] The above is as in this manual Figure 2The method performed by the horizontal authority verification device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in software form. The above processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of this specification can be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of this specification can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in a decoding processor. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0127] It should be understood that the electronic device of the embodiment of this specification can realize the horizontal authority verification device in Figure 2 Functions of the embodiments shown. Since the principles are the same, the embodiments of this specification will not be described in detail here.

[0128] Of course, in addition to software implementation, the electronic device of this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0129] The embodiment of the present specification also provides a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by a portable electronic device including a plurality of application programs, enable the portable electronic device to execute Figure 2 The method of the embodiment shown is specifically used to perform the following operations:

[0130] Encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user, and feeding back the obtained ciphertext of the resource identifier of the accessible resource to the first user;

[0131] receiving a resource access request from a second user, and decrypting a resource identification ciphertext carried in the resource access request;

[0132] Based on the matching status between the first user identifier and the second user identifier, the resource access request is subjected to permission verification; the first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user;

[0133] If the authority check passes, the corresponding resource is obtained based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and fed back to the second user.

[0134] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0135] In short, the above description is only a preferred embodiment of this specification and is not intended to limit the protection scope of this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the protection scope of this specification.

[0136] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer.

[0137] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0138] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0139] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

Claims

1. A horizontal authority verification method, characterized in that: include: Encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user, and feeding back the obtained ciphertext of the resource identifier of the accessible resource to the first user; receiving a resource access request from a second user, and decrypting a resource identification ciphertext carried in the resource access request; Based on the matching status between the first user identifier and the second user identifier, performing permission verification on the resource access request; The first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user; If the authority check passes, the corresponding resource is obtained based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and fed back to the second user.

2. The method according to claim 1, characterized in that The encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user includes: Upon receiving an accessible resource acquisition request from the first user, determining a target encryption policy corresponding to the accessible resource based on preset first permission verification configuration information, wherein the first permission verification configuration information includes a correspondence between different types of resource acquisition requests and encryption policies, the encryption policy being used to indicate whether to perform permission verification on the resource requested by the corresponding resource acquisition request and an encryption method used for performing permission verification, the accessible resource acquisition request being used to request to obtain the accessible resource of the first user; If the first encryption policy indicates to perform permission verification on the accessible resource, obtaining a resource identifier of the accessible resource from a resource library; The user identifier of the first user and the resource identifier of the accessible resource are encrypted based on the encryption method indicated by the target encryption policy.

3. The method according to claim 2, characterized in that The encryption method includes a symmetric key.

4. The method according to claim 1, characterized in that: Decrypting the resource identification ciphertext carried in the resource access request includes: Determine a target decryption policy corresponding to the resource access request based on preset second permission verification configuration information, wherein the second permission verification configuration information includes a correspondence between different access requests and decryption policies, and the decryption policy is used to indicate whether to perform permission verification on the corresponding access request and the decryption method used for the permission verification; Based on the target decryption policy, the resource identification ciphertext carried in the resource access request is decrypted.

5. The method according to claim 1, characterized in that The encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user includes: Sending an encryption request to a preset processing module, wherein the encryption request carries a user identifier of the first user and a resource identifier of the accessible resource; Receiving a first response message returned by the preset processing module in response to the encryption request, wherein the first response message carries a ciphertext of a resource identifier of the accessible resource; The decrypting the resource identification ciphertext carried in the resource access request includes: Sending a decryption request to the preset processing module, wherein the decryption request carries the resource identification ciphertext; A second response message returned by the preset processing module in response to the decryption request is received, wherein the second response message carries a decryption result of decrypting the resource identifier ciphertext.

6. The method according to any one of claims 1 to 5, characterized in that After decrypting the resource identification ciphertext carried in the resource access request, the method further includes: If the decryption of the resource identification ciphertext fails, the resource access request is rejected.

7. The method according to any one of claims 1 to 5, characterized in that After performing permission verification on the resource access request based on the first user identifier and the second user identifier, the method includes: If the permission check fails, the resource access request is rejected.

8. A horizontal authority verification device, comprising: An encryption processing module, used to encrypt the user identification of the first user and the resource identification of the resource accessible to the first user, and feed back the obtained ciphertext of the resource identification of the accessible resource to the first user; A decryption processing module, used to receive a resource access request from a second user, and decrypt the resource identification ciphertext carried in the resource access request; An authority verification module, configured to perform an authority verification on the resource access request based on a matching status between the first user identifier and the second user identifier; The first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user; The acquisition module is used to acquire the corresponding resource based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and feed it back to the second user when the authority verification is passed.

9. An electronic device, comprising: processor; as well as a memory arranged to store computer executable instructions which, when executed, cause the processor to: Encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user, and feeding back the obtained ciphertext of the resource identifier of the accessible resource to the first user; receiving a resource access request from a second user, and decrypting a resource identification ciphertext carried in the resource access request; Based on the matching status between the first user identifier and the second user identifier, performing permission verification on the resource access request; The first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user; If the authority check passes, the corresponding resource is obtained based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and fed back to the second user.

10. A computer-readable storage medium storing one or more programs, which, when executed by an electronic device including a plurality of application programs, causes the electronic device to perform the following operations: Encrypting the user identifier of the first user and the resource identifier of the resource accessible to the first user, and feeding back the obtained ciphertext of the resource identifier of the accessible resource to the first user; receiving a resource access request from a second user, and decrypting a resource identification ciphertext carried in the resource access request; Based on the matching status between the first user identifier and the second user identifier, performing permission verification on the resource access request; The first user identifier is a user identifier obtained by decrypting the ciphertext of the resource identifier, and the second user identifier is a user identifier of the second user; If the authority check passes, the corresponding resource is obtained based on the resource identifier obtained by decrypting the ciphertext of the resource identifier and fed back to the second user.

Images