A method for generating authorization file, calling method and device

Abstract

The embodiment of the present invention provides a method for generating an authorization file, a calling method and a device, the method comprising, for any server in a distributed system, determining each calling path and each called path of the server according to the calling relationship between the servers, obtaining the calling public key reported by each server, for any server, determining the calling public key corresponding to each calling path of the server from the calling public key reported by each server, and generating the authorization file of the server according to each calling path of the server and the corresponding calling public key, the called path of the server and the corresponding calling public key. Since the authorization file of each server is generated based on the calling relationship between the servers, the authorization file can be well applied to the cross-system call of the distributed system (such as the blockchain system), so that the permission identification and calling restriction between the cross-system (cross-chain) can be realized, and it can help to improve the stability of the authorization system of the distributed system.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of financial technology (Fintech), and in particular to a method for generating an authorization file, a calling method, and a device. Background Art

[0002] With the development of computer technology, more and more technologies (blockchain, data, distributed) are applied in the financial field. The traditional financial industry is gradually transforming into financial technology. However, due to the security and real-time requirements of the financial industry, higher requirements are also placed on technology.

[0003] At present, authorization policy files are mainly generated for single machines (single nodes) and rely on the resources of single machines (single nodes) and combined with user needs. For example, if a function of a single machine (single node) is authorized, any user accessing the function is subject to the same authorization restrictions. However, since this processing method relies on the local authorization policy file or local computer resources of a single machine (single node), and the local authorization policy file only defines, describes and restricts the computer resources of the local machine, it is unable to cope with the complex cross-system (cross-chain) calls of distributed systems, resulting in the inability to effectively solve problems such as cross-system permission identification and call restrictions. In addition, the function implementation of a distributed system (such as a blockchain system, etc.) is a call chain. If a single node on the call chain is authorized, the authorization restrictions on the single node can be lifted after the single node is cracked, resulting in a decrease in the stability of the distributed system.

[0004] In summary, there is an urgent need for a method to generate authorization files and a calling method to achieve cross-system (cross-chain) permission identification and call restrictions, and to improve the stability of the authorization system of distributed systems. Summary of the invention

[0005] The embodiments of the present invention provide a method for generating an authorization file and a calling method to implement cross-system (cross-chain) permission identification and call restriction, and can improve the stability of the authorization system of the distributed system.

[0006] In a first aspect, an embodiment of the present invention provides a method for generating an authorization file, comprising:

[0007] For any server in the distributed system, each calling path and each called path of the server are determined according to the calling relationship between the servers; the calling path is used to indicate the path that the server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the server;

[0008] Obtaining the calling public key reported by each server; the calling public key is a public key generated by each server for each caller according to its own called path; the calling public key serves as the calling basis when the caller calls the server;

[0009] For any server, determine the calling public key corresponding to each calling path of the server from the calling public keys reported by each server;

[0010] An authorization file of the server is generated according to each calling path of the server and the corresponding calling public key, and the called path of the server and the corresponding calling public key.

[0011] In the above technical scheme, for any server (any node) in a distributed system (such as a blockchain system), according to the calling relationship between the servers, the calling paths and the called paths of the server are determined, and the calling public keys reported by the servers are obtained. For any server, the calling public keys corresponding to the calling paths of the server are determined from the calling public keys reported by the servers, and the authorization files of the server are generated according to the calling paths of the server and the corresponding calling public keys, the called paths of the server and the corresponding calling public keys. Since the authorization files of each server are generated based on the calling relationship between the servers (each node) in the distributed system (such as a blockchain system), the characteristics of the distributed system can be fully considered, so that the authorization files can be well applied to the cross-system (cross-chain) calls of the distributed system, so that the cross-system (cross-chain) authority identification and call restrictions can be realized, and the calling server corresponding to the call request received by the called server can be timely and accurately identified, and the fine-grained function restrictions of each server can be realized, so as to solve the problem that the local authorization policy files in the prior art only define, describe and restrict the computer resources of the local machine, resulting in the inability to cope with the complex cross-system calls of the distributed system. In addition, since the authorization file generated by this method allows the server to perform both active restrictions (calling path and corresponding calling public key) and passive restrictions (called path and corresponding calling public key), dual restrictions on the authorization file can be achieved, which can help improve the stability of the authorization system of the distributed system.

[0012] Optionally, generating the authorization file of the server according to each calling path of the server and the corresponding calling public key, the called path of the server and the corresponding calling public key, includes:

[0013] According to any calling path of the server, determine each first authorization item for the server to call the target server on the calling path; wherein each first authorization item corresponds to the calling public key of the calling path;

[0014] According to any called path of the server, determine each second authorization item called when the server is used as a target server on the called path; wherein each second authorization item corresponds to a calling public key of the called path;

[0015] Generate the calling information in the authorization file according to each first authorization item of each calling path of the server and the corresponding calling public key;

[0016] The called information in the authorization file is generated according to each second authorization item of each called path of the server and the corresponding calling public key.

[0017] In the above technical solution, the calling information in the authorization file is generated according to the first authorization items and the corresponding calling public keys of each calling path of the server, and the called information in the authorization file is generated according to the second authorization items and the corresponding calling public keys of each called path of the server. In this way, the authorization file of the server can be accurately generated, and the authorization file can be applied to the cross-system call of the distributed system. In addition, the authorization file allows the server to perform active restrictions (calling path and corresponding calling public key) and passive restrictions (called path and corresponding calling public key). Therefore, the dual restrictions of the authorization file can be achieved, which can help improve the stability of the authorization system of the distributed system.

[0018] Optionally, after generating the called information in the authorization file, the method further includes:

[0019] The authorization information in the authorization file is generated according to each first authorization item of each calling path of the server and each second authorization item of each called path of the server; the authorization information includes the authorization rights corresponding to each authorization item.

[0020] In the above technical solution, the authorization information in the authorization file can be generated timely and accurately according to the first authorization items of each calling path of the server and the second authorization items of each called path of the server. Moreover, the authorization information is used to determine whether the server has the functional authority to call the target server, and to determine whether the server that initiates the call request to the server has the functional authority to call the server.

[0021] Optionally, after generating the authorization information in the authorization file, the method further includes:

[0022] For the authorization permission of at least one authorization item, an authorization policy of the authorization item is generated.

[0023] In the above technical solution, by generating an authorization policy for the authorization item, support can be provided for subsequently determining the specific authorization function of the server based on the authorization policy.

[0024] Optionally, after generating the authorization file of the server, the method further includes:

[0025] For any server, receiving an authorization file acquisition request sent by the server;

[0026] Obtain any calling public key generated by the server for the caller;

[0027] Encrypting the authorization file of the server using the calling public key;

[0028] The encrypted authorization file is sent to the server.

[0029] In the above technical solution, the authorization file of the server is encrypted by using any calling public key generated by the caller, so that the privacy and security of the authorization file can be ensured.

[0030] In a second aspect, an embodiment of the present invention provides a calling method, including:

[0031] The first server receives a first call request from the second server;

[0032] If the first server determines that the calling public key corresponding to the called path in the locally stored authorization file includes the calling public key in the first calling request, the calling request is executed; the authorization file includes each calling path and the corresponding calling public key of the first server and each called path and the corresponding calling public key of the first server; wherein the calling path is used to indicate the path that the first server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the first server; the calling public key is a public key generated by each server for each caller according to its own called path.

[0033] In the above technical solution, by using the calling public key in the first calling request, it is possible to timely and accurately identify whether the second server has the authorization authority to call the first server. In this way, the authorization file can be well applied to the cross-system calling of the distributed system, so that the cross-system authority identification and calling restriction can be realized, and the problem that the local authorization policy file in the prior art only defines, describes and restricts the computer resources of the local computer, resulting in the inability to cope with the complex cross-system calling of the distributed system, can be solved.

[0034] Optionally, the method further comprises:

[0035] The first server determines whether it has the authorization authority to call the authorization item of the third server from the authorization information of the authorization file; the authorization information includes the authorization authority corresponding to each authorization item, wherein each authorization item includes each first authorization item of each calling path of the first server and each second authorization item of each called path of the first server;

[0036] After determining that the first server has the authorization authority, the first server obtains the calling public key of the authorization item from the calling information of the authorization file; the calling information is generated according to each first authorization item of each calling path of the first server and the corresponding calling public key;

[0037] The first server sends a second calling request to the third server; the second calling request includes a calling public key for calling the authorization item.

[0038] In the above technical solution, through the authorization information based on the authorization file, it is possible to timely and effectively determine whether it has the authorization authority to call the authorization item of the third server. After determining that it has the authorization authority, the calling public key of the authorization item is obtained from the calling information of the authorization file, so that the third server can verify the identity information of the first server based on the calling public key, thereby ensuring the privacy and security of the server's authorized function call.

[0039] In a third aspect, an embodiment of the present invention provides a device for generating an authorization file, including:

[0040] A determination unit, for determining, for any server in the distributed system, each calling path and each called path of the server according to the calling relationship between the servers; the calling path is used to indicate the path that the server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the server;

[0041] The first processing unit is used to obtain the calling public key reported by each server; the calling public key is the public key generated by each server for each caller according to its own called path; the calling public key serves as the calling basis when the caller calls the server; for any server, the calling public key corresponding to each calling path of the server is determined from the calling public keys reported by each server; according to each calling path of the server and the corresponding calling public key, the called path of the server and the corresponding calling public key, the authorization file of the server is generated.

[0042] Optionally, the first processing unit is specifically configured to:

[0043] According to any calling path of the server, determine each first authorization item for the server to call the target server on the calling path; wherein each first authorization item corresponds to the calling public key of the calling path;

[0044] According to any called path of the server, determine each second authorization item called when the server is used as a target server on the called path; wherein each second authorization item corresponds to a calling public key of the called path;

[0045] Generate the calling information in the authorization file according to each first authorization item of each calling path of the server and the corresponding calling public key;

[0046] The called information in the authorization file is generated according to each second authorization item of each called path of the server and the corresponding calling public key.

[0047] Optionally, the first processing unit is further configured to:

[0048] After generating the called information in the authorization file, the authorization information in the authorization file is generated according to the first authorization items of each calling path of the server and the second authorization items of each called path of the server; the authorization information includes the authorization rights corresponding to each authorization item.

[0049] Optionally, the first processing unit is further configured to:

[0050] After the authorization information in the authorization file is generated, an authorization policy for the authorization item is generated for the authorization authority of at least one authorization item.

[0051] Optionally, the first processing unit is further configured to:

[0052] After generating the authorization file of the server, for any server, receiving an authorization file acquisition request sent by the server;

[0053] Obtain any calling public key generated by the server for the caller;

[0054] Encrypting the authorization file of the server using the calling public key;

[0055] The encrypted authorization file is sent to the server.

[0056] In a fourth aspect, an embodiment of the present invention provides a calling device, including:

[0057] A receiving unit, configured to receive a first call request from a second server;

[0058] The second processing unit is used to execute the calling request if it is determined that the calling public key corresponding to the called path in the locally stored authorization file includes the calling public key in the first calling request; the authorization file includes each calling path of the first server and the corresponding calling public key and each called path of the first server and the corresponding calling public key; wherein the calling path is used to indicate the path that the first server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the first server; the calling public key is a public key generated by each server for each caller according to its own called path.

[0059] Optionally, the second processing unit is further used for:

[0060] Determine from the authorization information of the authorization file whether the authorization authority for calling the authorization item of the third server is available; the authorization information includes the authorization authority corresponding to each authorization item, wherein each authorization item includes each first authorization item of each calling path of the first server and each second authorization item of each called path of the first server;

[0061] After determining that the authorization authority exists, obtaining a calling public key of the authorization item from calling information of the authorization file; the calling information is generated according to each first authorization item of each calling path of the first server and the corresponding calling public key;

[0062] A second calling request is sent to the third server; the second calling request includes a calling public key for calling the authorization item.

[0063] In a fifth aspect, an embodiment of the present invention provides a computing device, comprising at least one processor and at least one memory, wherein the memory stores a computer program, and when the program is executed by the processor, the processor executes any method for generating an authorization file as described in the first aspect or any calling method as described in the second aspect.

[0064] In a sixth aspect, an embodiment of the present invention provides a computer-readable storage medium storing a computer program executable by a computing device, wherein when the program is run on the computing device, the computing device executes any method for generating an authorization file as described in the first aspect or any calling method as described in the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0066] Figure 1 A schematic diagram of a system architecture provided for an embodiment of the present invention;

[0067] Figure 2 A flowchart of a method for generating an authorization file provided by an embodiment of the present invention;

[0068] Figure 3 A schematic diagram of the calling relationship between servers in a distributed system X provided in an embodiment of the present invention;

[0069] Figure 4 A schematic diagram of a process of encoding based on a calling relationship between servers provided in an embodiment of the present invention;

[0070] Figure 5 A schematic diagram of the called relationship coding of each server in a distributed system X provided by an embodiment of the present invention;

[0071] Figure 6 A schematic diagram of the calling relationship coding of each server in a distributed system X provided by an embodiment of the present invention;

[0072] Figure 7 A schematic diagram of the structure of a device for generating an authorization file provided by an embodiment of the present invention;

[0073] Figure 8 A schematic diagram of the structure of a calling device provided by an embodiment of the present invention;

[0074] Fig. 9 A schematic diagram of the structure of a computing device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0075] In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0076] The following is a brief introduction to the design ideas of the embodiments of the present invention:

[0077] In the prior art, the authorization policy file is mainly for a single machine, relying on the resources of a single machine (single node) and generated in combination with the needs of users. For example, if a function of a single machine (single node) is authorized and restricted, any user accessing the function is subject to the same authorization restriction. However, since this processing method relies on the local authorization policy file or local computer resources of a single machine (single node), and the local authorization policy file only defines, describes and restricts the computer resources of the local machine, it is unable to cope with the complex cross-system (cross-chain) calls of distributed systems (such as blockchain systems), resulting in the inability to effectively solve the problems of cross-system permission identification and call restrictions. In addition, the function implementation of a distributed system (such as a blockchain system) is a call chain, and the robustness of the method of authorizing and restricting a single node on the call chain is limited. For example, servers A and B can both call server C, and the maximum authorized throughput of a certain function of server A is 1000TPS, and the maximum authorized throughput of server B is 2000TPS. For calls to server A or server B, the maximum authorized throughput of server C cannot be generally limited, because if server C generally limits the maximum authorized throughput, it will not be able to meet the call requirements of server A or server B for a certain function authorization, and it is also impossible to distinguish whether the call received by server C is from server A or server B. Furthermore, the authorization file generation of the existing distributed system does not combine the call relationship of each server. If any server is cracked, the stability of the distributed system will be reduced. However, if all call links of the entire distributed system are restricted, the robustness of the system will be greatly enhanced. Even if server A is cracked alone, the authorization restriction on server A cannot be lifted, because server C also participates in the authorization restriction.

[0078] Based on this, an embodiment of the present invention provides a method, a calling method and a device for generating an authorization file. In an embodiment of the present invention, for any server (any node) in a distributed system (such as a blockchain system), the calling paths and the called paths of the server are determined according to the calling relationship between the servers, and the calling public keys reported by each server are obtained. For any server, the calling public keys corresponding to the calling paths of the server are determined from the calling public keys reported by each server, and the authorization file of the server is generated according to the calling paths of the server and the corresponding calling public keys, the called paths of the server and the corresponding calling public keys. Since the authorization files of each server are generated based on the calling relationship between each server (node) in a distributed system (such as a blockchain system), the characteristics of the distributed system can be fully considered so that the authorization files can be well applied to the cross-system (cross-chain) calls of the distributed system, thereby realizing the cross-system (cross-chain) permission identification and call restrictions, and timely and accurately identifying the calling server corresponding to the call request received by the called server, and realizing the fine-grained function restrictions of each server, thereby solving the problem that the local authorization policy file in the prior art only defines, describes and restricts the computer resources of the local machine, resulting in the inability to cope with the complex cross-system calls of the distributed system. In addition, since the authorization file generated by this method allows the server to perform active restrictions (call path and corresponding call public key) and passive restrictions (called path and corresponding call public key), the dual restrictions of the authorization file can be realized, which can help improve the stability of the authorization system of the distributed system.

[0079] In order to facilitate understanding of the embodiments of the present invention, first Figure 1 The system architecture shown in FIG. 1 is used as an example to illustrate the system architecture applicable to the embodiment of the present invention. Figure 1 As shown, the system architecture may be a server 100 , including a processor 110 , a communication interface 120 , and a memory 130 .

[0080] The communication interface 120 is used to communicate with the terminal device, send and receive information transmitted by the terminal device, and realize communication.

[0081] The processor 110 is the control center of the server 100, and uses various interfaces and lines to connect various parts of the entire server 100, and executes various functions of the server 100 and processes data by running or executing software programs and / or modules stored in the memory 130, and calling data stored in the memory 130. Optionally, the processor 110 may include one or more processing units.

[0082] The memory 130 can be used to store software programs and modules. The processor 110 executes various functional applications and data processing by running the software programs and modules stored in the memory 130. The memory 130 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function, etc.; the data storage area can store data created according to business processing, etc. In addition, the memory 130 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0083] It should be noted that the above Figure 1 The structure shown is only an example and is not limited to this embodiment of the present invention.

[0084] Based on the above description, Figure 2 The process of a method for generating an authorization file provided by an embodiment of the present invention is exemplarily shown, and the process can be executed by a device for generating an authorization file.

[0085] like Figure 2 As shown in the figure, the process specifically includes:

[0086] Step 201, for any server in the distributed system, according to the calling relationship between the servers, determine the calling paths and the called paths of the server.

[0087] Step 202: Obtain the calling public key reported by each server.

[0088] Step 203: for any server, determine the calling public key corresponding to each calling path of the server from the calling public keys reported by the servers.

[0089] Step 204: Generate an authorization file for the server according to each calling path of the server and the corresponding calling public key, and the called path of the server and the corresponding calling public key.

[0090] In the above step 201, for any server (any node) in a distributed system (such as a blockchain system), each calling path and each called path of the server (node) are determined. That is, according to the calling relationship between each server (each node), each server is traversed and encoded according to the preset encoding rules, and each calling path and each called path of each server can be obtained. Among them, the calling path is used to indicate the path that the server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the server.

[0091] In the above steps 202 and 203, the calling public key reported by each server is obtained, and for any server, the calling public key corresponding to each calling path of the server is determined from the calling public key reported by each server. That is, for any server, according to the calling path of the server, the calling public key corresponding to the calling path of the server is queried from the calling public keys reported by each server, and the calling public key corresponding to the calling path of the server is allocated to the server. Among them, the calling public key is the public key generated by each server for each caller according to its own called path; the calling public key serves as the calling basis when the caller calls the server.

[0092] In the above step 204, the authorization file of the server is generated according to each calling path of the server and the corresponding calling public key, the called path of the server and the corresponding calling public key. That is, according to any calling path of the server, the first authorization items of the server calling the target server on the calling path are determined, and according to any called path of the server, the second authorization items called when the server is used as the target server on the called path are determined. Then, according to each first authorization item of each calling path of the server and the corresponding calling public key, the calling information in the authorization file is generated, and according to each second authorization item of each called path of the server and the corresponding calling public key, the called information in the authorization file is generated. In this way, the authorization file of the server can be accurately generated, and the cross-system call of the authorization file can be applied to the distributed system. In addition, the authorization file allows the server to perform active restrictions (calling path and corresponding calling public key) and also allows the server to perform passive restrictions (called path and corresponding calling public key), so the dual restrictions of the authorization file can be realized, which can help improve the stability of the authorization system of the distributed system. Among them, each first authorization item corresponds to the calling public key of the calling path; each second authorization item corresponds to the calling public key of the called path.

[0093] In addition, after the called information in the authorization file is generated, the authorization information in the authorization file can be generated timely and accurately according to the first authorization items of each calling path of the server and the second authorization items of each called path of the server. Moreover, the authorization information is used to determine whether the server has the functional authority to call the target server, and to determine whether the server that initiates a call request to the server has the functional authority to call the server. Afterwards, an authorization policy for the authorization item is generated for the authorization authority of at least one authorization item, which can provide support for the subsequent determination of the specific authorized functions of the server based on the authorization policy. That is, for each authorization item's authorization authority, a corresponding authorization policy (i.e., specific authorized functions, such as which specific functions are called or restrictions on the frequency of calls, etc.) can be set for the authorization item. Among them, the authorization information includes the authorization authority corresponding to each authorization item.

[0094] In addition, after the server authorization file is generated, for any server, the authorization file acquisition request sent by the server is received, and any call public key generated by the server for the caller is obtained. The server authorization file is then encrypted using the call public key, and the encrypted authorization file is sent to the server, so that the privacy security of the authorization file can be ensured.

[0095] It should be noted that after the authorization files of each server are generated and sent to the corresponding servers, if any server wants to call a certain server, it can send a call request to a certain server based on the call public key, so that a certain server can verify the call public key in the call request and determine whether the server sending the call request has the authority to call a certain server. Specifically, the first server receives the first call request of the second server. If it is determined that the call public key corresponding to the called path in the locally stored authorization file includes the call public key in the first call request, the call request is executed. Based on the call public key in the first call request, it is possible to timely and accurately identify whether the second server has the authorization authority to call the first server. In this way, it is possible to implement the application of authorization files to cross-system calls of distributed systems, thereby solving the problem in the prior art that local authorization policy files only define, describe and restrict the computer resources of the local machine, resulting in the inability to cope with complex cross-system calls of distributed systems. Among them, the authorization file includes each calling path of the first server and the corresponding calling public key and each called path of the first server and the corresponding calling public key; the calling path is used to indicate the path that the first server, as the caller, takes when calling the target server; the called path is used to indicate the path that the caller takes when calling the first server; the calling public key is the public key generated by each server for each caller according to its own called path.

[0096] Alternatively, the first server determines from the authorization information of the authorization file whether it has the authorization authority to call the authorization item of the third server, and after determining that it has the authorization authority, obtains the calling public key of the authorization item from the calling information of the authorization file. Then sends a second calling request to the third server. Based on the authorization information of the authorization file, it can be timely and effectively judged whether it has the authorization authority to call the authorization item of the third server. After determining that it has the authorization authority, the calling public key of the authorization item is obtained from the calling information of the authorization file, so that the third server verifies the identity information of the first server based on the calling public key, so that the privacy security of the authorized function call of the server can be ensured. Among them, the authorization information includes the authorization authority corresponding to each authorization item, and each authorization item includes each first authorization item of each calling path of the first server and each second authorization item of each called path of the first server; the calling information is generated according to each first authorization item of each calling path of the first server and the corresponding calling public key; the second calling request includes the calling public key for calling the authorization item.

[0097] In view of this, the implementation process of generating an authorization file in an embodiment of the present invention is described in detail below.

[0098] Step 1: Define the format of the authorization file.

[0099] The design of the authorization file (also called authorization policy file) for distributed commercial software in the embodiment of the present invention is quite different from that of the ordinary stand-alone version. Generally, the authorization file of the ordinary stand-alone version needs to reflect the authorization object (generally the MAC address of the machine or other unique identifier that can identify the physical server) and the authorization item and the restrictions of the item. In addition to reflecting these two items of the ordinary stand-alone version, the authorization file of the distributed commercial software also needs to reflect the calling relationship between the servers within the distributed system. Among them, the calling relationship includes two situations: calling and being called. For calling, the authorization file needs to support the server to perform stand-alone policy verification on itself; for being called, the authorization file needs to provide identity authenticity verification of the caller and verification of the caller's policy restrictions.

[0100] Based on this, the key information contained in the authorization file in the embodiment of the present invention is used for policy verification of a distributed system (such as a blockchain system). The key information may be:

[0101] 1. Authorization object (bound to the server's identity to determine the uniqueness of the authorization object).

[0102] 2. Authorized projects and project restrictions (including calling and called projects).

[0103] 3. Call the identifier and the corresponding public key.

[0104] 4. The called identifier and the corresponding public key.

[0105] In summary, the format of the authorization file in the embodiment of the present invention may be as shown in Table 1.

[0106] Table 1

[0107]

[0108] It should be noted that in Table 1, the first 16 bits represent the length of the authorization list; bits 17 to 32 represent the length of the call list; bits 33 to 48 represent the length of the called list; bits 49 to 64 are reserved fields. The units of the above lengths are all bytes (8 bits).

[0109] The authorization list lists all functions of this server (this node) and their restrictions. For a single list element, it consists of three parts: function permission number, separator, and restriction level. The separator is two 8-bit words with all 1s, and the other bits are all 0s. The separator between elements is two 8-bit words with all 1s.

[0110] The call list lists all the paths for this server (this node) to call other servers (other nodes). For a single list element, it consists of three parts: service identifier, separator, and public key. The service identifier is a number of 8-bit words used to identify the call path of the target server; the separator is two 8-bit words with all 1s; the public key is the authentication identifier for this server to call other servers on a specific call chain, with a length of 64 bits. The separator between elements is two 8-bit words with all 1s.

[0111] The called list lists all the paths of this server (this node) being called by other servers (other nodes). For a single list element, it consists of three parts: service identifier, separator, and public key. The service identifier is a number of 8-bit words used to identify the calling path of calling this server; the separator is two 8-bit words with all 1s; the public key is the authentication identifier of other servers calling this server on a specific calling chain, with a length of 64 bits. The separator between elements is two 8-bit words with all 1s.

[0112] It should be noted that the service identifier in the calling list can be considered as the calling code of this server (that is, the path for this server to call other servers); the service identifier in the called list can be considered as the called code of this server (that is, the path for this server to be called by other servers).

[0113] Step 2: Generate an authorization file.

[0114] For example, assume that a distributed system (such as a blockchain system) is X, and any server in X is ServiceI (node ​​I). ServiceI maintains a call code set Call_I; at the same time, it maintains a called code set beCall_I.

[0115] For ServiceI, the set of all services it calls is called the out-degree of ServiceI, and the out-degree of ServiceI is set to Out_I. The out-degree Out_I is numbered starting from 0 (8-bit word all 0).

[0116] Assume that there are 6 servers in the distributed system X, namely Service0 to Service6. The calling relationship between the servers in the distributed system X can be as follows: Figure 3 Based on Figure 3 It can be seen that since there is no called set in the calling source server Service0, the called code set beCall_0 of Service0 = {0}. At the same time, the calling set Call_0 of Service0 can be initialized to {0}. In addition, according to Figure 3 The calling relationship shown in the figure is traversed and encoded for each server, and the calling relationship encoding and the called relationship encoding of the distributed system X can be obtained. Figure 4 , Figure 4 A schematic diagram of a process for encoding based on the calling relationship between servers provided in an embodiment of the present invention. The process is specifically as follows:

[0117] Step 401, let x=0.

[0118] Step 402, take out the xth element from Out_I and record it as ServiceX.

[0119] Step 403, ++x.

[0120] Step 404, determine whether ServiceX is empty. If so, the process ends; if not, execute step 405.

[0121] Step 405, set y=0.

[0122] Step 406, take out the yth code in beCall_I, recorded as numY.

[0123] Step 407, ++y.

[0124] Step 408, determine whether numY is empty. If so, execute step 902; if not, execute step 409.

[0125] Step 409, obtain the new code numNew=(numY<<8)+x.

[0126] Shift the position of numY to the left by 8 bits, and concatenate the shifted numY with x to generate a new code numNew.

[0127] Step 410, write numNew into beCall_Y.

[0128] Write numNew into beCall_Y, which is the called code set of ServiceI.

[0129] Step 411, write numNew into Call_I.

[0130] numNew is written into Call_I, and Call_I is used as the calling code set of ServiceI. At the same time, Call_I is used as the called code of the target server that has a calling relationship with ServiceI and is called by ServiceI.

[0131] Based on this, for each server in the distributed system X, traverse and encode according to the above process, and you can get the following Figure 5 The schematic diagram of the called relationship encoding of each server in the distributed system X shown in FIG. 1 is shown in FIG. 2 ; at the same time, the following can also be obtained: Figure 6 The schematic diagram of the calling relationship encoding of each server in the distributed system X shown is shown.

[0132] It should be noted that, in the embodiment of the present invention, an authorization machine GrantX is deployed in the distributed system X. All authorization files will be generated and distributed by the authorization machine.

[0133] When ServiceI starts, it will generate a private key PrivateKeyI and save it. Then ServiceI will generate a corresponding public key set PublicKeysI based on its own called code set beCall_I. Finally, the public key set PublicKeysI is submitted to the authorization machine. After receiving the public key set submitted by ServiceI in the distributed system X, the authorization machine will clearly define the authorization restrictions for each call in accordance with the user payment agreement and write it into the authorization list. At the same time, after receiving the public key set submitted by ServiceI in the distributed system X, the authorization machine will redistribute the public key for Call_I according to the call code set of each server. For example, Figure 3 Take Service2 in the example, Service2 will use its own private key according to Figure 5The called relationship in generates two calling public keys 01 and 001, namely 01-publickey and 001-publickey. Among them, 01-publickey will be assigned to the calling list in the authorization file of Service0; 001-publickey will be assigned to the calling list in the authorization file of Service1. In addition, it should be noted that when Service0 or Service1 tries to call Service2, the corresponding calling public key needs to be matched with the private key of Service2 for authorization verification.

[0134] Correspondingly, Service2 will also obtain the public key in the call list in its own authorization file from the authorization machine in order to authorize calls to other servers. At this point, the key information part of the authorization file of Service2 is generated. Among them, the authorization file of Service2 can be shown in Table 2.

[0135] Table 2

[0136]

[0137]

[0138] Among them, the authorization list contains the functional items that Service2 needs to implement (a total of 6 items, two of which are provided by Service2 and four are provided by the target server called by Service2); the public keys in the call list are the public keys corresponding to the lower-level service functional items that Service2 depends on (i.e., the public keys corresponding to the authorized functional items of the target server). These public keys are generated by other services and assigned to Service2 by the authorization machine. When Service2 calls other servers, it needs to present the public keys in the call list to other called services for verification. The public keys in the called list are the public keys corresponding to the authorized functional items provided by Service2 to the outside world. These public keys are generated by Service2 and provided to the authorization machine for distribution. When other services need to call Service2, they will be required to provide the corresponding public keys to Service2 for verification. For a call, this authorization file allows the calling end to impose restrictions (active restrictions, call list part) and the called end to impose restrictions (passive restrictions, call list part). Such dual restrictions help improve the robustness (stability) of the authorization system of the distributed system.

[0139] It should be noted that in actual application scenarios, each call (whether the main caller or the called party) may correspond to multiple function implementations, that is, it may correspond to multiple authorization items. Figure 3In the calling relationship between the servers in the distributed system X shown, each call corresponds to the implementation of a single function, and the call number is used to represent the authorization item, and the restriction level of the authorization item only distinguishes whether it is accessible.

[0140] In addition, since the authorization file of Service2 records all authorized public keys issued by itself, the correspondence between these public keys and authorized function items can be used to perform more complex authorization verification (such as limiting the frequency of calls, etc.).

[0141] Step 3: Distribute authorization files.

[0142] When ServiceI is started for the first time, it must be verified whether there is an authorization file locally. If not, it is necessary to send an authorization file acquisition request to the authorization machine. After receiving the authorization file acquisition request from ServiceI, the authorization machine randomly selects a public key PublicKeysI from the public key set PublicKeysI submitted by ServiceI, and uses PublicKeysI to encrypt the authorization file of ServiceI, and then sends the encrypted authorization file to ServiceI. Among them, the authorization file of ServiceI can be encrypted using an asymmetric encryption algorithm (such as RSA public key encryption algorithm or elliptic curve encryption algorithm, etc.), which is not limited in the embodiment of the present invention. For example, taking Service2 as an example, when ServiceI is started for the first time, it needs to determine whether there is an authorization file locally. If it exists, it can initiate a call request or receive a call request sent by other servers. If it does not exist, it is necessary to send an authorization file acquisition request to the authorization machine. After receiving the authorization file acquisition request from Service2, the authorization machine randomly selects a public key PublicKeys2 from the public key set PublicKeys2 submitted by Service2, and queries the authorization file of Service2 from the authorization files of each server stored locally based on the identifier of Service2. Then use PublicKeys2 to encrypt the authorization file of Service2 to obtain the encrypted authorization file, and then send the encrypted authorization file to Service2. It should be noted that since the public key set PublicKeysI of ServiceI is generated based on its own private key, the authorization machine randomly selects which PublicKeysI from the public key set PublicKeysI to encrypt the authorization file of ServiceI, and ServiceI can use its own private key to decrypt and obtain the decrypted authorization file.

[0143] After the authorization machine generates the authorization file and distributes it to the corresponding servers, if any server wants to call a server, it can send a call request to the server based on the call public key, so that the server can verify the call public key in the call request and determine whether the server sending the call request has the authority to call the server. Figure 3 Take Service2 in the example, when Service2 wants to call Service5, it needs to generate a call request based on the corresponding call public key in the call list of its own authorization file, and send the call request to Service5. After receiving the call request, Service5 first verifies the call public key in the call request based on the local private key. If the verification is successful, it determines whether the call public key corresponding to the called path in the locally stored authorization file includes the call public key in the call request, and executes the call request after determining that it is included. It should be understood that when the called server executes the call request, it will execute the specific authorization function corresponding to the call public key, and process the call behavior of Service2 accordingly based on the authorization function. Assume that the specific authorization function corresponding to the call public key stipulates that the number of calls within 1 minute exceeds 1000 times, that is, the server that initiates the call request is charged according to the corresponding charging rules. For example, it is stipulated that the number of calls within 1 minute is between 1000 and 2000 times according to standard A, and more than 2000 times are charged according to standard B. For example, if the number of calls to Service5 by Service2 in 1 minute is between 1000 and 2000, Service2 will be charged according to standard A. In addition, Service2 can also view the authorized function restrictions of Service5 in its own authorization file, that is, it can be viewed that if the number of calls to Service5 exceeds 1000 times in 1 minute, Service5 will charge itself. In this way, Service2 can immediately stop calling Service5 when monitoring that the number of calls to Service5 in 1 minute is about to exceed 1000 times, so as to avoid being charged for calling more than 1000 times in 1 minute.

[0144] The above embodiment shows that for any server (any node) in a distributed system (such as a blockchain system), according to the call relationship between each server, the calling paths and each called path of the server are determined, and the calling public key reported by each server is obtained. For any server, the calling public key corresponding to each calling path of the server is determined from the calling public key reported by each server, and the authorization file of the server is generated according to each calling path of the server and the corresponding calling public key, the called path of the server and the corresponding calling public key. Since the authorization file of each server is generated based on the calling relationship between each server (each node) in a distributed system (such as a blockchain system), the characteristics of the distributed system can be fully considered so that the authorization file can be well applied to the cross-system (cross-chain) call of the distributed system, so that the authority identification and call restriction between the cross-system (cross-chain) can be realized, and the calling server corresponding to the call request received by the called server can be timely and accurately identified, and the fine-grained function restriction of each server can be realized, so as to solve the problem that the local authorization policy file in the prior art only defines, describes and restricts the computer resources of the local machine, resulting in the inability to cope with the complex cross-system call of the distributed system. In addition, since the authorization file generated by this method allows the server to perform both active restrictions (calling path and corresponding calling public key) and passive restrictions (called path and corresponding calling public key), dual restrictions on the authorization file can be achieved, which can help improve the stability of the authorization system of the distributed system.

[0145] Based on the same technical concept, Figure 7 An apparatus for generating an authorization file provided by an embodiment of the present invention is exemplarily shown, and the apparatus can execute the process of the method for generating an authorization file.

[0146] like Figure 7 As shown, the device comprises:

[0147] The determining unit 701 is used to determine, for any server in the distributed system, each calling path and each called path of the server according to the calling relationship between the servers; the calling path is used to indicate the path that the server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the server;

[0148] The first processing unit 702 is used to obtain the calling public key reported by each server; the calling public key is the public key generated by each server for each caller according to its own called path; the calling public key serves as the calling basis when the caller calls the server; for any server, the calling public key corresponding to each calling path of the server is determined from the calling public keys reported by each server; according to each calling path of the server and the corresponding calling public key, the called path of the server and the corresponding calling public key, the authorization file of the server is generated.

[0149] Optionally, the first processing unit 702 is specifically configured to:

[0150] According to any calling path of the server, determine each first authorization item for the server to call the target server on the calling path; wherein each first authorization item corresponds to the calling public key of the calling path;

[0151] According to any called path of the server, determine each second authorization item called when the server is used as a target server on the called path; wherein each second authorization item corresponds to a calling public key of the called path;

[0152] Generate the calling information in the authorization file according to each first authorization item of each calling path of the server and the corresponding calling public key;

[0153] The called information in the authorization file is generated according to each second authorization item of each called path of the server and the corresponding calling public key.

[0154] Optionally, the first processing unit 702 is further configured to:

[0155] After generating the called information in the authorization file, the authorization information in the authorization file is generated according to the first authorization items of each calling path of the server and the second authorization items of each called path of the server; the authorization information includes the authorization rights corresponding to each authorization item.

[0156] Optionally, the first processing unit 702 is further configured to:

[0157] After the authorization information in the authorization file is generated, an authorization policy for the authorization item is generated for the authorization authority of at least one authorization item.

[0158] Optionally, the first processing unit 702 is further configured to:

[0159] After generating the authorization file of the server, for any server, receiving an authorization file acquisition request sent by the server;

[0160] Obtain any calling public key generated by the server for the caller;

[0161] Encrypting the authorization file of the server using the calling public key;

[0162] The encrypted authorization file is sent to the server.

[0163] Based on the same technical concept, Figure 8 A calling device provided by an embodiment of the present invention is exemplarily shown, and the device can execute the process of the calling method.

[0164] like Figure 8 As shown, the device comprises:

[0165] A receiving unit 801 is used to receive a first call request from a second server;

[0166] The second processing unit 802 is used to execute the calling request if it is determined that the calling public key corresponding to the called path in the locally stored authorization file includes the calling public key in the first calling request; the authorization file includes each calling path of the first server and the corresponding calling public key and each called path of the first server and the corresponding calling public key; wherein the calling path is used to indicate the path that the first server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the first server; the calling public key is a public key generated by each server for each caller according to its own called path.

[0167] Optionally, the second processing unit 802 is further configured to:

[0168] Determine from the authorization information of the authorization file whether the authorization authority for calling the authorization item of the third server is available; the authorization information includes the authorization authority corresponding to each authorization item, wherein each authorization item includes each first authorization item of each calling path of the first server and each second authorization item of each called path of the first server;

[0169] After determining that the authorization authority exists, obtaining a calling public key of the authorization item from calling information of the authorization file; the calling information is generated according to each first authorization item of each calling path of the first server and the corresponding calling public key;

[0170] A second calling request is sent to the third server; the second calling request includes a calling public key for calling the authorization item.

[0171] Based on the same technical concept, the embodiment of the present invention also provides a computing device, such as Fig. 9As shown, it includes at least one processor 901 and a memory 902 connected to the at least one processor. The specific connection medium between the processor 901 and the memory 902 is not limited in the embodiment of the present invention. Fig. 9 For example, the processor 901 and the memory 902 are connected via a bus. The bus can be divided into an address bus, a data bus, a control bus, etc.

[0172] In an embodiment of the present invention, the memory 902 stores instructions that can be executed by at least one processor 901. By executing the instructions stored in the memory 902, the at least one processor 901 can execute the steps included in the aforementioned method for generating an authorization file or the calling method.

[0173] Among them, the processor 901 is the control center of the computing device, and can use various interfaces and lines to connect various parts of the computing device, and realize data processing by running or executing instructions stored in the memory 902 and calling data stored in the memory 902. Optionally, the processor 901 may include one or more processing units, and the processor 901 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes the issuance of instructions. It is understandable that the above-mentioned modem processor may not be integrated into the processor 901. In some embodiments, the processor 901 and the memory 902 may be implemented on the same chip, and in some embodiments, they may also be implemented separately on independent chips.

[0174] Processor 901 may be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the method disclosed in the embodiment of generating an authorization file or calling the method based on the authorization file may be directly embodied as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0175] The memory 902 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 902 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 902 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 902 in the embodiment of the present invention can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0176] Based on the same technical concept, an embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program executable by a computing device. When the program runs on the computing device, the computing device executes the above-mentioned method for generating an authorization file or the steps of the calling method.

[0177] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0178] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0179] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0180] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0181] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0182] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of this application and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A method for generating an authorization file, characterized in that: include: For any server in the distributed system, each calling path and each called path of the server are determined according to the calling relationship between the servers; the calling path is used to indicate the path that the server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the server; Get the calling public key reported by each server; The calling public key is a public key generated by each server for each caller according to its own called path; The calling public key is used as the calling basis when the calling party calls the server; For any server, determine the calling public key corresponding to each calling path of the server from the calling public keys reported by each server; Generate an authorization file for the server according to each calling path of the server and the corresponding calling public key, and the called path of the server and the corresponding calling public key; The step of generating the authorization file of the server according to each calling path of the server and the corresponding calling public key, the called path of the server and the corresponding calling public key comprises: According to any calling path of the server, determine each first authorization item for the server to call the target server on the calling path; wherein each first authorization item corresponds to the calling public key of the calling path; According to any called path of the server, determine each second authorization item called when the server is used as a target server on the called path; wherein each second authorization item corresponds to a calling public key of the called path; Generate the calling information in the authorization file according to each first authorization item of each calling path of the server and the corresponding calling public key; The called information in the authorization file is generated according to each second authorization item of each called path of the server and the corresponding calling public key.

2. The method according to claim 1, characterized in that After generating the called information in the authorization file, the method further includes: The authorization information in the authorization file is generated according to each first authorization item of each calling path of the server and each second authorization item of each called path of the server; the authorization information includes the authorization rights corresponding to each authorization item.

3. The method according to claim 2, characterized in that After the authorization information in the authorization file is generated, the method further includes: For the authorization permission of at least one authorization item, an authorization policy of the authorization item is generated.

4. The method according to any one of claims 1 to 3, characterized in that After generating the authorization file of the server, the method further includes: For any server, receiving an authorization file acquisition request sent by the server; Obtain any calling public key generated by the server for the caller; Encrypting the authorization file of the server using the calling public key; The encrypted authorization file is sent to the server.

5. A calling method, characterized in that: include: The first server receives a first call request from the second server; If the first server determines that the calling public key corresponding to the called path in the locally stored authorization file includes the calling public key in the first calling request, the calling request is executed; the authorization file includes each calling path and the corresponding calling public key of the first server and each called path of the first server and the corresponding calling public key; wherein the calling path is used to indicate the path that the first server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the first server; the calling public key is a public key generated by each server for each caller according to its own called path; The first server determines whether it has the authorization authority to call the authorization item of the third server from the authorization information of the authorization file; the authorization information includes the authorization authority corresponding to each authorization item, wherein each authorization item includes each first authorization item of each calling path of the first server and each second authorization item of each called path of the first server; After determining that the first server has the authorization authority, the first server obtains the calling public key of the authorization item from the calling information of the authorization file; the calling information is generated according to each first authorization item of each calling path of the first server and the corresponding calling public key; The first server sends a second calling request to the third server; the second calling request includes a calling public key for calling the authorization item.

6. A device for generating an authorization document, characterized in that: include: A determination unit, for determining, for any server in the distributed system, each calling path and each called path of the server according to the calling relationship between the servers; the calling path is used to indicate the path that the server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the server; A first processing unit is used to obtain a calling public key reported by each server; The calling public key is a public key generated by each server for each caller according to its own called path; The calling public key is used as a basis for the calling party to call the server; for any server, the calling public key corresponding to each calling path of the server is determined from the calling public keys reported by each server; Generate an authorization file for the server according to each calling path of the server and the corresponding calling public key, and the called path of the server and the corresponding calling public key; The first processing unit is specifically used to determine, according to any calling path of the server, each first authorization item for the server to call a target server on the calling path; wherein each first authorization item corresponds to a calling public key of the calling path; according to any called path of the server, determine each second authorization item for the server to call when it is used as a target server on the called path; wherein each second authorization item corresponds to a calling public key of the called path; according to each first authorization item of each calling path of the server and the corresponding calling public key, generate the calling information in the authorization file; according to each second authorization item of each called path of the server and the corresponding calling public key, generate the called information in the authorization file.

7. A calling device, characterized in that: include: A receiving unit, configured to receive a first call request from a second server; The second processing unit is used to execute the calling request if it is determined that the calling public key corresponding to the called path in the locally stored authorization file includes the calling public key in the first calling request; the authorization file includes each calling path of the first server and the corresponding calling public key and each called path of the first server and the corresponding calling public key; wherein the calling path is used to indicate the path that the first server, as the caller, passes through when calling the target server; the called path is used to indicate the path that the caller passes through when calling the first server; the calling public key is a public key generated by each server for each caller according to its own called path; The second processing unit is further used to determine whether the authorization authority to call the authorization item of the third server is present from the authorization information of the authorization file; the authorization information includes the authorization authority corresponding to each authorization item, wherein each authorization item includes each first authorization item of each calling path of the first server and each second authorization item of each called path of the first server; after determining that the authorization authority is present, obtaining the calling public key of the authorization item from the calling information of the authorization file; The calling information is generated according to each first authorization item of each calling path of the first server and the corresponding calling public key; a second calling request is sent to the third server; the second calling request includes the calling public key for calling the authorization item.

8. A computing device, characterized in that The invention comprises at least one processor and at least one memory, wherein the memory stores a computer program, and when the program is executed by the processor, the processor executes the method according to any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that: It stores a computer program executable by a computing device, and when the program is run on the computing device, the computing device executes the method according to any one of claims 1 to 5.

Images