A method, apparatus, system, and storage medium for permission verification

Abstract

An embodiment of the present application discloses a permission verification method, device, system, and storage medium. The method includes: verifying the identity of a target account and the relationship between the target account and the account to be accessed, and generating a verification ticket for the target account according to the verification result; sending the verification ticket to the target account; receiving a data access request sent by the target account, where the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and includes a verification ticket; determining whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request. This method can effectively improve the convenience of managing and maintaining verification permissions, and there is no need to repeatedly verify a data access request multiple times, saving the processing resources of the server.

Description

Technical Field

[0001] This application relates to the field of Internet technologies, and in particular, to an authority verification method, apparatus, system, and storage medium. Background Art

[0002] In a distributed network, to ensure the security of data storage and prevent the data stored in a server from being illegally accessed, stolen, or tampered with, when a requester initiates an access to the data stored in a server in the distributed network, the server needs to correspondingly verify whether the requester has the authority to access the data. After verifying and confirming that the requester has the authority to access the data, the requester is allowed to access the data.

[0003] The related technologies currently mainly implement the above authority verification process in the following manner: Configure authority verification logics for each server in the distributed network in advance. After a requester initiates an access request for data, the server through which the access request passes correspondingly uses the authority verification logic configured on itself to verify the access request.

[0004] However, the above authority verification method applied to a distributed network has the following defects: On the one hand, configuring authority verification logics for each server in the distributed network is not conducive to the management and maintenance of authorities. When it is necessary to adjust the authority policy, it is necessary to correspondingly adjust the authority verification logics configured on each server, which is cumbersome and complex to operate and prone to incorrect adjustment. On the other hand, an access request corresponding to a data access operation usually needs to pass through multiple servers in the distributed network, and each server through which it passes needs to perform an authority verification on the access request. As a result, an access request will be verified repeatedly multiple times, wasting the processing resources of each server. Summary of the Invention

[0005] Embodiments of this application provide an authority verification method, apparatus, system, and storage medium, which can effectively improve the convenience of managing and maintaining verification authorities and do not need to repeatedly verify a data access request multiple times, saving the processing resources of the server.

[0006] In view of this, a first aspect of this application provides an authority verification method, and the method includes:

[0007] Verify the identity of the target account and the relationship between the target account and the account to be accessed, and generate a verification ticket for the target account according to the verification result;

[0008] Send the verification ticket to the target account;

[0009] Receive the data access request sent by the target account; the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and the data access request includes the verification ticket;

[0010] Determine whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request.

[0011] The second aspect of this application provides a permission verification device, and the device includes:

[0012] A ticket generation module, configured to verify the identity of the target account and the relationship between the target account and the account to be accessed, and generate a verification ticket for the target account according to the verification result;

[0013] A sending module, configured to send the verification ticket to the target account;

[0014] A receiving module, configured to receive the data access request sent by the target account; the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and the data access request includes the verification ticket;

[0015] A permission verification module, configured to determine whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request.

[0016] The third aspect of this application provides a distributed network system, and the system includes: a ticket server and a data storage server;

[0017] The ticket server is configured to verify the identity of the target account and the relationship between the target account and the account to be accessed, and generate a verification ticket for the target account according to the verification result;

[0018] The ticket server is further configured to send the verification ticket to the target account;

[0019] The data storage server is configured to receive the data access request sent by the target account; the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and the data access request includes the verification ticket;

[0020] The data storage server is further configured to determine whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request.

[0021] The fourth aspect of this application provides a device, and the device includes a processor and a memory:

[0022] The memory is used to store a computer program;

[0023] The processor is configured to execute the steps of the permission verification method described in the first aspect above according to the computer program.

[0024] The fifth aspect of the present application provides a computer-readable storage medium, which is used to store a computer program, and the computer program is used to execute the steps of the permission verification method described in the first aspect above.

[0025] The sixth aspect of the present application provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps of the permission verification method described in the first aspect above.

[0026] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0027] The embodiment of the present application provides a permission verification method. This method can complete the verification of the identity of the target account and the relationship between the target account and the account to be accessed at one time, generate a verification ticket for the target account according to the verification result, and send the verification ticket to the target account; thereafter, when the target account triggers an operation to access the data of the account to be accessed, the server can correspondingly receive a data access request including the verification ticket. Furthermore, according to the verification ticket in the data access request, it can be confirmed whether the target account has the permission to access the data of the account to be accessed. Compared with the permission verification method in the related art, the permission verification method provided by the embodiment of the present application does not need to configure permission verification rules for each server in the distributed network. It only needs to centrally configure the permission verification rules on the server for generating the verification ticket. The server verifies the identity of the target account and the relationship between the target account and the account to be accessed, and generates a verification ticket as a data access credential; in this way, the coupling degree of permission management is reduced, and the convenience of permission management and maintenance is improved. In addition, after receiving the data access request, the server can directly determine whether the target account has the permission to access the data of the account to be accessed according to the verification ticket carried in the data access request, without verifying the access permission of the target account according to complex permission verification rules, saving the processing resources of the server. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 It is a schematic diagram of the working principle of the distributed network system provided by the embodiment of the present application;

[0029] Figure 2 It is a schematic flowchart of the permission verification method provided by the embodiment of the present application;

[0030] Figure 3 It is a schematic structural diagram of the verification bill provided by the embodiment of the present application;

[0031] Figure 4 It is an interactive signaling diagram of the permission verification method provided by the embodiment of the present application;

[0032] Figure 5 It is a schematic structural diagram of the first permission verification device provided by the embodiment of the present application;

[0033] Figure 6 It is a schematic structural diagram of the second permission verification device provided by the embodiment of the present application;

[0034] Figure 7 It is a schematic structural diagram of the third permission verification device provided by the embodiment of the present application;

[0035] Figure 8 It is a schematic structural diagram of the fourth permission verification device provided by the embodiment of the present application;

[0036] Figure 9 It is a schematic structural diagram of the fifth permission verification device provided by the embodiment of the present application;

[0037] Figure 10 It is a schematic structural diagram of the server provided by the embodiment of the present application. Detailed implementation manners

[0038] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0039] In the description, claims and above-mentioned drawings of the present application, the terms "first", "second", "third", "fourth", etc. (if any) are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not necessarily limit to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0040] In the related art, it is necessary to configure permission verification logic for each server in the distributed network. When a data access request passes through a certain server, the server needs to verify the data access request according to the permission verification logic configured by itself to determine whether the account initiating the data access request has the permission to access the data it wants to access. On the one hand, configuring permission verification logic for each server in the distributed network is not conducive to the management and maintenance of permissions. When it is necessary to adjust the permission policy, it is necessary to correspondingly adjust the permission verification logic configured on each server, and the operation is cumbersome and complex. On the other hand, a data access request corresponding to a data access operation usually needs to pass through multiple servers, and these multiple servers repeatedly verify the data access request, which will cause waste of server processing resources.

[0041] In view of the problems existing in the above-mentioned related art, the embodiments of the present application provide a permission verification method, which can effectively improve the convenience of managing and maintaining access permissions and avoid wasting the processing resources of the server.

[0042] Specifically, in the permission verification method provided by the embodiments of the present application, the identity of the target account and the relationship between the target account and the account to be accessed can be verified first, a verification ticket for the target account can be generated according to the verification result, and the verification ticket can be sent to the target account. After that, when the target account triggers an operation to access the data of the account to be accessed, a data access request generated in response to this operation can be received accordingly. The data access request includes the verification ticket. Furthermore, it can be determined whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request.

[0043] Compared with the permission verification method in the related art, the permission verification method provided by the embodiments of the present application does not need to configure permission verification rules for each server in the distributed network. Instead, the permission verification rules can be centrally configured on the server for generating verification tickets. This server verifies the identity of the target account and the relationship between the target account and the account to be accessed, and generates a verification ticket as a data access credential. In this way, the coupling degree of permission management is reduced, and the convenience of permission management and maintenance is improved. In addition, after receiving a data access request, the server can directly determine whether the target account has permission to access the data of the account to be accessed based on the verification ticket carried in the data access request, without verifying the access permission of the target account according to complex permission verification rules, saving the processing resources of the server.

[0044] It should be noted that the permission verification method provided by the embodiments of the present application can be applied to a distributed network system, which may include a ticket server and multiple data storage servers. Among them, the ticket server can verify the identity of the target account and the relationship between the target account and the account to be accessed, generate a verification ticket for the target account according to the verification result, and send the verification ticket to the target account. The data storage server can receive a data access request generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and determine whether the target account has permission to access the data of the account to be accessed according to the data access request. In actual deployment, the above-mentioned ticket server and data storage server can be independent servers, cluster servers or cloud servers.

[0045] To facilitate the understanding of the permission verification method provided by the embodiments of the present application, the distributed network system to which the permission verification method provided by the embodiments of the present application is applied will be introduced first below.

[0046] See Figure 1 , Figure 1 which is a schematic diagram of the working principle of the distributed network system provided by the embodiments of the present application. As Figure 1 shown, the distributed network system includes a ticket server 110 and multiple data storage servers 120. The ticket server 110 and multiple data storage servers 120 can both communicate with the terminal device 130 through the network. An application client that supports logging in to the target account runs on the terminal device 130.

[0047] In practical applications, the ticket server 110 can verify the identity of the target account and the relationship between the target account and the account to be accessed, and obtain the verification ticket of the target account according to the verification result. Exemplarily, when the ticket server 110 detects that a user logs in to the target account, it can verify the identity of the target account according to the login information input when logging in to the target account, obtain the first verification result, and generate the main verification ticket of the target account according to the first verification result; when detecting that data of the account to be accessed is accessed through the target account, it verifies the relationship between the target account and the account to be accessed, obtains the second verification result, and generates the secondary verification ticket of the target account according to the second verification result; in this way, the main verification ticket and the secondary verification ticket together constitute the verification ticket of the target account.

[0048] After the ticket server 110 generates the verification ticket of the target account, it sends the verification ticket to the terminal device 130 through the network. Furthermore, the terminal device 130 can generate a data access request correspondingly in response to the operation of accessing the data of the account to be accessed triggered by the target account, and add the verification ticket to the data access request. The terminal device 130 sends the data access request to the data storage server 120 for storing the data of the account to be accessed through the network.

[0049] It should be understood that if the ticket server 110 verifies the relationship between the target account and the account to be accessed in response to the operation of accessing the data of the account to be accessed triggered by the target account, after the terminal device 130 receives the verification ticket of the target account, it can directly generate a data access request including the verification ticket and send it to the data storage server 120 without waiting for the target account to trigger the operation of accessing the data of the account to be accessed again.

[0050] It should be noted that the operation of accessing the data of the account to be accessed triggered by the target account usually may involve accessing various data of the account to be accessed. For example, accessing the avatar data, personal signature data, personal log data, organization data to which the account belongs, etc. of the account to be accessed; correspondingly, the data access request generated in response to the above operation may need to access multiple data storage servers 120.

[0051] After receiving a data access request sent by the terminal device 110, the data storage server 120 can determine whether the target account has the permission to access the data of the account to be accessed stored therein according to the verification ticket of the target account carried in the data access request. Exemplarily, assuming that the verification ticket of the target account includes a primary verification ticket and a secondary verification ticket, the data storage server 120 can first determine whether the identity of the target account is legal according to the primary verification ticket. If the identity of the target account is determined to be legal, then determine whether the relationship between the target account and the account to be accessed is a preset relationship according to the secondary verification ticket. If the relationship between the target account and the account to be accessed is determined to be a preset relationship, allow the target account to access the data of the account to be accessed stored therein.

[0052] In the above distributed network system, the permission verification logic is centrally deployed on the ticket server 110, and the ticket server 110 uniformly verifies the identity of the target account and the relationship between the target account and the account to be accessed, and generates a verification ticket as the data access credential of the target account. In this way, the coupling degree of permission management is reduced, which is convenient for centralized management and maintenance of the permission verification logic. When it is necessary to access the data of the account to be accessed through the target account, the terminal device 130 can directly generate a data access request carrying the verification ticket and send it to the data storage server 120. The data storage server 120 can determine whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request, without verifying the access permission of the target account according to complex permission verification rules, thus avoiding waste of the processing resources of the data storage server 120.

[0053] It should be noted that Figure 1 The structure of the distributed network system shown is only an example. In practical applications, the ticket server can cooperate with other servers in the distributed network system to generate the verification ticket of the target account. For example, cooperate with the login server to verify the identity of the target account and generate the primary verification ticket, and cooperate with the relationship storage server to verify the relationship between the target account and the account to be accessed and generate the secondary verification ticket, and so on. No limitation is made to the structure of the distributed network system provided in the embodiments of the present application here.

[0054] The permission verification method provided by the present application will be introduced in detail below through method embodiments.

[0055] See Figure 2 , Figure 2 is a schematic flowchart of the permission verification method provided by the embodiments of the present application. For the convenience of introduction, the permission verification method will be introduced below by taking the example that the permission verification method is jointly executed by the ticket server and the data storage server in the distributed network system. As Figure 2 shown, the permission verification method includes the following steps:

[0056] Step 201: Verify the identity of the target account and the relationship between the target account and the account to be accessed, and generate a verification ticket for the target account according to the verification result.

[0057] In practical applications, a user can use the registered target account to log in to an application platform, and can trigger an operation to access data of other accounts on the application platform through the target account. Exemplarily, a user can use the registered target account to log in to a social platform, and trigger an operation to access data of other accounts on the social platform through the target account, such as triggering access to personal information, log data, favorite data, etc. of other accounts.

[0058] In view of the above situation, the ticket server in the distributed network system on which the application platform depends needs to verify the identity of the target account and the relationship between the target account and the account to be accessed, and generate a verification ticket for the target account according to the verification result. This verification ticket can be used as a credential for the target account to access data of the account to be accessed.

[0059] It should be noted that the above account to be accessed can be determined according to the data access operation triggered by the target account. For example, assuming that an operation to access data of a specific account is triggered by the target account, then the specific account to which the data to be accessed by the target account belongs should be the above account to be accessed. In addition, the above account to be accessed can also be determined according to the communication relationship of the target account on the application platform. For example, accounts having a friend relationship with the target account can be used as the accounts to be accessed, or other accounts belonging to the same user group as the target account can be used as the accounts to be accessed. This application does not make any limitation on the above account to be accessed.

[0060] In a possible implementation manner, the ticket server can generate a main verification ticket and a secondary verification ticket for the target account respectively according to the verification result of the identity of the target account and the verification result of the relationship between the target account and the account to be accessed. That is, the ticket server can verify the login identity information of the target account to obtain a first verification result, and generate a main verification ticket for the target account according to the first verification result. This main verification ticket is used to represent whether the identity of the target account is legal; the ticket server can verify the relationship between the target account and the account to be accessed to obtain a second verification result, and generate a secondary verification ticket for the target account according to the second verification result. This secondary verification ticket is used to represent whether the relationship between the target account and the account to be accessed is a preset relationship.

[0061] Specifically, when the ticket server detects that a user logs in to a target account, it can obtain the login identity information entered by the user when logging in to the target account, verify the legitimacy of the target account based on the login identity information, and generate a first verification result that can represent the legitimacy of the target account; then, generate a main verification ticket for the target account according to the first verification result, and the main verification ticket can also correspondingly reflect whether the identity of the target account is legal.

[0062] Furthermore, the ticket server can verify the relationship between the target account and the account to be accessed, determine whether the relationship between the target account and the account to be accessed is a preset relationship, and generate a corresponding second verification result; it should be noted that if the relationship between the target account and the account to be accessed is a preset relationship, it means that the target account has the permission to access the data of the account to be accessed, and the preset relationship can be set according to actual needs. For example, it can be set as any one or any combination of a friend relationship, a relationship belonging to the same user group, and a relationship belonging to the same organization. This application does not make any limitations on the preset relationship here. Then, a secondary verification ticket for the target account can be generated according to the second verification result, and the secondary verification ticket can also correspondingly reflect whether the relationship between the target account and the account to be accessed is the above-mentioned preset relationship.

[0063] It should be understood that in actual applications, the ticket server can generate the main verification ticket for the target account only when it determines that the identity of the target account is legal, and does not generate the main verification ticket for the target account when it determines that the identity of the target account is illegal. Or, the ticket server can also generate a main verification ticket for representing the legal identity of the target account when it determines that the identity of the target account is legal, and generate a main verification ticket for representing the illegal identity of the target account when it determines that the identity of the target account is illegal. This application does not make any limitations on the generation conditions of the main verification ticket and the content it represents.

[0064] Similarly, the ticket server can generate the secondary verification ticket for the target account only when it determines that the relationship between the target account and the account to be accessed is a preset relationship, and does not generate the secondary verification ticket for the target account when it determines that the relationship between the target account and the account to be accessed is not a preset relationship. Or, the ticket server can also generate a secondary verification ticket for representing that the relationship between the target account and the account to be accessed is a preset relationship when it determines that the relationship between the target account and the account to be accessed is a preset relationship, and generate a secondary verification ticket for representing that the relationship between the target account and the account to be accessed is not a preset relationship when it determines that the relationship between the target account and the account to be accessed is not a preset relationship. This application also does not make any limitations on the generation conditions of the secondary verification ticket and the content it represents.

[0065] It should be noted that in practical applications, in order to save the processing resources of the ticket server, the ticket server may only execute the operation of verifying whether the relationship between the target account and the account to be accessed is a preset relationship and generating a secondary verification ticket based on the main verification ticket indicating that the identity of the target account is legal. In the case where the main verification ticket indicates that the identity of the target account is illegal, the operation of verifying the relationship between the target account and the account to be accessed and generating a secondary verification ticket is not continued.

[0066] To ensure the security of the account identity information, the ticket server may generate the above-mentioned main verification ticket and secondary verification ticket in the following manner: encrypt the identity information of the target account using a first encryption key to obtain first encrypted data; generate a main verification ticket based on the first verification result, the first encrypted data, and the hash value signature of the first encrypted data; determine a second encryption key according to the first encryption key, and encrypt the relationship type between the target account and the account to be accessed, as well as the identity information of the account to be accessed, using the second encryption key to obtain second encrypted data; generate a secondary verification ticket based on the second verification result, the second encrypted data, and the hash value signature of the second encrypted data.

[0067] Specifically, the ticket server may adopt symmetric encryption technology to encrypt the identity information of the target account (such as the ID of the target account) and a random number using the first encryption key to obtain first encrypted data; furthermore, use the main ticket type corresponding to the first verification result, the first encrypted data, and the hash value signature of the first encrypted data to form the main verification ticket of the target account; it should be understood that if the first verification result indicates that the identity of the target account is legal, the main ticket type in the main verification ticket should indicate that the main verification ticket is a legal ticket, and if the first verification result indicates that the identity of the target account is illegal, the main ticket type in the main verification ticket should indicate that the main verification ticket is an illegal ticket. Figure 3 Figure (a) shows a schematic structural diagram of an exemplary main verification ticket. The main verification ticket includes a main ticket type TicketType1, first encrypted data EncryptedData1, and a hash value signature Sign1 of the first encrypted data EncryptedData1. Among them, the random number Random and the identity information User1_ID of the target account are encrypted in the first encrypted data EncryptedData1.

[0068] To ensure the association between the secondary verification ticket of the target account and the main verification ticket of the target account, the ticket server may determine a second encryption key according to the first encryption key; exemplarily, the ticket server may directly use the first encryption key as the second encryption key, or perform specific processing on the first encryption key to obtain the second encryption key. For example, add specific characters to the first encryption key to obtain the second encryption key.

[0069] After obtaining the second encryption key, the ticket server may use symmetric encryption technology to encrypt the relationship type between the target account and the account to be accessed, as well as the identity information of the account to be accessed, with the second encryption key to obtain the second encrypted data. Furthermore, a subordinate verification ticket for the target account is formed by using the subordinate ticket type corresponding to the second verification result, the second encrypted data, and the hash value signature of the second encrypted data. It should be understood that if the second verification result indicates that the relationship between the target account and the account to be accessed is a preset relationship, the subordinate ticket type in the subordinate verification ticket should indicate that the subordinate verification ticket is a legal ticket; if the second verification result indicates that the relationship between the target account and the account to be accessed is not a preset relationship, the subordinate ticket type in the subordinate verification ticket should indicate that the subordinate verification ticket is an illegal ticket. Figure 3 As shown in (b), it is a schematic structural diagram of an exemplary subordinate verification ticket. The subordinate verification ticket includes a subordinate ticket type TicketType2, a second encrypted data EncryptedData2, and a hash value signature Sign2 of the second encrypted data EncryptedData2. Among them, the relationship type ReIType between the target account and the account to be accessed and the identity information User2_ID of the account to be accessed are encrypted in the second encrypted data EncryptedData2.

[0070] It should be noted that in practical applications, the ticket server can verify at one time whether the relationships between the target account and multiple accounts to be accessed are preset relationships, and then generate a subordinate verification ticket that can represent whether the relationships between the target account and these multiple accounts to be accessed are preset relationships. That is, the ticket server can determine multiple accounts to be accessed that have the same relationship type as the target account, and for each account to be accessed, determine the second verification result corresponding to the account to be accessed according to the relationship between the target account and the account to be accessed. Furthermore, a subordinate verification ticket is generated according to the second verification results corresponding to each of the multiple accounts to be accessed.

[0071] Exemplarily, after the target account joins the target user group, other accounts in the target user group except the target account itself can be regarded as accounts to be accessed, and the relationships between these accounts to be accessed and the target account are all of belonging to the same user group; correspondingly, the ticket server can respectively determine whether the relationship between the target account and each account to be accessed in the target user group is a preset relationship, and generate the second verification result corresponding to the account to be accessed. Furthermore, the server can generate a subordinate verification ticket for the target account according to the second verification results corresponding to each account to be accessed, and the subordinate verification ticket can represent whether the relationship between the target account and each account to be accessed in the target user group is a preset relationship.

[0072] Taking the example that the secondary verification ticket is generated only when it is determined that the relationship between the target account and the account to be accessed is a preset relationship, assume that the target user group includes the target account, account a, account b, and account c. The ticket server can respectively determine whether the relationship between account a, account b, and account c and the target account is a preset relationship, such as determining whether it is a friend relationship with the target account, and accordingly generate the second verification results corresponding to account a, account b, and account c respectively. If it is determined that both account a and account b have a preset relationship with the target account according to the second verification results corresponding to account a, account b, and account c respectively, then the secondary verification ticket of the target account can be generated according to the identity information of account a and the identity information of account b.

[0073] It should be understood that in practical applications, in addition to being able to perform the above operations in the scenario where the target account joins a certain user group, the above operations can also be performed in scenarios such as when the target account joins a certain organizational structure. The present application does not make any limitations on the implementation scenarios of the above operations.

[0074] In another possible implementation manner, the ticket server can generate a target verification ticket of the target account according to its identity verification result of the target account and the verification result of the relationship between the target account and the account to be accessed. That is, the ticket server can verify the login identity information of the target account to obtain the first verification result, verify the relationship between the target account and the account to be accessed to obtain the second verification result, and then, according to the first verification result and the second verification result, generate the target verification ticket of the target account, and the target verification ticket can represent whether the identity of the target account is legal and whether the relationship between the target account and the account to be accessed is a preset relationship.

[0075] Specifically, when the ticket server detects that a user logs in to the target account, it can obtain the login identity information input by the user when logging in to the target account, verify the legality of the target account according to the login identity information, and generate the first verification result that can represent the legality of the target account; in addition, the ticket server can also verify whether the relationship between the target account and the account to be accessed is a preset relationship, and generate the second verification result that can represent whether the relationship between the target account and the account to be accessed is a preset relationship. Then, the ticket server can generate the verification ticket of the target account according to the above first verification result and second verification result, and the verification ticket of the target account can represent both whether the identity of the target account is legal and whether the relationship between the target account and the account to be accessed is a preset relationship.

[0076] It should be noted that, in practical applications, in order to avoid wasting the processing resources of the ticket server, when the ticket server verifies the login identity information of the target account and determines that the identity of the target account is illegal, it may not continue to execute the operations of verifying the relationship between the target account and the account to be accessed, and generating the target verification ticket; the ticket server may also not continue to execute the operation of generating the target verification ticket when the relationship between the target account and the account to be accessed is not a preset relationship.

[0077] Exemplarily, the target verification ticket may include a field for carrying the first verification result, a field for carrying the first encrypted data (which is obtained by encrypting the identity information of the target account), a field for carrying the second verification result, and a field for carrying the second encrypted data (which is obtained by encrypting the relationship type between the target account and the account to be accessed, and the identity information of the account to be accessed). Optionally, the target verification ticket may further include a hash value signature of the first encrypted data and / or a hash value signature of the second encrypted data. The present application does not specifically limit the information carried in the target verification ticket here.

[0078] In the above two implementation manners for generating the verification ticket of the target account, it is mentioned that the first verification result is obtained by verifying the login identity information of the target account. Herein, the present application provides two exemplary specific implementation manners for obtaining the first verification result by verifying the login identity information of the target account.

[0079] The first implementation manner is that when the login of the target account is detected, the identity of the target account is verified according to the account name and password input when logging in to the target account, and the first verification result is obtained.

[0080] Specifically, when the user logs in to the target account through the application client installed on the terminal device, the user can input the account name and password through the user login interface. After confirming the input of the account name and password, the terminal device can send the input account name and password of the user to the ticket server. Furthermore, the ticket server can verify the received account name and password according to the user login information stored in the login server, and generate the corresponding first verification result; Exemplarily, the ticket server may first search for the received account name in the user login information stored in the login server. If the account name cannot be found, a first verification result indicating that the identity of the target account is illegal is directly generated. If the account name can be found, it is further determined whether the received password is consistent with the password corresponding to the account name stored in the login server. If they are inconsistent, a first verification result indicating that the identity of the target account is illegal is generated. If they are consistent, a first verification result indicating that the identity of the target account is legal is generated.

[0081] The second implementation method: when the target account is detected to be logged in, the identity of the target account is verified according to the contact information and verification code entered when logging in to the target account, and a first verification result is obtained.

[0082] Specifically, when a user logs in to the target account through the application client installed on the terminal device, the user can enter the contact information reserved when registering the target account, such as a mobile phone number, an email address, etc., through the user login interface, and trigger the operation of obtaining the verification code; in response to the trigger operation of obtaining the verification code, when the login server determines that the target account has been registered based on this contact information, it can send a randomly generated verification code to this contact information; after the user receives the verification code through this contact information and further enters the verification code on the user login interface, after confirming the input of the complete verification code, the terminal device can send the previously entered contact information and this verification code to the ticket server. After receiving the contact information and verification code sent by the terminal device, the ticket server can retrieve the verification code sending record of the login server within a preset period (such as within 3 minutes), and verify whether the login server has sent this verification code to this contact information within the preset period. If so, it generates a first verification result indicating that the identity of the target account is legal; if not, it generates a first verification result indicating that the identity of the target account is illegal.

[0083] It should be understood that in actual applications, the ticket server can also use other methods to verify whether the identity of the target account is legal and generate the corresponding first verification result. This application does not make any restrictions on the method of verifying the identity legality of the target account here.

[0084] In the above two implementation methods for generating the verification ticket of the target account, the relationship between the target account and the account to be accessed is also verified to obtain the second verification result. This application hereby gives three exemplary implementation methods for verifying the relationship between the target account and the account to be accessed to obtain the second verification result.

[0085] The first implementation method: according to the relationship type between the target account and the account to be accessed, call the legal relationship library corresponding to this relationship type, and this legal relationship library is used to store the identity information of accounts that meet this relationship type and have a legal relationship with each other; furthermore, based on this legal relationship library, determine the second verification result according to the identity information of the target account and the identity information of the account to be accessed.

[0086] Specifically, assume that the bill server triggers an operation to verify whether the relationship between the target account and the account to be accessed is a preset relationship in response to an operation of accessing the account to be accessed triggered by the target account. After receiving the relationship verification request generated by the terminal device in response to the operation of accessing the data of the account to be accessed triggered by the target account, the bill server can call the legal relationship library corresponding to the relationship type according to the relationship type between the target account and the account to be accessed carried in the relationship verification request. Furthermore, according to the information stored in the legal relationship library, as well as the identity information of the target account and the identity information of the account to be accessed carried in the relationship verification request, determine whether the relationship between the target account and the account to be accessed is legal, and generate a second verification result accordingly.

[0087] It should be noted that in the above-mentioned legal relationship library corresponding to a certain relationship type, the identity information of accounts that meet the relationship type and have a legal relationship with each other is stored. The legal relationship here is equivalent to the preset relationship in the above text, that is, determining that the relationship between the target account and the account to be accessed is legal based on the information stored in the legal relationship library is essentially equivalent to the relationship between the target account and the account to be accessed being a preset relationship, and the target account has the permission to access the data of the account to be accessed.

[0088] For example, assume that the user triggers an operation to access the data of account 2 that belongs to the same user group as account 1 through account 1. Then the terminal device can generate a relationship verification request accordingly and send it to the bill server in response to this operation. The relationship verification request includes the ID of account 1, the ID of account 2, and the relationship type "belonging to the same user group". After receiving the relationship verification request, the bill server can call the legal relationship library corresponding to the relationship type "belonging to the same user group". The legal relationship library stores the identity information of accounts that belong to the same user group and have a legal relationship with each other. Furthermore, based on the information stored in the legal relationship library, determine whether there is a legal relationship between account 1 and account 2, that is, determine whether account 1 has the permission to access the data of account 2, and generate a second verification result accordingly.

[0089] The second implementation method is that when both the target account and the account to be accessed belong to the target organization, the bill server can obtain the first data access rule corresponding to the target organization. The first data access rule can represent the data access permissions between different organizational identities in the target organization. Then, based on the first data access rule, determine the second verification result according to the organizational identities of the target account and the account to be accessed in the target organization respectively.

[0090] In practical applications, the method provided by the embodiments of the present application can be applied to an application platform developed for office scenarios. For different organizations, managers within the organization can set data access rules applicable to the organization, and the data access rules can restrict the access permissions between different organizational identities within the organization. When both the target account and the account to be accessed belong to the target organization, the ticket server can obtain the first data access rule corresponding to the target organization. Furthermore, based on the first data access rule, the organizational identity of the target account in the target organization, and the organizational identity of the account to be accessed in the target organization, it is determined whether the target account has the permission to access the data of the account to be accessed, and a corresponding second verification result is generated.

[0091] For example, assume that both the target account and the account to be accessed belong to a certain enterprise organization. The identity of the target account in the enterprise organization is an employee of Department A, and the organizational identity of the account to be accessed in the enterprise organization is the director of Department B. The first data access rule corresponding to the enterprise organization stipulates that an account at the employee level has no permission to access the data of an account at the director level. Then, based on the first data access rule, the ticket server can generate a second verification result indicating that the target account has no permission to access the data of the account to be accessed.

[0092] It should be understood that the above first data access rule can be set according to the actual needs within the organization, and the present application does not make any limitations on the first data rule here.

[0093] In the third implementation manner, when the target account belongs to the first organization and the account to be accessed belongs to the second organization, the ticket server can obtain the organizational relationship between the first organization and the second organization, as well as the second data access rule corresponding to the organizational relationship; furthermore, based on the second data access rule, the second verification result is determined.

[0094] The method provided by the embodiments of the present application can be applied not only to data access between different accounts belonging to the same organization, but also to data access between different accounts belonging to different organizations. Specifically, when the target account and the account to be accessed belong to the first organization and the second organization respectively, the ticket server can obtain the organizational relationship between the first organization and the second organization, such as a cooperative relationship, an irrelevant relationship, etc., and obtain the second data access rule corresponding to this organizational relationship, such as the data access rule set for the cooperative relationship, the data access rule set for the irrelevant relationship, etc. The second data access rule can represent the data access rule between the accounts in the organization that satisfies this organizational relationship. Furthermore, the ticket server can determine whether the target account has the permission to access the data of the account to be accessed according to the obtained second data access rule, and generate a second verification result accordingly.

[0095] For example, assume that the organizational relationship between the first organization to which the target account belongs and the second organization to which the account to be accessed belongs is a cooperative relationship, and the second data access rule corresponding to the cooperative relationship is that accounts in organizations with a cooperative relationship are allowed to access each other's data. Then, according to this second data access rule, the ticket server can generate a second verification result indicating that the target account has the right to access the data of the account to be accessed.

[0096] It should be understood that the above second data access rule can be set according to actual needs, or can be set by the managers in the organizations with relevant organizational relationships according to actual needs. This application does not make specific limitations on this second data access rule here.

[0097] It should be understood that in actual applications, the ticket server can also use other methods to verify the relationship between the target account and the account to be accessed and generate the corresponding second verification result. This application does not make any limitations on the method of verifying the relationship between the target account and the account to be accessed here.

[0098] Step 202: Send the verification ticket to the target account.

[0099] After generating the verification ticket for the target account through the above verification process, the ticket server can send the verification ticket to the target account accordingly, that is, send it to the terminal device on which the application client supporting the login of the target account runs, so that the target account can use the verification ticket as a voucher to prove whether it can access the data of the account to be accessed.

[0100] It should be noted that when the verification ticket of the target account includes the main verification ticket and the subordinate verification ticket of the target account, the ticket server can first verify the legitimacy of the target account according to the login identity information of the target account, generate the main verification ticket of the target account, and send the main verification ticket of the target account to the target account; subsequently, when the ticket server receives the relationship verification request sent by the target account, it verifies the relationship between the target account and the account to be accessed, generates the subordinate verification ticket of the target account, and then sends the subordinate verification ticket to the target account. That is, the ticket server can send the main verification ticket and the subordinate verification ticket to the target account in two times.

[0101] It should be understood that the above relationship verification request may include the main verification ticket previously received by the target account. After receiving the relationship verification request, the ticket server can first determine whether the identity of the target account is legal according to the main verification ticket, and only when the identity of the target account is legal, verify the relationship between the target account and the account to be accessed and generate the subordinate verification ticket of the target account.

[0102] Step 203: Receive a data access request sent by the target account; the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and the verification ticket is included in the data access request.

[0103] In a possible implementation manner, if the operation of the above ticket server for verifying the relationship between the target account and the account to be accessed is not executed in response to an operation of accessing the data of the account to be accessed triggered by the target account, but is executed in response to other operations (such as an operation of logging in to the target account, an operation of adding the target account to a certain user group, an operation of adding the target account to a certain organization, etc.), then after receiving the verification ticket sent by the ticket server, the target account can further trigger an operation of accessing the data of the account to be accessed. The terminal device generates a data access request accordingly in response to this operation, adds the received verification ticket to the data access request, and then sends the data access request to the data storage server for storing the data of the account to be accessed.

[0104] In another possible implementation manner, if the operation of the above ticket server for verifying the relationship between the target account and the account to be accessed is executed in response to an operation of accessing the data of the account to be accessed triggered by the target account, then after receiving the verification ticket sent by the ticket server, the target account can further generate a data access request corresponding to the operation of accessing the data of the account to be accessed previously triggered by the target account based on the verification ticket, and send the data access request to the data storage server for storing the data of the account to be accessed.

[0105] In other words, in this implementation manner, after detecting an operation of accessing the data of the account to be accessed triggered by the target account, the terminal device can first generate a relationship verification request and send it to the ticket server, requesting the ticket server to verify the relationship between the target account and the account to be accessed and issue a verification ticket corresponding to the verification result; after receiving the verification ticket sent by the ticket server, the terminal device then generates a data access request including the verification ticket and sends it to the data storage server to request the data storage server to provide the data to be accessed by the target account.

[0106] It should be noted that in practical applications, triggering the access to the data of the to-be-accessed account through the target account usually involves accessing various data of the to-be-accessed account. For example, assuming that the operation of accessing the personal information of the to-be-accessed account is triggered through the target account, it may involve accessing various data such as the avatar data, personal label data, personal signature data, and personal profile data of the to-be-accessed account. Since different data storage servers in a distributed network system usually store different types of data, the data access request corresponding to the operation of accessing the data of the to-be-accessed account triggered by the target account may be sent to multiple data storage servers in the distributed network system.

[0107] Step 204: Determine whether the target account has the permission to access the data of the to-be-accessed account according to the verification ticket in the data access request.

[0108] After receiving the data access request carrying the verification ticket of the target account, the data storage server can determine whether the target account has the permission to access the data of the to-be-accessed account according to the verification ticket in the data access request; if it is determined that the target account has the permission to access the data of the to-be-accessed account, the target account is allowed to access the data of the to-be-accessed account, and the data of the to-be-accessed account is sent to the target account; if it is determined that the target account does not have the permission to access the data of the to-be-accessed account, the target account is refused to access the data of the to-be-accessed account.

[0109] In step 201 above, it is introduced that the verification ticket of the target account may include the main verification ticket and the secondary verification ticket of the target account, or may only include the target verification ticket of the target account; the implementation methods for the data storage server to determine whether the target account has the permission to access the data of the to-be-accessed account according to the verification ticket of the target account in these two cases are introduced separately below.

[0110] When the verification ticket of the target account includes the main verification ticket and the secondary verification ticket of the target account, the data storage server can first determine whether the identity of the target account is legal according to the main verification ticket of the target account; in the case of determining that the identity of the target account is legal, determine whether the relationship between the target account and the to-be-accessed account is a preset relationship according to the secondary verification ticket; in the case of determining that the relationship between the target account and the to-be-accessed account is a preset relationship, determine that the target account has the permission to access the data of the to-be-accessed account.

[0111] Specifically, after receiving a data access request including the primary verification ticket and the secondary verification ticket of the target account, the data storage server can first determine whether the identity of the target account is legal based on the primary verification ticket of the target account; if it is not legal, it can determine that the target account has no permission to access the data of the account to be accessed and reject the target account's access to the data of the account to be accessed; if it is legal, it can continue to determine whether the relationship between the target account and the account to be accessed is a preset relationship based on the secondary verification ticket of the target account; if the relationship between the target account and the account to be accessed is not a preset relationship, it can determine that the target account has no permission to access the data of the account to be accessed and reject the target account's access to the data of the account to be accessed; if the relationship between the target account and the account to be accessed is a preset relationship, it is determined that the target account has permission to access the data of the account to be accessed, and the data of the account to be accessed stored by it is provided to the target account.

[0112] It should be understood that if the ticket server generates the primary verification ticket of the target account only when the identity of the target account is verified to be legal and does not generate the primary verification ticket of the target account when the identity of the target account is verified to be illegal, the data storage server can correspondingly determine that the identity of the target account is legal when it determines that the data access request carries the primary verification ticket. If the ticket server generates a primary verification ticket indicating that the identity of the target account is legal when the identity of the target account is verified to be legal and generates a primary verification ticket indicating that the identity of the target account is illegal when the identity of the target account is verified to be illegal, the data storage server needs to correspondingly determine whether the identity of the target account is legal according to the content indicated by the primary verification ticket carried in the data access request.

[0113] Similarly, if the ticket server generates the secondary verification ticket of the target account only when the relationship between the target account and the account to be accessed is verified to be a preset relationship and does not generate the secondary verification ticket of the target account when the relationship between the target account and the account to be accessed is not a preset relationship, the data storage server can correspondingly determine that the target account has permission to access the data of the account to be accessed when it determines that the data access request carries the secondary verification ticket. If the ticket server generates a secondary verification ticket indicating that the relationship between the target account and the account to be accessed is a preset relationship when the relationship between the target account and the account to be accessed is verified to be a preset relationship and generates a secondary verification ticket indicating that the relationship between the target account and the account to be accessed is not a preset relationship when the relationship between the target account and the account to be accessed is not a preset relationship, the data storage server needs to correspondingly determine whether the target account has permission to access the data of the account to be accessed according to the content indicated by the secondary verification ticket carried in the data access request.

[0114] The main verification ticket of the target account includes the first encrypted data (obtained by encrypting the identity information of the target account) and the hash value signature of the first encrypted data. When the secondary verification ticket includes the second encrypted data (obtained by encrypting the relationship type between the target account and the account to be accessed, as well as the identity information of the account to be accessed) and the hash value signature of the second encrypted data, the data storage server can verify the main verification ticket and the secondary verification ticket of the target account in the following manner:

[0115] First, verify the hash value signature in the main verification ticket; after the verification passes, use the first decryption key symmetric to the first encryption key to decrypt the first encrypted data in the main verification ticket to obtain the identity information of the target account; determine whether the identity of the target account is legal according to the type of the main verification ticket. When it is determined that the identity of the target account is legal, verify the hash value signature in the secondary verification ticket; after the verification passes, determine the second decryption key according to the first decryption key, and use the second decryption key to decrypt the second encrypted data in the secondary verification ticket to obtain the relationship between the target account and the account to be accessed, as well as the identity information of the account to be accessed; determine whether the target account has the permission to access the data of the account to be accessed according to the type of the secondary verification ticket and the decrypted identity information of the account to be accessed.

[0116] Specifically, the data storage server can first calculate the hash value signature based on the first encrypted data in the main verification ticket, and then compare the calculated hash value signature with the hash value signature in the main verification ticket to see if they are consistent; if they are not consistent, it can be considered that the first encrypted data carried in the main verification ticket has been tampered with, and the information carried in the main verification ticket is untrustworthy, and the main verification ticket is discarded without performing subsequent operations; if they are consistent, it can be determined that the main verification ticket passes the signature verification. After the signature verification passes, the data storage server can use the first decryption key symmetric to the first encryption key to decrypt the first encrypted data to obtain the identity information of the target account. When the type of the main verification ticket is a legal ticket, it can be determined that the identity of the target account is legal; when the type of the main verification ticket is an illegal ticket, it can be determined that the identity of the target account is illegal.

[0117] When it is determined that the identity of the target account is legal, the data storage server can calculate the hash value signature based on the second encrypted data in the verification ticket, and then compare the calculated hash value signature with the hash value signature in the verification ticket; if the two are inconsistent, it can be considered that the second encrypted data carried in the verification ticket has been tampered with, and the information carried in the verification ticket is untrusted. Discard the verification ticket and do not perform subsequent operations; if the two are consistent, it can be determined that the verification ticket passes the signature verification. After the signature verification passes, the data storage server can determine the second decryption key according to the first decryption key, and then use the second decryption key to decrypt the second encrypted data to obtain the relationship type between the target account and the account to be accessed, as well as the identity information of the account to be accessed; when the type of the verification ticket is a legal ticket, it can be determined that the account to be accessed obtained by decrypting the second encrypted data is the account to be accessed that the target account has permission to access. If the account to be accessed that the target account currently wants to access belongs to the account to be accessed in the second encrypted data, it can be determined that the target account has permission to access the data of the account to be accessed; when the type of the verification ticket is an illegal ticket, it can be determined that the account to be accessed obtained by decrypting the second encrypted data is the account to be accessed that the target account has no permission to access. If the account to be accessed that the target account currently wants to access belongs to the account to be accessed in the second encrypted data, it can be determined that the target account has no permission to access the data of the account to be accessed.

[0118] Since the symmetric encryption algorithm is used to generate the second encrypted data, the method of determining the second decryption key according to the first decryption key should be the same as the method of determining the second encrypted data according to the first encryption key. Exemplarily, if the ticket server directly uses the first encryption key as the second encryption key, the data storage server can directly use the first decryption key as the second decryption key; if the ticket server performs a specific process on the first encryption key to obtain the second encryption key, the data storage server can also perform this specific process on the first decryption key to obtain the second decryption key.

[0119] When the verification ticket of the target account includes the target verification ticket of the target account, the data storage server can directly determine whether the identity of the target account is legal and whether the relationship between the target account and the account to be accessed is a preset relationship according to the target verification ticket; when it is determined that the identity of the target account is legal and the relationship between the target account and the account to be accessed is a preset relationship, it is determined that the target account has permission to access the data of the account to be accessed.

[0120] Specifically, after receiving a data access request including a target verification ticket, the data storage server can directly determine whether the identity of the target account is legal based on the target verification ticket, and whether the relationship between the target account and the account to be accessed is a preset relationship; if it is determined based on the target verification ticket that the identity of the target account is legal and the relationship between the target account and the account to be accessed is a preset relationship, it can be determined that the target account has the permission to access the data of the account to be accessed, and the target account is allowed to access the data of the account to be accessed; if it is determined based on the target verification ticket that the identity of the target account is illegal, and / or the relationship between the target account and the account to be accessed is not a preset relationship, it can be determined that the target account has no permission to access the data of the account to be accessed, and the target account is refused to access the data of the account to be accessed.

[0121] Next, taking the target verification ticket including the first verification result, the first encrypted data (obtained by encrypting the identity information of the target account), the second verification result, the second encrypted data (obtained by encrypting the relationship type between the target account and the account to be accessed, and the identity information of the account to be accessed), and the hash value signature calculated based on the first encrypted data and the second encrypted data as an example, the above verification process will be introduced.

[0122] After receiving a data access request carrying a target verification ticket, the data storage server can first calculate the hash value signature based on the first encrypted data and the second encrypted data in the target verification ticket, and then compare whether the calculated hash value signature is consistent with the hash value signature in the target verification ticket; if the two are inconsistent, it is determined that the target verification ticket fails the signature verification, discard the target verification ticket, and do not continue to perform subsequent operations; if the two are consistent, it is determined that the target verification ticket passes the signature verification. Furthermore, the data storage server can decrypt the first encrypted data to obtain the identity information of the target account, and decrypt the second encrypted data to obtain the relationship type between the target account and the account to be accessed, and the identity information of the account to be accessed; in the case where the first verification result indicates that the identity of the target account is legal and the second verification result indicates that the relationship between the target account and the account to be accessed is a preset relationship, if the account to be accessed that the target account wants to access is among the accounts to be accessed obtained by decrypting the second encrypted data, it can be determined that the target account has the permission to access the data of the account to be accessed; otherwise, in the case where the first verification result indicates that the identity of the target account is illegal, and / or the second verification result indicates that the relationship between the target account and the account to be accessed is not a preset relationship, if the account to be accessed that the target account wants to access is among the accounts to be accessed obtained by decrypting the second encrypted data, it can be determined that the target account has no permission to access the data of the account to be accessed.

[0123] Compared with the privilege verification method in the related art, the privilege verification method provided by the embodiments of the present application does not need to configure privilege verification rules for each server in the distributed network. Instead, it only needs to centrally configure the privilege verification rules on the server for generating verification tickets. This server verifies the identity of the target account and the relationship between the target account and the account to be accessed, and generates a verification ticket as the data access credential. In this way, the coupling degree of privilege management is reduced, and the convenience of privilege management and maintenance is improved. In addition, after receiving a data access request, the server can directly determine whether the target account has the privilege to access the data of the account to be accessed according to the verification ticket carried in the data access request, without verifying the access privilege of the target account according to complex privilege verification rules, thus saving the processing resources of the server.

[0124] To facilitate further understanding of the technical solution provided by the embodiments of the present application, the following takes the example that the target account UserA requests to access the data of the account to be accessed UserB, and combines with Figure 4 the signaling interaction diagram shown in

[0125] Step 401: When UserA logs in to the application platform, the account name and password are sent to the login server.

[0126] Step 402: Based on the account name and password stored therein, the login server verifies the correctness of the account name and password sent by UserA to verify whether the login identity of UserA is legal, and then sends the identity verification result to the ticket server.

[0127] Step 403: According to the identity verification result sent by the login server, the ticket server generates a main verification ticket for UserA and sends the main verification ticket to UserA. The main verification ticket can identify the legality of UserA's login identity.

[0128] Step 404: After UserA triggers an operation to access the data of UserB, a relationship verification request is sent to the ticket server to request the ticket server to verify whether the relationship between UserA and UserB is a preset relationship and generate a secondary verification ticket for UserA. The relationship verification request includes the main verification ticket of UserA, the relationship type between UserA and UserB, and the identity information of UserB.

[0129] Step 405: After receiving the relationship verification request, the ticket server calls the relationship storage server corresponding to the relationship type according to the relationship type between UserA and UserB to verify whether the relationship between UserA and UserB is a preset relationship.

[0130] Step 406: The relationship storage service verifies whether the relationship between UserA and UserB is a preset relationship, and generates a corresponding relationship verification result to feedback to the ticket server.

[0131] Step 407: The ticket server generates a secondary verification ticket for UserA corresponding to the relationship verification result, and sends the secondary verification ticket to UserA.

[0132] Step 408: UserA sends a data access request to the data storage server, and the data access request includes the primary verification ticket and the secondary verification ticket of UserA.

[0133] Step 409: If the data storage server verifies that UserA's identity is legal according to the primary verification ticket in the data access request, and the relationship between UserA and UserB is a preset relationship, then UserA is allowed to access UserB's data. If the data storage server verifies that UserA's identity is illegal according to the primary verification ticket in the data access request, and / or the relationship between UserA and UserB is not a preset relationship, or even finds that the primary verification ticket and / or the secondary verification ticket are missing in the data access request, then the data storage server will reject UserA's access to UserB's data.

[0134] In the above process, the primary verification ticket and the secondary verification ticket can be automatically brought into the request data packet through technical means such as cookies, and passed along with the call of Remote Procedure Call (RPC) to the backend data storage server. The data storage server only needs to simply verify the legality of the primary verification ticket and the secondary verification ticket to identify the identity and permissions of the requester, and intercept the illegal access requests.

[0135] In this way, by using the mechanism of the primary verification ticket and the secondary verification ticket, the data storage servers' verification of the legality of the relationship between UserA and UserB is converted into verifying whether the legal primary verification ticket and secondary verification ticket are carried in the data access request, and the heavy identity verification logic is concentrated on the ticket server.

[0136] For the above-described permission verification method, the present application also provides a corresponding permission verification device to enable the application and implementation of the above permission verification method in practice.

[0137] See Figure 5 , Figure 5 is a schematic structural diagram of a permission verification device 500 corresponding to the permission verification method shown above. As Figure 2 shown, the permission verification device 500 includes: Figure 5 shown, the permission verification device 500 includes:

[0138] The bill generation module 501 is used to verify the identity of the target account and the relationship between the target account and the account to be accessed, and generate a verification bill for the target account according to the verification result;

[0139] The sending module 502 is used to send the verification bill to the target account;

[0140] The receiving module 503 is used to receive the data access request sent by the target account; the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and the verification bill is included in the data access request;

[0141] The permission verification module 504 is used to determine whether the target account has the permission to access the data of the account to be accessed according to the verification bill in the data access request.

[0142] Optionally, based on the Figure 5 permission verification device shown, refer to Figure 6 , Figure 6 which is a schematic structural diagram of another permission verification device 600 provided by an embodiment of the present application. As Figure 6 shown, the bill generation module 501 includes:

[0143] The main bill generation sub-module 601 is used to verify the login identity information of the target account to obtain a first verification result; according to the first verification result, generate a main verification bill for the target account; the main verification bill is used to represent whether the identity of the target account is legal;

[0144] The secondary bill generation sub-module 602 is used to verify the relationship between the target account and the account to be accessed to obtain a second verification result; according to the second verification result, generate a secondary verification bill for the target account; the secondary verification bill is used to represent whether the relationship between the target account and the account to be accessed is a preset relationship.

[0145] Optionally, based on the Figure 6 permission verification device shown, refer to Figure 7 , Figure 7 which is a schematic structural diagram of another permission verification device 700 provided by an embodiment of the present application. As Figure 7 shown, the permission verification module 504 includes:

[0146] The main bill verification sub-module 701 is used to determine whether the identity of the target account is legal according to the main verification bill;

[0147] The slave ticket verification sub-module 702 is used to determine whether the relationship between the target account and the account to be accessed is the preset relationship according to the slave verification ticket when it is determined that the identity of the target account is legal; when it is determined that the relationship between the target account and the account to be accessed is the preset relationship, it is determined that the target account has the right to access the data of the account to be accessed.

[0148] Optionally, based on the permission verification device shown in Figure 6 , the main ticket generation sub-module 601 is specifically used for:

[0149] Encrypt the identity information of the target account using the first encryption key to obtain the first encrypted data;

[0150] Generate the main verification ticket according to the first verification result, the first encrypted data and the hash value signature of the first encrypted data;

[0151] The slave ticket generation sub-module 602 is specifically used for:

[0152] Determine the second encryption key according to the first encryption key;

[0153] Encrypt the relationship type between the target account and the account to be accessed, and the identity information of the account to be accessed using the second encryption key to obtain the second encrypted data;

[0154] Generate the slave verification ticket according to the second verification result, the second encrypted data and the hash value signature of the second encrypted data.

[0155] Optionally, based on the permission verification device shown in Figure 7 , the main ticket verification sub-module 701 is specifically used for:

[0156] Verify the hash value signature in the main verification ticket;

[0157] After the verification passes, use the first decryption key symmetric to the first encryption key to decrypt the first encrypted data in the main verification ticket to obtain the identity information of the target account;

[0158] Determine whether the identity of the target account is legal according to the type of the main verification ticket;

[0159] The slave ticket verification sub-module 702 is specifically used for:

[0160] When it is determined that the identity of the target account is legal, verify the hash value signature in the slave verification ticket;

[0161] After the verification passes, determine the second decryption key according to the first decryption key, and use the second decryption key to decrypt the second encrypted data in the verification ticket to obtain the relationship between the target account and the to-be-accessed account, and the identity information of the to-be-accessed account;

[0162] Determine whether the target account has the permission to access the data of the to-be-accessed account according to the type of the verification ticket and the identity information of the to-be-accessed account in the second encrypted data.

[0163] Optionally, based on the permission verification device shown in Figure 6 the slave ticket generation sub-module 602 is specifically configured to:

[0164] Determine multiple to-be-accessed accounts having the same relationship type as the target account;

[0165] For each to-be-accessed account, determine the second verification result corresponding to the to-be-accessed account according to the relationship between the target account and the to-be-accessed account;

[0166] Generate the verification ticket according to the second verification results respectively corresponding to the multiple to-be-accessed accounts.

[0167] Optionally, based on the permission verification device shown in Figure 5 refer to Figure 8 , Figure 8 which is a schematic structural diagram of another permission verification device 800 provided by an embodiment of the present application. As shown in Figure 8 the ticket generation module 501 includes:

[0168] A target ticket generation sub-module 801, configured to verify the login identity information of the target account to obtain a first verification result; verify the relationship between the target account and the to-be-accessed account to obtain a second verification result; generate a target verification ticket for the target account according to the first verification result and the second verification result; the target verification ticket is used to represent whether the identity of the target account is legal, and whether the relationship between the target account and the to-be-accessed account is a preset relationship.

[0169] Optionally, based on the permission verification device shown in Figure 8 refer to Figure 9 , Figure 9 which is a schematic structural diagram of another permission verification device 900 provided by an embodiment of the present application. As shown in Figure 9 the permission verification module 504 includes:

[0170] The target bill verification sub-module 901 is used to determine whether the identity of the target account is legal according to the target verification bill, and whether the relationship between the target account and the to-be-accessed account is the preset relationship; when it is determined that the identity of the target account is legal and the relationship between the target account and the to-be-accessed account is the preset relationship, it is determined that the target account has the right to access the data of the to-be-accessed account.

[0171] Optionally, based on the permission verification device shown in Figure 6 or Figure 8 the main bill generation sub-module 601 or the target bill generation sub-module 801 is specifically used for:

[0172] When detecting the login of the target account, verify the identity of the target account according to the account name and password input when logging in to the target account, and obtain the first verification result;

[0173] Or, when detecting the login of the target account, verify the identity of the target account according to the contact information and verification code input when logging in to the target account, and obtain the first verification result.

[0174] Optionally, based on the permission verification device shown in Figure 6 or Figure 8 the slave bill generation sub-module 602 or the target bill generation sub-module 801 is specifically used for:

[0175] According to the relationship type between the target account and the to-be-accessed account, call the legal relationship library corresponding to the relationship type; the legal relationship library is used to store the identity information of accounts that meet the relationship type and have a legal relationship with each other;

[0176] Based on the legal relationship library, determine the second verification result according to the identity information of the target account and the identity information of the to-be-accessed account.

[0177] Optionally, based on the permission verification device shown in Figure 6 or Figure 8 when both the target account and the to-be-accessed account belong to the target organization, the slave bill generation sub-module 602 or the target bill generation sub-module 801 is specifically used for:

[0178] Obtain the first data access rule corresponding to the target organization; the first data access rule is used to represent the data access permissions between different organizational identities in the target organization;

[0179] Based on the first data access rule, determine the second verification result according to the organizational identities of the target account and the account to be accessed in the target organization respectively.

[0180] Optionally, based on the Figure 6 or Figure 8 permission verification device shown, when the target account belongs to the first organization and the account to be accessed belongs to the second organization, the ticket generation sub-module 602 or the target ticket generation sub-module 801 is specifically configured to:

[0181] Obtain the organizational relationship between the first organization and the second organization, and the second data access rule corresponding to the organizational relationship;

[0182] Based on the second data access rule, determine the second verification result.

[0183] The permission verification device provided by the embodiments of the present application does not need to configure permission verification rules for each server in the distributed network. It only needs to centrally configure the permission verification rules on the server for generating verification tickets. The server verifies the identity of the target account and the relationship between the target account and the account to be accessed, and generates a verification ticket as a data access credential. In this way, the coupling degree of permission management is reduced, and the convenience of permission management and maintenance is improved. In addition, after receiving a data access request, the server can directly determine whether the target account has permission to access the data of the account to be accessed according to the verification ticket carried in the data access request, without verifying the access permission of the target account according to complex permission verification rules, saving the processing resources of the server.

[0184] The embodiments of the present application also provide a device for verifying permissions. The device can specifically be a server. The server provided by the embodiments of the present application will be introduced from the perspective of hardware implementation below.

[0185] See Figure 10 , Figure 10Schematic diagram of the structure of a server 1000 provided by an embodiment of the present application. The server 1000 may vary greatly due to configuration or performance differences, and may include one or more central processing units (CPUs) 1022 (e.g., one or more processors) and a memory 1032, and one or more storage media 1030 (e.g., one or more mass storage devices) for storing application programs 1042 or data 1044. Among them, the memory 1032 and the storage media 1030 may be transient storage or persistent storage. The programs stored in the storage media 1030 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Further, the central processing unit 1022 may be configured to communicate with the storage media 1030 and execute a series of instruction operations in the storage media 1030 on the server 1000.

[0186] The server 1000 may further include one or more power supplies 1026, one or more wired or wireless network interfaces 1050, one or more input / output interfaces 1058, and / or one or more operating systems 1041, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0187] In the above embodiment, the steps executed by the server may be based on the Figure 10 server structure shown.

[0188] Among them, the CPU 1022 is used to execute the following steps:

[0189] Verify the identity of the target account and the relationship between the target account and the account to be accessed, and generate a verification ticket for the target account according to the verification result;

[0190] Send the verification ticket to the target account;

[0191] Receive a data access request sent by the target account; the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and the data access request includes the verification ticket;

[0192] Determine whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request.

[0193] Optionally, the CPU 1022 may further be used to execute the steps of any implementation manner of the permission verification method provided by the embodiment of the present application.

[0194] An embodiment of the present application also provides a computer-readable storage medium for storing a computer program, which is used to execute any one of the implementation manners of the permission verification method described in the foregoing various embodiments.

[0195] An embodiment of the present application also provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes any one of the implementation manners of the permission verification method described in the foregoing various embodiments.

[0196] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein.

[0197] In several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in an electrical, mechanical, or other form.

[0198] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0199] In addition, each functional unit in various embodiments of the present application can be integrated in one processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0200] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The foregoing storage medium includes: various media that can store computer programs, such as USB flash drives, mobile hard disks, read-only memories (English full name: Read-Only Memory, English abbreviation: ROM), random access memories (English full name: Random Access Memory, English abbreviation: RAM), magnetic disks, or optical discs.

[0201] It should be understood that in this application, "at least one (item)" means one or more, and "multiple" means two or more. "And / or" is used to describe the association relationship of associated objects and indicates that three relationships can exist. For example, "A and / or B" can represent: only A exists, only B exists, and both A and B exist at the same time. Among them, A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after. "At least one (piece) of the following" or its similar expression refers to any combination of these items, including any combination of single items (pieces) or plural items (pieces). For example, at least one (piece) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0202] As described above, the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the various embodiments of this application.

Claims

1. A permission verification method, characterized in that, The method includes: Verifying the identity of the target account and the relationship between the target account and the account to be accessed, and generating a verification ticket for the target account according to the verification result; Sending the verification ticket to the target account; Receiving a data access request sent by the target account; the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and the verification ticket is included in the data access request; Determining whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request; Wherein, the verifying the identity of the target account and the relationship between the target account and the account to be accessed, and generating a verification ticket for the target account according to the verification result includes: Verifying the login identity information of the target account to obtain a first verification result; Generating a main verification ticket for the target account according to the first verification result; the main verification ticket is used to represent whether the identity of the target account is legal; Verifying the relationship between the target account and the account to be accessed to obtain a second verification result; Generating a subordinate verification ticket for the target account according to the second verification result; the subordinate verification ticket is used to represent whether the relationship between the target account and the account to be accessed is a preset relationship.

2. The method according to claim 1, wherein The determining whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request includes: Determining whether the identity of the target account is legal according to the main verification ticket; When it is determined that the identity of the target account is legal, determining whether the relationship between the target account and the account to be accessed is the preset relationship according to the subordinate verification ticket; When it is determined that the relationship between the target account and the account to be accessed is the preset relationship, determining that the target account has the permission to access the data of the account to be accessed.

3. The method according to claim 1, wherein The generating a main verification ticket for the target account according to the first verification result includes: Encrypting the identity information of the target account by using a first encryption key to obtain first encrypted data; Generating the main verification ticket according to the first verification result, the first encrypted data, and the hash value signature of the first encrypted data; The generating a subordinate verification ticket for the target account according to the second verification result includes: Determining a second encryption key according to the first encryption key; Encrypting the relationship type between the target account and the account to be accessed and the identity information of the account to be accessed by using the second encryption key to obtain second encrypted data; Generating the subordinate verification ticket according to the second verification result, the second encrypted data, and the hash value signature of the second encrypted data.

4. The method according to claim 3, wherein The determining whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request includes: Verifying the hash value signature in the main verification ticket; After the verification passes, use the first decryption key symmetric to the first encryption key to decrypt the first encrypted data in the master verification ticket to obtain the identity information of the target account; Determine whether the identity of the target account is legal according to the type of the master verification ticket; When it is determined that the identity of the target account is legal, verify the hash value signature in the slave verification ticket; After the verification passes, determine the second decryption key according to the first decryption key, and use the second decryption key to decrypt the second encrypted data in the slave verification ticket to obtain the relationship between the target account and the to-be-accessed account, and the identity information of the to-be-accessed account; Determine whether the target account has the permission to access the data of the to-be-accessed account according to the type of the slave verification ticket and the identity information of the to-be-accessed account in the second encrypted data.

5. The method according to claim 1 or 3, characterized in that, The verifying the relationship between the target account and the to-be-accessed account to obtain a second verification result includes: Determine multiple to-be-accessed accounts having the same relationship type as the target account; For each to-be-accessed account, determine the corresponding second verification result of the to-be-accessed account according to the relationship between the target account and the to-be-accessed account; The generating the slave verification ticket of the target account according to the second verification result includes: Generate the slave verification ticket according to the second verification results corresponding to the multiple to-be-accessed accounts respectively.

6. The method according to claim 1, wherein The verifying the identity of the target account and the relationship between the target account and the to-be-accessed account, and generating the verification ticket of the target account according to the verification result further includes: Generate the target verification ticket of the target account according to the first verification result and the second verification result; the target verification ticket is used to represent whether the identity of the target account is legal and whether the relationship between the target account and the to-be-accessed account is a preset relationship.

7. The method according to claim 6, characterized in that, The determining whether the target account has the permission to access the data of the to-be-accessed account according to the verification ticket in the data access request includes: Determine whether the identity of the target account is legal and whether the relationship between the target account and the to-be-accessed account is the preset relationship according to the target verification ticket; When it is determined that the identity of the target account is legal and the relationship between the target account and the to-be-accessed account is the preset relationship, determine that the target account has the permission to access the data of the to-be-accessed account.

8. The method according to claim 1 or 6, characterized in that, The verifying the login identity information of the target account to obtain a first verification result includes any one of the following methods: When it is detected that the target account is logged in, verify the identity of the target account according to the account name and password input when logging in to the target account to obtain the first verification result; When it is detected that the target account is logged in, verify the identity of the target account according to the contact information and verification code input when logging in to the target account to obtain the first verification result.

9. The method according to claim 1 or 6, characterized in that, The verifying the relationship between the target account and the to-be-accessed account to obtain a second verification result includes: Based on the relationship type between the target account and the account to be accessed, call the legal relationship library corresponding to the relationship type; the legal relationship library is used to store the identity information of accounts that meet the relationship type and have a legal relationship with each other. Based on the legal relationship library, determine the second verification result according to the identity information of the target account and the identity information of the account to be accessed.

10. The method according to claim 1 or 6, characterized in that, When both the target account and the account to be accessed belong to the target organization, verifying the relationship between the target account and the account to be accessed to obtain the second verification result includes: Obtain the first data access rule corresponding to the target organization; the first data access rule is used to represent the data access permissions between different organizational identities in the target organization. Based on the first data access rule, determine the second verification result according to the organizational identities of the target account and the account to be accessed in the target organization respectively.

11. The method according to claim 1 or 6, characterized in that, When the target account belongs to the first organization and the account to be accessed belongs to the second organization, verifying the relationship between the target account and the account to be accessed to obtain the second verification result includes: Obtain the organizational relationship between the first organization and the second organization, and the second data access rule corresponding to the organizational relationship. Based on the second data access rule, determine the second verification result.

12. An authority verification device, characterized in that, The device includes: A ticket generation module, which is used to verify the identity of the target account and the relationship between the target account and the account to be accessed, and generate a verification ticket for the target account according to the verification result. A sending module, which is used to send the verification ticket to the target account. A receiving module, which is used to receive the data access request sent by the target account; the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and the verification ticket is included in the data access request. A permission verification module, which is used to determine whether the target account has the permission to access the data of the account to be accessed according to the verification ticket in the data access request. The ticket generation module includes: A main ticket generation sub-module, which is used to verify the login identity information of the target account to obtain the first verification result; according to the first verification result, generate the main verification ticket of the target account; the main verification ticket is used to represent whether the identity of the target account is legal. A slave ticket generation sub-module, which is used to verify the relationship between the target account and the account to be accessed to obtain the second verification result; according to the second verification result, generate the slave verification ticket of the target account; the slave verification ticket is used to represent whether the relationship between the target account and the account to be accessed is a preset relationship.

13. The device according to claim 12, characterized in that, The permission verification module includes: A main ticket verification sub-module, which is used to determine whether the identity of the target account is legal according to the main verification ticket. The slave ticket verification sub-module is used to determine whether the relationship between the target account and the to-be-accessed account is the preset relationship according to the slave verification ticket when it is determined that the identity of the target account is legal; when it is determined that the relationship between the target account and the to-be-accessed account is the preset relationship, it is determined that the target account has the permission to access the data of the to-be-accessed account.

14. The device according to claim 13, wherein The main ticket generation sub-module is specifically used for: encrypting the identity information of the target account with the first encryption key to obtain the first encrypted data; generating the main verification ticket according to the first verification result, the first encrypted data, and the hash value signature of the first encrypted data; The slave ticket generation sub-module is specifically used for: determining the second encryption key according to the first encryption key; encrypting the relationship type between the target account and the to-be-accessed account, and the identity information of the to-be-accessed account with the second encryption key to obtain the second encrypted data; generating the slave verification ticket according to the second verification result, the second encrypted data, and the hash value signature of the second encrypted data.

15. The device according to claim 14, characterized in that, The main ticket verification sub-module is specifically used for: verifying the hash value signature in the main verification ticket; after the verification passes, decrypting the first encrypted data in the main verification ticket with the first decryption key symmetric to the first encryption key to obtain the identity information of the target account; determining whether the identity of the target account is legal according to the type of the main verification ticket; The slave ticket verification sub-module is specifically used for: when it is determined that the identity of the target account is legal, verifying the hash value signature in the slave verification ticket; after the verification passes, determining the second decryption key according to the first decryption key, and decrypting the second encrypted data in the slave verification ticket with the second decryption key to obtain the relationship between the target account and the to-be-accessed account, and the identity information of the to-be-accessed account; determining whether the target account has the permission to access the data of the to-be-accessed account according to the type of the slave verification ticket and the identity information of the to-be-accessed account in the second encrypted data.

16. The device according to claim 12 or 14, characterized in that The slave ticket generation sub-module is specifically used for: determining multiple to-be-accessed accounts having the same relationship type as the target account; for each to-be-accessed account, determining the second verification result corresponding to the to-be-accessed account according to the relationship between the target account and the to-be-accessed account; generating the slave verification ticket according to the second verification results corresponding to the multiple to-be-accessed accounts respectively.

17. The device according to claim 12, wherein The ticket generation module further includes: a target ticket generation sub-module, which is used to generate a target verification ticket of the target account according to the first verification result and the second verification result; the target verification ticket is used to represent whether the identity of the target account is legal, and whether the relationship between the target account and the to-be-accessed account is the preset relationship.

18. The device according to claim 17, characterized in that, The permission verification module includes: The target bill verification sub-module is used to determine whether the identity of the target account is legal and whether the relationship between the target account and the account to be accessed is the preset relationship according to the target verification bill; in the case where it is determined that the identity of the target account is legal and the relationship between the target account and the account to be accessed is the preset relationship, it is determined that the target account has the right to access the data of the account to be accessed.

19. The device according to claim 12 or 17, characterized in that Specifically, the main bill generation sub-module or the target bill generation sub-module is used for: When detecting the login of the target account, verifying the identity of the target account according to the account name and password input when logging in to the target account to obtain the first verification result; Or, when detecting the login of the target account, verifying the identity of the target account according to the contact information and verification code input when logging in to the target account to obtain the first verification result.

20. The device according to claim 12 or 17, characterized in that, Specifically, the slave bill generation sub-module or the target bill generation sub-module is used for: According to the relationship type between the target account and the account to be accessed, calling the legal relationship library corresponding to the relationship type; the legal relationship library is used to store the identity information of accounts that meet the relationship type and have a legal relationship with each other; Based on the legal relationship library, determining the second verification result according to the identity information of the target account and the identity information of the account to be accessed.

21. The device according to claim 12 or 17, characterized in that, In the case where both the target account and the account to be accessed belong to the target organization, specifically, the slave bill generation sub-module or the target bill generation sub-module is used for: Obtaining the first data access rule corresponding to the target organization; the first data access rule is used to represent the data access permissions between different organizational identities in the target organization; Based on the first data access rule, determining the second verification result according to the organizational identities of the target account and the account to be accessed in the target organization.

22. The device according to claim 12 or 17, characterized in that, In the case where the target account belongs to the first organization and the account to be accessed belongs to the second organization, specifically, the slave bill generation sub-module or the target bill generation sub-module is used for: Obtaining the organizational relationship between the first organization and the second organization and the second data access rule corresponding to the organizational relationship; Based on the second data access rule, determining the second verification result.

23. A distributed network system, characterized in that, The system includes: a bill server and a data storage server; The bill server is used to verify the identity of the target account and the relationship between the target account and the account to be accessed, and generate a verification bill for the target account according to the verification result; The bill server is further used to send the verification bill to the target account; The data storage server is used to receive the data access request sent by the target account; the data access request is generated in response to an operation of accessing the data of the account to be accessed triggered by the target account, and the data access request includes the verification bill; The data storage server is further used to determine whether the target account has the right to access the data of the account to be accessed according to the verification bill in the data access request; Among them, verifying the identity of the target account and the relationship between the target account and the account to be accessed, and generating a verification ticket for the target account according to the verification result includes: Verifying the login identity information of the target account to obtain a first verification result; Generating a main verification ticket for the target account according to the first verification result; the main verification ticket is used to represent whether the identity of the target account is legal; Verifying the relationship between the target account and the account to be accessed to obtain a second verification result; Generating a secondary verification ticket for the target account according to the second verification result; the secondary verification ticket is used to represent whether the relationship between the target account and the account to be accessed is a preset relationship.

24. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, and the computer program is used to execute the permission verification method according to any one of claims 1 to 11.

25. A computer program product, characterized in that, The computer program product includes instructions, and when the instructions run on a computer device, the computer device is caused to execute the permission verification method according to any one of claims 1 to 11.

Images