Access control method, device and system

Abstract

The present application provides an access control method, device and system that can perform access control efficiently and flexibly, thereby reducing data leakage. The method includes: an authorization server issues a token to a client device based on an application from the client device, the token including a token description and a first authorization code, the token description including an authorization vector, the authorization vector indicating target information, and the first authorization code being generated based on the token description, target information, and a cryptographic hash function. When the client device sends a request message, it carries the token and target information in the request message. After receiving the request message, the gateway device generates a second authorization code based on the token description, target information, and the cryptographic hash function, and forwards the request message to the data server when the second authorization code is the same as the first authorization code.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communications, and in particular to an access control method, device, and system. Background Art

[0002] With the widespread adoption of the internet, new software applications are constantly emerging, significantly impacting and changing the way people work and live, and increasing their reliance on online information. However, due to factors such as the inherent complexity and widespread accessibility of networks, networks face increasing security threats, and security issues are becoming increasingly prominent.

[0003] Currently, a major security issue is data leakage due to unauthorized access. For example, Figure 1 As shown in the example, in a campus network scenario, legitimate employees within the campus area can access internal data, while malicious employees can unauthorizedly access the data center, leading to data leaks. Furthermore, legitimate users outside the campus area can access public data, while malicious hackers can unauthorizedly access internal data, leading to data leaks. Therefore, proper access control is essential to prevent data leaks caused by unauthorized access. Summary of the Invention

[0004] The present application provides an access control method, device, and system that can efficiently and flexibly perform access control, thereby reducing data leakage.

[0005] In a first aspect, an access control method is provided. The method can be executed by an authorization server, or by a component of the authorization server, such as a processor, chip, or chip system, or by a logic module or software that can implement all or part of the authorization server's functions. Taking the method executed by the authorization server as an example, the method includes: the authorization server receives token application information from a client device for applying for a target token, generates a target token based on the token application information, and then sends the target token to the client device. The target token includes a token description and a first authorization code, the token description includes an authorization vector, the authorization vector indicates target information, and the first authorization code is generated based on the token description, the target information, and a cryptographic hash function.

[0006] Based on this solution, the authorization server issues a token to the client device based on the application of the client device. The token includes a token description and a first authorization code. The token description includes an authorization vector. The authorization vector indicates the target information involved in the calculation of the authorization code, so that the execution point of the access control policy can obtain the information involved in the calculation of the authorization code based on the authorization vector after receiving the request message, and generate a second authorization code. Access control is performed based on whether the first authorization code and the second authorization code are consistent. For example, access is allowed when the second authorization code is consistent with the first authorization code, and access is denied when the second authorization code is inconsistent with the first authorization code, thereby preventing data leakage.

[0007] In conjunction with the first aspect, in certain embodiments of the first aspect, the target information is information to be carried in a request message of the client device. Exemplarily, the request message is used to request establishment of a TCP connection to the target resource; or the request message is used to request access to the target resource.

[0008] Based on this implementation, the information in the request message is used to participate in the calculation of the authorization code. When the token is subsequently verified, it can prevent the use of the target token to send illegal requests. For example, when an illegal user uses the target token to send a request, since the calculation of the authorization code requires the participation of the information in the request message, if they want to pass the token verification, they need to falsify the target information in the request message at the same time. However, falsifying the information in the request message may not be able to complete the illegal request of the illegal user. Therefore, the target token of this application can be used freely within the authorized scope without worrying about theft, which can further improve security performance.

[0009] In combination with the first aspect, in certain embodiments of the first aspect, the authorization vector includes an offset value and length information, the offset value indicates the starting position of the target information, and the length information indicates the length of the target information; or, the authorization vector includes a bit map, and the bit map indicates the field that carries the target information.

[0010] In combination with the first aspect, in certain embodiments of the first aspect, the target information includes at least one of the following: network layer information, transport layer information, authorization request start character, request end character, requester description information, or responder description information corresponding to the target resource, and the target resource is the resource to be accessed by the client device.

[0011] Based on this implementation, the content of the target information can be adjusted as needed, thereby flexibly adjusting the access control granularity and achieving multi-level, refined access control. For example, the target information can include network layer information to achieve network layer access control; or the target information can include network layer, transport layer, and application layer information to achieve URL-level fine-grained control; or the target information can include requester or responder description information to achieve access control based on security level, network type, etc.

[0012] For example, when the requirement information included in the token application information indicates establishing a TCP connection, the target information includes network layer information and transport layer information corresponding to the target resource;

[0013] When the requirement information indicates that the complete request message is not segmented, the target information includes the network layer information, transport layer information, authorization request start character, and request end character corresponding to the target resource;

[0014] When the demand information indicates a complete request message segment, the target information includes first sub-target information corresponding to the start segment of the complete request message, second sub-target information corresponding to the middle segment of the complete request message, and third sub-target information corresponding to the end segment of the complete request message. The first sub-target information includes network layer information, transport layer information, and an authorization request start symbol; the second sub-target information includes network layer information and transport layer information; and the third sub-target information includes network layer information, transport layer information, and a request end symbol.

[0015] In combination with the first aspect, in certain embodiments of the first aspect, the authorization request initiator includes request information and a partial or complete URL prefix of the target resource, and the request information indicates an operation related to the target resource.

[0016] In combination with the first aspect, in certain embodiments of the first aspect, the authorization server generates a target token based on the token application information, including: the authorization server determines the access rights of the requester based on the requester description information in the token application information; and determines the authorization request start character based on the access rights of the requester.

[0017] In combination with the first aspect, in certain embodiments of the first aspect, the network layer information includes a source Internet Protocol IP address and a destination IP address; the transport layer information includes a destination port, or includes a destination port and a source port; the requester description information includes at least one of the following: the requester's identity information, the requester's status information, the requester's group identifier, the requester's security level, or the network type of the network in which the requester is located; the responder description information includes at least one of the following: the responder's group identifier, the responder's security level, or the network type of the network in which the responder is located.

[0018] In combination with the first aspect, in certain embodiments of the first aspect, the token description also includes a validity period and at least one of the following: a check policy, an issuer identifier, a cryptographic suite, or exclusion information; wherein the validity period indicates the validity period of the target token; the check policy indicates whether the requester of the target resource is trusted; the issuer identifier indicates the device that issues the target token; the cryptographic suite indicates relevant information of the cryptographic hash function; and the exclusion information indicates prohibited information.

[0019] Based on the token description of this implementation, the execution point of the access control policy can be further verified according to the validity period, inspection policy, exclusion information, etc., further improving the security performance.

[0020] In combination with the first aspect, in certain embodiments of the first aspect, when a request message is used to request the establishment of a Transmission Control Protocol TCP connection corresponding to a target resource, the information that is prohibited from being carried is a payload; or, when the request message is the starting segment of a complete request message, the information that is prohibited from being carried is a request terminator; or, when the request message is the ending segment of a complete request message, the information that is prohibited from being carried is request information; or, when the request message is the middle segment of a complete request message, the information that is prohibited from being carried is request information and a request terminator; or, when the request message is a complete request message, exclusion information indicates that it is prohibited to carry multiple request information and multiple request terminators.

[0021] In a second aspect, an access control method is provided. The method can be executed by a gateway device, or by a component of the gateway device, such as a processor, chip, or chip system, or by a logic module or software that can implement all or part of the gateway device's functions. Taking the method executed by a gateway device as an example, the method includes: the gateway device receives a request message from a client device including a target token and target information, the target token including a token description and a first authorization code, the token description including an authorization vector, and the authorization vector indicating the target information; thereafter, the gateway device generates a second authorization code based on the token description, the target information, and a keyed hash function; and if the second authorization code is the same as the first authorization code, the gateway device forwards the request message to a data server.

[0022] Based on this scheme, the request message includes a target token and target information. The token includes a token description and a first authorization code. The token description includes an authorization vector. The authorization vector indicates the target information involved in the authorization code calculation. Therefore, after receiving the request message, the gateway device can obtain the information involved in the authorization code calculation (i.e., the target information) based on the authorization vector and generate a second authorization code. Access control is performed based on whether the first authorization code and the second authorization code are consistent. When the second authorization code is consistent with the first authorization code, the request message is forwarded to the data server to prevent data leakage.

[0023] On the other hand, gateway devices do not need to maintain access control policies or access control lists. Compared with existing ACL and firewall solutions, they can be deployed flexibly and reduce deployment and usage costs.

[0024] On the other hand, the gateway device does not need to analyze the application layer semantics of the request message, nor does it need to query access control policies, user information, etc. It can calculate and verify the authorization code in a fool-proof manner, decoupling the storage and computing complexity from the access control policy and user scale, thereby achieving highly efficient access control.

[0025] In combination with the second aspect, in certain embodiments of the second aspect, the authorization vector includes an offset value and length information, the offset value indicates the starting position of the target information, and the length information indicates the length of the target information; or, the authorization vector includes a bit map, and the bit map indicates the field that carries the target information.

[0026] In combination with the second aspect, in certain embodiments of the second aspect, the target information includes at least one of the following: network layer information, transport layer information, authorization request start character, request end character, requester description information, or responder description information corresponding to the target resource, and the target resource is the resource to be accessed by the client device.

[0027] In combination with the second aspect, in certain embodiments of the second aspect, the authorization request initiator includes request information and a partial or complete uniform resource locator (URL) prefix of the target resource, and the request information indicates an operation related to the target resource.

[0028] In combination with the second aspect, in certain embodiments of the second aspect, the network layer information includes the source Internet Protocol IP address and the destination IP address; the transport layer information includes the destination port, or includes the destination port and the source port; the requester description information includes at least one of the following: the requester's identity information, the requester's status information, the requester's group identifier, the requester's security level, or the network type of the network in which the requester is located; the responder description information includes at least one of the following: the responder's group identifier, the responder's security level, or the network type of the network in which the responder is located.

[0029] In combination with the second aspect, in certain embodiments of the second aspect, the token description also includes a validity period and at least one of the following: a check policy, an issuer identifier, a cryptographic suite, or exclusion information; wherein the validity period indicates the validity period of the target token; the check policy indicates whether the requester of the target resource is trusted; the issuer identifier indicates the device that issues the target token; the cryptographic suite indicates relevant information of the cryptographic hash function; and the exclusion information indicates prohibited information.

[0030] In conjunction with the second aspect, in certain embodiments of the second aspect, the method further includes: the gateway device determining, based on the validity period of the target token, that the target token has not expired. Based on this embodiment, the validity period check can prevent an unauthorized user from sending a request using an expired token.

[0031] In combination with the second aspect, in certain embodiments of the second aspect, the method also includes: the gateway device determines that the requester of the target resource is trusted based on the inspection policy; or, the gateway device determines that the requester of the target resource is not trusted based on the inspection policy, and determines that the request message is legal based on the exclusion information.

[0032] In combination with the second aspect, in certain implementations of the second aspect, the gateway device determines that the request message is legal based on the exclusion information, including: when the request message does not carry prohibited information, the gateway device determines that the request message is legal.

[0033] Based on this implementation, by checking the exclusion information, it is possible to prevent illegal users from using legal tokens to send illegal requests, such as preventing illegal users from using TCP connection tokens to send HTTP requests, thereby performing stricter access control and improving network security.

[0034] In combination with the second aspect, in certain embodiments of the second aspect, when the exclusion information is a first value, the information prohibited from being carried is a payload; when the exclusion information is a second value, the information prohibited from being carried is a request terminator; when the exclusion information is a third value, the information prohibited from being carried is request information; when the exclusion information is a fourth value, the information prohibited from being carried is request information and a request terminator; when the exclusion information is a fifth value, it indicates that multiple request information and multiple request terminators are prohibited from being carried.

[0035] In combination with the second aspect, in certain implementations of the second aspect, the method further includes: the gateway device extracting target information from the request message according to the authorization vector.

[0036] Among them, the technical effects brought about by the various implementation methods of the second aspect can refer to the technical effects brought about by the corresponding implementation methods of the first aspect mentioned above, and will not be repeated here.

[0037] In a third aspect, an access control method is provided. The method can be executed by a client device, or by a component of the client device, such as a processor, a chip, or a chip system, or by a logic module or software that can implement all or part of the client device's functions. Taking the method executed by a client device as an example, the method includes: the client device sends token application information for applying for a target token to an authorization server, then obtains the target token, and sends a request message, the request message including the target token and target information. The target token includes a token description and a first authorization code, the token description includes an authorization vector, the authorization vector indicates the target information, and the first authorization code is generated based on the token description, the target information, and a cryptographic hash function.

[0038] Based on this solution, an authorization server issues a token to a client device based on the client device's application. The client device carries this token with the request message. The token includes a token description and a first authorization code. The token description includes an authorization vector, which indicates the target information involved in the authorization code calculation. Upon receiving the request message, the gateway device or data server can obtain the information involved in the authorization code calculation based on the authorization vector and generate a second authorization code. Access control is then performed based on a comparison of the first and second authorization codes to determine whether they are consistent. For example, access is permitted if the second authorization code matches the first, but denied if they are inconsistent, thereby preventing data leakage.

[0039] In combination with the third aspect, in certain embodiments of the third aspect, the authorization vector includes an offset value and length information, the offset value indicates the starting position of the target information, and the length information indicates the length of the target information; or, the authorization vector includes a bit map, and the bit map indicates the field that carries the target information.

[0040] In combination with the third aspect, in certain embodiments of the third aspect, the target information includes at least one of the following: network layer information, transport layer information, authorization request start character, request end character, requester description information, or responder description information corresponding to the target resource, and the target resource is the resource to be accessed by the client device.

[0041] In combination with the third aspect, in certain embodiments of the third aspect, the authorization request initiator includes request information and a partial or complete uniform resource locator (URL) prefix of the target resource, and the request information indicates an operation related to the target resource.

[0042] In combination with the third aspect, in certain embodiments of the third aspect, the network layer information includes the source Internet Protocol IP address and the destination IP address; the transport layer information includes the destination port, or includes the destination port and the source port; the requester description information includes at least one of the following: the requester's identity information, the requester's status information, the requester's group identifier, the requester's security level, or the network type of the network in which the requester is located; the responder description information includes at least one of the following: the responder's group identifier, the responder's security level, or the network type of the network in which the responder is located.

[0043] In combination with the third aspect, in certain embodiments of the third aspect, the client device obtains the target token, including: the client device searches for the target token according to the authorization request initiator corresponding to the target resource and the correspondence between the authorization request initiator and the token.

[0044] In combination with the third aspect, in certain embodiments of the third aspect, the token description also includes a validity period and at least one of the following: a check policy, an issuer identifier, a cryptographic suite, or exclusion information; wherein the validity period indicates the validity period of the target token; the check policy indicates whether the requester of the target resource is trusted; the issuer identifier indicates the device that issues the target token; the cryptographic suite indicates relevant information of the cryptographic hash function; and the exclusion information indicates prohibited information.

[0045] In combination with the third aspect, in certain embodiments of the third aspect, when a request message is used to request the establishment of a Transmission Control Protocol TCP connection corresponding to a target resource, the prohibited information to be carried is a payload; or, when the request message is the starting segment of a complete request message, the prohibited information to be carried is a request terminator; or, when the request message is the ending segment of a complete request message, the prohibited information to be carried is request information; or, when the request message is the middle segment of a complete request message, the prohibited information to be carried is request information and a request terminator; or, when the request message is a complete request message, exclusion information indicates that multiple request information and multiple request terminators are prohibited.

[0046] In combination with the third aspect, in certain embodiments of the third aspect, the token application information includes at least one of the following: network layer information, transport layer information, application layer information, requester description information, or requirement information corresponding to the target resource; the application layer information includes at least one of the following: the URL of the target resource, request information, or request terminator; the requirement information indicates at least one of the following: the expected token usage duration, whether the complete request message is segmented, and whether a TCP connection is established.

[0047] Among them, the technical effects brought about by the various implementation methods of the third aspect can refer to the technical effects brought about by the corresponding implementation methods of the above-mentioned first aspect, and will not be repeated here.

[0048] In a fourth aspect, a communication device is provided for implementing the various methods described above. The communication device may be the authorization server of the first aspect, or a device contained in the authorization server, such as a chip or module; or, the communication device may be the gateway device of the second aspect, or a device contained in the gateway device, such as a chip or module; or, the communication device may be the client device of the third aspect, or a device contained in the client device, such as a chip. The communication device includes a module, unit, or means corresponding to the implementation of the above method, and the module, unit, or means may be implemented by hardware, software, or by executing the corresponding software implementation by hardware. The hardware or software includes one or more modules or units corresponding to the above functions.

[0049] In some possible designs, the communication device may include a transceiver module and a processing module. The transceiver module, also referred to as a transceiver unit, is configured to implement the transmitting and / or receiving functions described in any of the above aspects and any possible implementations thereof. The transceiver module may be comprised of a transceiver circuit, a transceiver, a transceiver, or a communication interface. The processing module may be configured to implement the processing functions described in any of the above aspects and any possible implementations thereof.

[0050] In some possible designs, the transceiver module includes a sending module and a receiving module, which are respectively used to implement the sending and receiving functions in any of the above aspects and any possible implementation methods.

[0051] In a fifth aspect, a communication device is provided, comprising: a processor and a communication interface; the communication interface is configured to communicate with a module external to the communication device; and the processor is configured to execute a computer program or instruction to cause the communication device to perform the method described in any of the above aspects. The communication device may be the authorization server of the first aspect, or a device included in the authorization server, such as a chip or module; or the communication device may be the gateway device of the second aspect, or a device included in the gateway device, such as a chip or module; or the communication device may be the client device of the third aspect, or a device included in the client device, such as a chip.

[0052] In a sixth aspect, a communication device is provided, comprising: an interface circuit and a processor, wherein the interface circuit is a code / data read / write interface circuit, the interface circuit being configured to receive computer-executable instructions (the computer-executable instructions are stored in a memory, may be read directly from the memory, or may pass through other devices) and transmit them to the processor; the processor being configured to execute the computer-executable instructions so that the communication device performs the method described in any of the above aspects. The communication device may be the authorization server of the first aspect, or a device included in the authorization server, such as a chip or module; or the communication device may be the gateway device of the second aspect, or a device included in the gateway device, such as a chip or module; or the communication device may be the client device of the third aspect, or a device included in the client device, such as a chip.

[0053] In a seventh aspect, a communication device is provided, comprising: at least one processor configured to execute a computer program or instruction to cause the communication device to perform the method described in any of the above aspects. The communication device may be the authorization server of the first aspect, or a device included in the authorization server, such as a chip or module; or the communication device may be the gateway device of the second aspect, or a device included in the gateway device, such as a chip or module; or the communication device may be the client device of the third aspect, or a device included in the client device, such as a chip.

[0054] In some possible designs, the communication device includes a memory for storing necessary program instructions and data. The memory may be coupled to the processor or may be independent of the processor.

[0055] In some possible designs, the communication device may be a chip or a chip system. When the device is a chip system, it may be composed of a chip or include a chip and other discrete components.

[0056] In an eighth aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium, which, when executed on a communication device, enables the method described in any one of the above aspects to be executed.

[0057] In a ninth aspect, a computer program product comprising instructions is provided, which, when executed on a communication device, enables the method described in any one of the above aspects to be executed.

[0058] It can be understood that when the communication device provided in any one of the fourth to ninth aspects is a chip, the above-mentioned sending action / function can be understood as output information, and the above-mentioned receiving action / function can be understood as input information.

[0059] Among them, the technical effects brought about by any design method in the fourth to ninth aspects can refer to the technical effects brought about by different design methods in the above-mentioned first, second or third aspects, and will not be repeated here.

[0060] In a tenth aspect, a communication system is provided, which includes the authorization server, gateway device, and client device described in the above aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 A schematic diagram of normal access and unauthorized access in a campus network;

[0062] Figure 2 A schematic diagram of access control based on an access control list;

[0063] Figure 3 A schematic diagram of access control based on a firewall;

[0064] Figure 4 A schematic diagram of access control based on JWT;

[0065] Figure 5 A schematic diagram of access control based on network cookies;

[0066] Figure 6a A schematic diagram of the structure of a communication system applicable to this application;

[0067] Figure 6b A schematic diagram of access control provided for this application;

[0068] Figure 7 A flowchart of an access control method provided by this application;

[0069] Figure 8 A schematic diagram of parameter types included in target information provided in this application;

[0070] Figure 9 A schematic diagram of parameter types included in target information provided in this application;

[0071] Figure 10a A schematic diagram of parameter types included in target information provided in this application;

[0072] Figure 10b A schematic diagram of parameter types included in target information provided in this application;

[0073] Figure 10c A schematic diagram of parameter types included in target information provided in this application;

[0074] Figure 11a A schematic diagram of the format of a token provided for this application;

[0075] Figure 11b A schematic diagram of another token format provided for this application;

[0076] Figure 12a A schematic diagram of the structure of an IP packet payload provided for this application;

[0077] Figure 12b A schematic diagram of the structure of an IP packet payload provided for this application;

[0078] Figure 12c A schematic diagram of the structure of an IP packet payload provided for this application;

[0079] Figure 12d A schematic diagram of the structure of an IP packet payload provided for this application;

[0080] Figure 13a A schematic diagram of the format of a token provided for this application;

[0081] Figure 13b A schematic diagram of another token format provided for this application;

[0082] Figure 14 A schematic diagram of a token verification process provided for this application;

[0083] Figure 15A schematic diagram of a token validity check sub-sub-process provided for this application;

[0084] Figure 16 A schematic diagram of a client deployment method provided for this application;

[0085] Figure 17 A flowchart of an access control method for deploying request proxy middleware provided by this application;

[0086] Figure 18 A schematic structural diagram of a communication device provided in this application;

[0087] Figure 19 A schematic structural diagram of another communication device provided in this application. DETAILED DESCRIPTION

[0088] In the description of this application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship, for example, A / B can represent A or B; "and / or" in this application is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural.

[0089] In the description of this application, unless otherwise specified, "plurality" means two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, a and b, a and c, b and c, a, b, and c, where a, b, and c can be single or plural.

[0090] In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0091] It will be understood that the “embodiment” mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, the various embodiments in the entire specification do not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It will be understood that in the various embodiments of the present application, the size of the sequence number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0092] It can be understood that in this application, "when" and "if" both mean that corresponding processing will be carried out under certain objective circumstances, and do not limit the time. Nor do they require any judgment action when implementing it, nor do they mean that there are other limitations.

[0093] It is understood that some optional features in the embodiments of the present application may, in certain scenarios, be implemented independently of other features, such as the solution on which they are currently based, to solve corresponding technical problems and achieve corresponding effects. They may also be combined with other features in certain scenarios as needed. Accordingly, the devices provided in the embodiments of the present application may also implement these features or functions accordingly, which will not be described in detail here.

[0094] In this application, unless otherwise specified, the same or similar parts between the various embodiments can refer to each other. In the various embodiments in this application, and the various implementation methods / implementation methods / implementation methods in each embodiment, if there is no special explanation and logical conflict, the terms and / or descriptions between different embodiments and the various implementation methods / implementation methods / implementation methods in each embodiment are consistent and can be referenced to each other. The technical features in different embodiments and the various implementation methods / implementation methods / implementation methods in each embodiment can be combined to form new embodiments, implementation methods, implementation methods, or implementation methods according to their inherent logical relationships. The implementation methods of this application described below do not constitute a limitation on the scope of protection of this application.

[0095] Hypertext Transfer Protocol (HTTP), a widely used data transmission protocol, is the key to access control. Currently, HTTP access control methods are mainly divided into the following five categories:

[0096] The first type of solution is to deploy access control list (ACL) service on the network layer data plane (such as router / switch). Its principle is as follows: Figure 2As shown in the figure, the authorization server first formulates an access control policy for the client address to the data server address and generates an ACL entry. The ACL is then configured, which means that the ACL entry is sent to the gateway via a specific transmission protocol, software, or out-of-band. Finally, when the gateway receives a data request from the client, it searches the ACL entry for ACL rules and performs a match. If the ACL matches, the data request is forwarded to the data server; if the ACL does not match, the data request is discarded.

[0097] Optionally, an ACL entry may include an ACL number and one or more rules. Each rule includes a rule identifier (ID), i.e., the rule ID, access policy (permit / deny), source address, destination address, and effective time range. For example, a specific ACL entry may be as follows:

[0098] acl number 2000

[0099] rule 5permit source 10.108.234.100 destination 10.108.234.114time-range time 1

[0100] rule 10permit source 10.108.234.101 destination 10.108.234.114time-range time 2

[0101] …

[0102] …

[0103] However, as can be seen from the above introduction, when access control is performed based on ACL, the control granularity is relatively coarse. It is limited by the expression method of ACL rules and the limited information that can be obtained by the network layer. At most, it can only perform access control at the network five-tuple level (i.e., source address, destination address, source port, destination port, protocol), that is, it performs access control at the HTTP data server address level, and cannot perform fine-grained control at the HTTP uniform resource locator (URL) level. On the other hand, the ACL table items grow individually and are mutually dependent, making it difficult to perform operations such as deletion. At the same time, ACL table items are bound to addresses, which is very inflexible when performing address changes and migration deployments, making updates and maintenance more difficult. On the other hand, the search and storage of ACL table items generally require the use of special hardware, which is highly dependent on hardware and has high deployment and use costs.

[0104] The second type of solution is firewall-based access control, which mainly implements request filtering and connection blocking by deploying firewalls. Its basic principles are as follows: Figure 3 As shown in the figure, dedicated software and hardware deployed on the firewall analyze information at all layers of the message, enabling a variety of functions such as access policy enforcement, content audit monitoring, and harmful traffic filtering. Upon receiving a client request, the firewall enforces the access policy, forwarding the request to the data server if it is legitimate or discarding it if it is illegitimate.

[0105] Firewalls offer flexible access control granularity and scope, making them a primary method for access control in current campus networks. However, firewall-based access control solutions rely on data plane logic for policy enforcement, requiring the deployment of specialized equipment and software to parse information at all network layers. This results in high complexity and significant communication and computational overhead.

[0106] The third type of solution is access control based on application layer tokens, which mainly uses application layer tokens issued by the server to perform fine-grained access control on data. Its basic principle is as follows: Figure 4 First, the user logs in to the server on the client and initiates a request. The server ( Figure 4For example, a data server (which could also be a trusted authorization server) verifies the username and password and, based on the user's permissions, issues a corresponding token, such as a JSON web token (JWT), which is returned to the client. The client then stores the token and embeds it in the HTTP request header (typically the Authorization header) when initiating a request. Upon receiving the request, the data server extracts the token and verifies its validity using methods such as database queries or signature verification. If the token is valid, the request is responded to; otherwise, the request is rejected.

[0107] However, the above token-based access control requires consuming resources on the data server side for permission verification, and cannot intercept illegal requests before they reach the data server, nor can it block the establishment of unauthorized request connections.

[0108] The fourth type of solution is access control based on zero-trust architecture. Access control based on zero-trust architecture is not a specific technology, but a design concept based on the assumption that the entire network is untrustworthy and that there are persistent internal and external threats. Based on this concept, relevant security technologies are used to build a zero-trust security system. Its access control is completed in two stages. The access proxy acts as a backward proxy and is the logical center for the enforcement of access policies in the first stage. It is used to complete functions such as user / device authentication, credential unloading, and sending requests to the backend. ACLs can be deployed to complete coarse-grained access control and then forward requests. The second stage is completed in the back-end application. That is, when the back-end application receives the request, it queries its own service access policy configuration to perform fine-grained access control.

[0109] As a systematic solution, the access control solution based on zero-trust architecture has high deployment and overhead costs. In addition, this solution is more about the integration and use of existing access control technologies (such as JWT and ACL engine), and does not solve the problems existing in the relevant technologies themselves.

[0110] The fifth type of solution is based on network cookies. The basic framework of the network cookies system is as follows: Figure 5 As shown. The client requests a cookie descriptor from the cookie server according to its own needs (such as accessing resources). For example, the cookie descriptor includes the following information:

[0111] cookie_descriptor{

[0112] cookie_id, / / unique identifier of cookie descriptor

[0113] key, / / cookie signature key

[0114] service_data, / / service data

[0115] attribute[], / / cookie attributes

[0116] }.

[0117] After the client obtains this cookie descriptor, it can generate a cookie locally to carry with it when sending a message. For example, the cookie includes the following information:

[0118] cookie{

[0119] cookie_id, / / unique identifier of cookie descriptor

[0120] uuid, / / cookie's unique identifier

[0121] timestamp, / / timestamp

[0122] signature, / / cookie signature

[0123] }.

[0124] When the switch or middleware receives a message carrying a cookie from the client, it searches for the signature key based on the cookie_id and uses it to calculate the cookie digest. It then compares the calculated cookie digest with the cookie's signature. If the two are identical, it performs further verification based on the cookie timestamp. If the verification passes, it forwards the message to the data server so that the data server can provide the service corresponding to the cookie_descriptor.

[0125] In solutions based on network cookies, the client obtains the cookie descriptor and then generates the cookie locally. However, the cookie descriptor must be synchronized between the client, the cookie server, and the switch / middleware. As the number of clients increases, the communication and storage complexity of synchronizing the cookie descriptor between the client, the cookie server, and the switch / middleware increases linearly.

[0126] On the other hand, the switch / middleware needs to retrieve the signature key in the cookie descriptor through the cookie carried by the cookie, so the complexity of verifying the legitimacy of the cookie will also increase linearly.

[0127] On the other hand, cookie verification is performed only through the cookie itself and the information stored in the switch / middleware. If HTTP access control is performed, illegal users may use valid cookies to send unauthorized HTTP requests, which will cause security vulnerabilities in a high-security environment.

[0128] As can be seen from the above, current access control methods have various problems. Based on this, the present application provides an access control method that can perform access control reasonably, efficiently and flexibly, thereby reducing data leakage.

[0129] It is understandable that the method provided in this application can be used for access control of various transmission protocols with standardized formats, including but not limited to HTTP. For example, it can also be applied to other protocols such as file transfer protocol (FTP).

[0130] Figure 6a FIG. 6 is a schematic diagram of the architecture of a communication system 600 used in an embodiment of the present application. Figure 6a As shown, the communication system includes a client device 601 and an authorization server 602. Optionally, the communication system may further include a data server 603 or a gateway device 604.

[0131] Optionally, the authorization server is the point of entry for access control policies, such as issuing tokens. The data server is the responder for data or resources. The gateway device is the point of execution for access control policies, such as for token verification. Alternatively, the data server can be the point of execution for access control policies, meaning token verification can be performed on the data server.

[0132] Based on the communication system 600, Figure 6b As shown, taking the gateway device as the execution point of the access control policy as an example, in the access control method provided by this application, the client device first sends a token request message to the authorization server, and then the authorization server returns the target token to the client device. When the client device sends a request message, it carries the target token in the request message. After receiving the request message, the gateway device verifies the legitimacy of the token and forwards the request message to the data server if the token is valid. Subsequently, the data server can send a response to the request message.

[0133] When the data server serves as the execution point of the access control policy, the gateway device can directly forward the received request message to the data server, which will perform token verification and send a response to the request message to the client device if the token is valid. The detailed description of the above solution will be described in subsequent embodiments and will not be repeated here.

[0134] Optionally, the authorization server and the data server may be an application server or a personal computer (PC), etc. The gateway device may be a network device with data packet forwarding capability, such as a router or a switch.

[0135] Optionally, the client device may be a terminal device with communication capabilities. Exemplarily, the client device may be: an Internet of Things (IoT) device (e.g., a sensor, an electricity meter, a water meter, etc.), a vehicle to everything (V2X) device, a station (ST) in a wireless local area network (WLAN), a personal digital assistant (PDA) device, a handheld device with wireless communication capabilities (e.g., a mobile phone), a computing device or other processing device connected to a wireless modem, an in-vehicle device, a wearable device (also referred to as a wearable smart device), a tablet computer, or a computer with wireless transceiver capabilities, etc.

[0136] It should be noted that the communication system described in the embodiment of the present application is intended to more clearly illustrate the technical solution of the embodiment of the present application, and does not constitute a limitation on the technical solution provided in the embodiment of the present application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

[0137] The following will be combined with the accompanying drawings to expand the method provided by the embodiment of the present application. It is understandable that in the embodiment of the present application, the execution subject can perform some or all of the steps in the embodiment of the present application, and these steps or operations are only examples. The embodiment of the present application can also perform other operations or variations of various operations. In addition, the various steps can be performed in a different order according to the embodiment of the present application, and it is possible that not all operations in the embodiment of the present application need to be performed.

[0138] It should be noted that the names of the various information or parameters in the following embodiments of the present application are only examples, and other names may be used in specific implementations. The embodiments of the present application do not specifically limit this.

[0139] like Figure 7As shown, an access control method provided by this application includes the following steps:

[0140] S701: The client device sends a token application message to the authorization server. Correspondingly, the authorization server receives the token application message from the client device.

[0141] The token application information is used to apply for a target token.

[0142] Optionally, the token application information may include at least one of the following: network layer information corresponding to the target resource, transport layer information corresponding to the target resource, application layer information corresponding to the target resource, requester description information corresponding to the target resource, or requirement information.

[0143] Optionally, the target resource is a resource to be accessed by the client device. The target resource can be any resource on the Internet. Its location on the Internet can be identified by a uniform resource locator (URL). This application uses the example of a data server providing (or responding to) the target resource. For example, a specific URL can be w3.huawei.com / next / indexa.html.

[0144] The network layer information may include the source Internet Protocol (IP) address and the destination IP address. The source IP address corresponding to the target resource is the IP address of the client device, and the destination IP address is the IP address of the data server.

[0145] The transport layer information may include a destination port, or may include a destination port and a source port. The destination port corresponding to the target resource is the port of the data server, and the source port is the port of the client device.

[0146] Application-layer information can include at least one of the following: the URL of the target resource, request information, and a request terminator. The request information indicates the operation associated with the target resource. The URL and request information can indicate the resource a request intends to access and the metadata to be manipulated. For example, for HTTP, the request information can be a method, such as Get, Post, or Connect. For FTP, the request information can be a command, such as Put or Delete.

[0147] For example, for the HTTP protocol, when the HTTP request does not contain a request body, the request terminator can be / r / n / r / n; when the HTTP request contains a request body, the request terminator can be 0 / r / n / r / n. When the HTTP request contains a request body, the format of the request terminator can be pre-negotiated between the authorization server and the client device, or can be configured or notified by the authorization server to the client device.

[0148] The requester corresponding to the target resource may include a client device and / or a user. The user may be an account (i.e., a user name) that logs in on the client device and requests access to the target resource. The description information of the requester corresponding to the target resource may include at least one of the following: identity information of the requester (e.g., user name and password, client device certificate, etc.), status information of the requester (e.g., operational status summary of the client device), group identifier of the requester, security level of the requester, or network type of the network in which the requester is located (e.g., mobile network or fixed network).

[0149] The request information indicates at least one of the following: the desired token usage duration, whether the complete request message is segmented, and whether a Transmission Control Protocol (TCP) connection is established. A TCP connection refers to the TCP connection corresponding to the target resource, or in other words, the TCP connection between the client device and the data server. Typically, a TCP connection between the client device and the data server must be established before a request can be made.

[0150] Optionally, before step S701, the client device may establish a secure and trusted channel with the authorization server through the transport layer security (TLS) protocol, out-of-band configuration, etc., and then send token application information to the authorization server through the secure and trusted channel to prevent the token application information from being tampered with or leaked.

[0151] S702: The authorization server generates a target token based on the token application information.

[0152] The target token includes a token description and a first authorization code. The token description includes an authorization vector, which indicates target information. The first authorization code is generated based on the token description, target information, and a cryptographic hash function.

[0153] Exemplarily, the first authorization code is generated by a character string consisting of the token description and the target information through a cryptographic hash function. The cryptographic hash function may be an HMAC algorithm. In this case, the calculation formula of the authorization code may be expressed as the following formula (1):

[0154] AuthVector = HMAC(TokenDescription||target information, MasterKey) (1)

[0155] Here, || represents a connection; the MasterKey is the key for the cryptographic hash function. The MasterKey can be generated and updated periodically by the authorization server. The authorization server can also send the MasterKey to a gateway device or data server for token verification.

[0156] Optionally, the target information is information to be carried in the request message of the client device, or in other words, the target information is part of the bytes in the request message. That is, the information in the request message participates in the calculation of the authorization code. In this scenario, the target information can be expressed as AuthSegments, and the above formula (1) can be replaced by the following formula (2):

[0157] AuthVector = HMAC(TokenDescrption||AuthSegments, MasterKey) (2)

[0158] Based on this solution, the information in the request message is used to participate in the calculation of the authorization code. When the token is subsequently verified, it can prevent the use of the target token to send illegal requests. For example, when an illegal user sends a request using the target token, since the calculation of the authorization code requires the participation of the information in the request message, if they want to pass the token verification, they need to falsify the target information in the request message. However, falsifying the information in the request message may not be able to complete the illegal request of the illegal user. Therefore, the target token of this application can be used freely within the authorized scope without worrying about theft. Compared with the network cookies solution, it can further improve security performance.

[0159] Optionally, the target information may include at least one of the following: network layer information, transport layer information, authorization request start character, request end character, requester description information, or responder description information corresponding to the target resource.

[0160] Optionally, the destination IP address in the network layer information included in the target information can be the full IP address of the data server, or can be the IP address prefix of the data server. When the destination IP is the IP address prefix of the data server, the target token can be used when accessing multiple data servers under the IP address prefix.

[0161] Optionally, the authorization request initiator includes the request information and part or all of the URL prefix of the target resource. By adjusting the URL prefix of the target resource in the authorization request initiator, the authorization server can flexibly control the access scope. For example, taking the target resource URL as w3.huawei.com / next / indexa.html as an example, if the URL prefix of the target resource in the authorization request initiator is w3.huawei.com, it indicates that the authorization server grants the requester the relevant operation permissions under the host. If the URL prefix of the target resource in the authorization request initiator is w3.huawei.com / next, it indicates that the authorization server grants the requester the relevant operation permissions under the target "next" in the host. Compared with granting the relevant operation permissions under the host, this narrows the requester's access scope.

[0162] Optionally, the authorization server may determine the access rights of the requester based on the requester's description information, and then determine the authorization request initiator based on the requester's access rights. For example, the authorization server may pre-store or configure a correspondence between access rights and requesters. Upon receiving the requester's description information from the client device, the authorization server may obtain information about the requester and then search for the requester's access rights based on this correspondence.

[0163] Optionally, the responder is a data server, and the responder description information may include at least one of the following: the responder's group identifier, the responder's security level, or the network type of the responder's network. For the description of other parameters included in the target information, please refer to the relevant description in step S701 above, and will not be repeated here. Optionally, the authorization server may determine the parameters included in the target information based on the requirement information in the token application information. For example:

[0164] When the request information indicates to establish a TCP connection, such as Figure 8 As shown, the target information includes the network layer information and transport layer information corresponding to the target resource. In this case, the target token can be called a TCP connection token.

[0165] When the demand information indicates that the complete request message is not segmented, such as Figure 9 As shown, the target information includes the network layer information, transport layer information, authorization request start symbol, and request end symbol corresponding to the target resource. At this time, the target token can be recorded as A_Token.

[0166] When the demand information indicates a complete request message segment, the target information includes the first sub-target information corresponding to the starting segment of the complete request message, the second sub-target information corresponding to the middle segment, and the third sub-target information corresponding to the last segment. Correspondingly, the target token includes the first sub-target token corresponding to the starting segment (denoted as S_Token), the second sub-target token corresponding to the middle segment (denoted as M_Token), and the third sub-target token corresponding to the last segment (denoted as E_Token).

[0167] Optional, such as Figure 10a As shown, the initial segment of the complete request message includes the IP header, TCP header, and payload, which includes the request information, URL, and part of the request bytes. The first sub-target information corresponding to the initial segment includes network layer information, transport layer information, and authorization request start character.

[0168] Optional, such as Figure 10b As shown, the middle segment of the complete request message includes an IP header, a TCP header, and a payload, wherein the payload includes part of the request bytes. The second sub-target information corresponding to the middle segment includes network layer information and transport layer information.

[0169] Optional, such as Figure 10c As shown, the end segment of the complete request message includes the IP header, TCP header, and payload, which includes part of the request bytes and the request terminator. The third sub-target information corresponding to the end segment includes network layer information, transport layer information, and the request terminator.

[0170] Optionally, based on the token application information in step S701, the authorization server may generate a TCP connection token and an A_Token; or, may generate a TCP connection token, an S_Token, an M_Token, and an E_Token; or, may generate a TCP connection token, an A_Token, an S_Token, an M_Token, and an E_Token.

[0171] Based on this solution, the content of the target information can be adjusted as needed, thereby flexibly adjusting the access control granularity and achieving multi-level, refined access control. For example, the target information can include network layer information to achieve network layer access control; or the target information can include network layer, transport layer, and application layer information to achieve URL-level fine-grained control; or the target information can include requester or responder description information to achieve access control based on security level, network type, etc.

[0172] Optional, regarding how the authorization vector indicates the target information:

[0173] As a possible implementation, the authorization vector may include an offset value (offset) and length information. The offset value indicates the starting position of the target information, and the length information indicates the length of the target information. For example, the offset value may be the offset of the starting position of the target information relative to the starting position or ending position of the request message. The length information indicates the length starting from the offset.

[0174] Optionally, when the target information includes multiple parameters, the authorization vector may include multiple offset values ​​and multiple length information to indicate the multiple parameters respectively. For example, when the target information includes parameter 1 and parameter 2, the authorization vector may include offset value 1 and length 1 to indicate the starting position and length of parameter 1, and may also include offset value 2 and length 2 to indicate the starting position and length of parameter 2. In this case, the format of the target token may be as follows: Figure 11a shown.

[0175] As another possible implementation, the authorization vector may include a bitmap that indicates the field carrying the target information. Exemplarily, the bitmap includes N bits, where N is the total number of fields included in the request message, and each bit corresponds to a field in the request message. The authorization server may set the bit corresponding to the field carrying the target information to 1. Taking N equal to 8 as an example, if the target information includes the information carried by the 4th to 6th fields, the bitmap may be 00011100. In this case, the format of the target token may be as follows: Figure 11b shown.

[0176] It is understandable that, since the request message has a standardized format, even if the client device does not send a request message, the authorization server can still learn the format of the request message and can further indicate the target information through the authorization vector.

[0177] S703: The authorization server sends a target token to the client device. Correspondingly, the client device receives the target token from the authorization server.

[0178] Optionally, the authorization server may send the target token to the client device through a secure and trusted channel between the authorization server and the client device.

[0179] Optionally, the token sent by the authorization server to the client device may include a TCP connection token and an A_Token; or, may include a TCP connection token, an S_Token, an M_Token, and an E_Token; or, may include a TCP connection token, an A_Token, an S_Token, an M_Token, and an E_Token.

[0180] Optionally, the client device can establish a correspondence between the authorization request initiator corresponding to the target resource and the target token. The authorization request initiator corresponding to the target resource can be obtained by the client device based on the authorization vector of the target token, or can be sent to the client device by the authorization server. That is, in addition to the target token, the authorization server also returns the authorization request initiator corresponding to the target resource to the client device.

[0181] Afterwards, the above steps S701-S703 may be continued to obtain tokens corresponding to other resources, thereby establishing a correspondence table between the authorization request initiator and the token. Exemplarily, the correspondence table may be shown in Table 1 below.

[0182] Table 1

[0183]

[0184] Subsequently, when the client device requests to access the target resource or establishes a TCP connection corresponding to the target resource, the following step S704 is executed.

[0185] S704: The client device obtains the target token.

[0186] Optionally, if the client device has established a table of correspondences between authorization request initiators and tokens, the acquisition and use of the target token can be decoupled. Specifically, the client device can request the target token from the authorization server in advance and store it, then use the target token when sending a request message. In this case, step S704 may include searching for the target token based on the authorization request initiator corresponding to the target resource and the correspondence between the authorization request initiator and the token.

[0187] Optionally, if the client device has not established a correspondence between the authorization request initiator and the token, step S704 may be understood as the above: the client device receives the target token from the authorization server. After receiving the target token from the authorization server, the client device may use it directly.

[0188] S705: The client device sends a request message. The gateway device receives the request message from the client device, wherein the request message includes a target token and target information.

[0189] Optionally, the request message may be used to request establishment of a TCP connection corresponding to the target resource, or may be used to request access to the target resource. For example, the request message may be an HTTP request message or an FTP request message.

[0190] Optionally, the target token can be carried in the network layer header of the request message. The specific location of the target token in the network layer header can be determined according to the specific network layer protocol. For example, when the network layer protocol is IPv6, the target token can be carried in an option field such as the destination option in the network layer header; when the network layer protocol is NewIP, the target token can be carried in the security option field in the network layer header. Alternatively, the target token can be carried in the application layer of the request message.

[0191] Optionally, when the target token is carried in the network layer header of the request message, the access control policy can be enforced by the gateway device, which performs token verification. When the target token is carried in the application layer of the request message, the access control policy can be enforced by the data server, which performs token verification.

[0192] Optionally, when the request message is used to establish a TCP connection corresponding to the target resource, the target token can be a TCP connection token. When the access control policy is enforced by a gateway device, the use of a TCP connection token allows unauthorized client devices to be identified and filtered when requesting to establish a TCP connection, enabling first-packet interception between the client device and the data server.

[0193] Alternatively, using the example of a target token carried in the network layer header of a request message, the client device's application layer can generate a complete request message to request access to the target resource. The application layer then delivers the complete request message to the transport layer, which determines whether to perform TCP segmentation on the complete request message. If TCP segmentation is required, the transport layer tags the segment type before delivering it to the network layer. Upon receiving the message from the transport layer, the network layer identifies the segment type and adds the corresponding target token to the network layer header.

[0194] For example, take HTTP request message as an example, Figure 12a As shown, when HTTP segmentation (HTTPSeg) is equal to 0, it means that there is no need to segment the HTTP request message, the payload of the IP message includes the complete HTTP request, and the corresponding target token is A_Token.

[0195] like Figure 12b As shown, when HTTPSeg is equal to 1, it indicates the starting segment of the complete request message. The payload of the IP message includes the HTTP request start symbol (ie, method+URL) and the remaining HTTP request part. The corresponding target token is S_Token.

[0196] like Figure 12cAs shown, when HTTPSeg is equal to 2, it indicates the middle segment of the complete request message. The payload of the IP message includes the remaining HTTP request part, and the corresponding target token is M_Token.

[0197] like Figure 12d As shown, when HTTPSeg is equal to 3, it indicates the end segment of the complete request message. The payload of the IP message includes the remaining HTTP request part and the request terminator, and the corresponding target token is E_Token.

[0198] S706: The gateway device or the data server generates a second authorization code according to the token description, the target information, and the key hash function.

[0199] Optionally, when the execution point of the access control policy is a gateway device, step S706 is performed by the gateway device. When the execution point of the access control policy is a data server, step S706 is performed by the data server. In this case, before step S706, the gateway device needs to forward the request message to the data server. Figure 7 The gateway device executing step S706 is taken as an example for description.

[0200] Optionally, the gateway device or data server generates the second authorization code in the same manner as the authorization server and uses the same key.

[0201] Optionally, the target information may be extracted from the request message by the gateway device or the data server according to the authorization vector in the token description.

[0202] Optionally, when the second authorization code is the same as (or consistent with) the first authorization code, if step S706 is executed by the gateway device, the following step S707 may be executed; if step S706 is executed by the data server, the following step S708 may be executed.

[0203] Optionally, when the second authorization code is different from (or inconsistent with) the first authorization code, the gateway device or the data server may discard the request message. Alternatively, if step S706 is performed by the gateway device, the gateway device may forward the request message to the data server via the first path; or, the gateway device may add a tag to the request message and forward the tagged request message to the data server. When the data server receives the request message via the first path or receives the tagged request message, it may learn that the request message is a message that has failed token verification, and may perform corresponding processing, for example, discarding the request message or responding to a partial request.

[0204] Based on this solution, when the execution point of the access control policy is a gateway device, compared with the existing JWT solution, illegal requests can be intercepted before reaching the data server.

[0205] S707: The gateway device forwards the request message to the data server. Correspondingly, the data server receives the request message from the gateway device.

[0206] Optionally, the gateway device may forward the request message to the data server via the second path. When the data server receives the request message via the second path, it may know that the request message is a message that has passed token verification, and thus execute the following step S708.

[0207] S708: The data server sends a response message to the client device. Correspondingly, the client device receives the response message from the data server. The response message is a response to the request message.

[0208] Optionally, after receiving the response message, the client device may perform relevant processing based on the response message, and this application does not make any specific limitations on this.

[0209] In this application, on the one hand, the authorization server issues a token to the client device based on the client device's application, and the client device carries the token when sending a request message. The token includes a token description and a first authorization code. The token description includes an authorization vector. The authorization vector indicates the target information involved in the authorization code calculation, so that after the gateway device or data server side receives the request message, it can obtain the information involved in the authorization code calculation based on the authorization vector and generate a second authorization code. Access control is performed based on whether the first authorization code and the second authorization code are consistent. For example, access is allowed when the second authorization code is consistent with the first authorization code, and access is denied when the second authorization code is inconsistent with the first authorization code, thereby preventing data leakage.

[0210] On the other hand, the authorization server can flexibly formulate access control policies, that is, it can flexibly formulate tokens without synchronizing access control policies to gateway devices, so that gateway devices do not need to maintain access control policies or access control lists. Compared with existing ACL and firewall solutions, it can be flexibly deployed and reduce deployment and usage costs.

[0211] On the other hand, the execution point of the access control policy does not need to analyze the application layer semantics of the request message, nor does it need to query the access control policy, user information, etc. It can calculate and verify the authorization code in a fool-proof manner without any perception. The storage and computing complexity is decoupled from the access control policy and the user scale, thereby achieving highly efficient access control.

[0212] In some embodiments, in addition to the authorization vector, the token description may also include an expiration date (ExpiredTime) and at least one of the following: a check policy (CheckPolicy), an issuer identifier (IssuerID), a cipher suite (CypherSuit), or exclusion information (Exclude). In this scenario, the format of the target token can be as follows: Figure 13a or Figure 13b shown.

[0213] Optionally, the validity period indicates a limited period of the target token, which may be determined by the authorization server based on the expected token usage duration indicated by the requirement information.

[0214] Optionally, the check policy indicates whether to trust the target resource's requestor, or in other words, whether to trust the target token's user. For example, when CheckPolicy is set to 0, the target resource's requestor is trusted, while when CheckPolicy is set to 1, the target resource's requestor is distrusted. If the global check policy is unique, meaning all requestors in the network are trusted or distrusted, the check policy can be omitted.

[0215] In step S702, the authorization server can determine whether to trust the target resource's requestor based on the requestor's description information, thereby setting a check policy. For example, if the client device is authenticated by the authorization server and the user is a trusted user, the authorization server determines that the target resource's requestor is trusted, and sets CheckPolicy to 0. If the client device is not authenticated by the authorization server or the user is untrustworthy, the authorization server determines that the target resource's requestor is not trusted, and sets CheckPolicy to 1.

[0216] Optionally, the issuer identifier indicates the device that issued the target token (called the token-issuing device), which is the authorization server. Access control policy enforcement points can use this identifier to look up information about the token-issuing device. If the token-issuing device is globally unique, the issuer identifier can be omitted.

[0217] Optionally, the cipher suite indicates information about the cryptographic hash function used to calculate the authorization code. The access control policy enforcement point can determine the cryptographic information required for token verification based on the cipher suite. For example, the cipher suite may include a MasterKey identifier, allowing the access control policy enforcement point to determine the MasterKey based on the identifier; alternatively, the access control policy enforcement point may also determine the type and length of the cryptographic hash function based on the cipher suite.

[0218] Optionally, the exclusion information indicates prohibited information, which is information that is prohibited from being included in the request message from the client device. In other words, the exclusion information indicates information that cannot appear in the request message. When the inspection policy indicates that the requester of the target resource is trusted, the exclusion information can be omitted.

[0219] Optionally, when the request message is used to request establishment of a TCP connection corresponding to the target resource, the prohibited information to be carried is a payload. In this case, the exclusion information can be set to a first value, and illustratively, the first value can be 0.

[0220] When the request message is the starting segment of a complete request message, the prohibited information is the request end character. In this case, the exclusion information can be set to a second value, and for example, the second value can be 1.

[0221] When the request message is the last segment of a complete request message, the information prohibited from being carried is the request information. In this case, the exclusion information can be set to a third value, for example, the third value can be 2.

[0222] When the request message is a middle segment of a complete request message, the prohibited information is the request information and the request terminator. In this case, the exclusion information can be set to a fourth value, for example, the fourth value can be 3.

[0223] When the request message is a complete request message, the exclusion information indicates that it is prohibited to carry multiple request information and multiple request terminators. In this case, the exclusion information can be set to a fifth value, and for example, the fifth value can be 4.

[0224] In step S702, the authorization server may determine relevant information about the request message based on the requirement information from the client device, and thereby set exclusion information. For example, if the requirement information indicates establishing a TCP connection, the request message is used to establish a TCP connection corresponding to the target resource, and the exclusion information may be set to a first value; if the requirement information indicates fragmenting the entire request message, the exclusion information corresponding to the initial fragment may be set to a second value, and so on.

[0225] Optionally, based on the above token description, the execution point of the access control policy can be further verified according to the validity period, inspection policy, exclusion information, etc. For example, taking the execution point of the access control policy as a gateway device, Figure 14 It is a verification process for a gateway device, such as Figure 14 As shown, the verification process includes the following steps:

[0226] S1401: Determine whether the destination port in the request message is the port corresponding to the target protocol.

[0227] The target protocol is the protocol currently undergoing access control, such as the HTTP protocol or the FTP protocol, and of course it can also be other transmission protocols, which is not specifically limited in this application.

[0228] Optionally, if the destination port is the port corresponding to the target protocol, execute the following step S1402; if the destination port is not the port corresponding to the target protocol, execute other access control processes. This application does not limit other access control processes and will not be described in detail here.

[0229] S1402: Determine whether the request message carries a target token.

[0230] Optionally, if the request message carries a target token, execute the following step S1403; if the request message does not carry a token, discard the request message.

[0231] S1403: Determine whether the target token has expired.

[0232] Optionally, the gateway device may obtain the validity period of the target token from the token description, thereby determining whether the target token has expired based on the validity period of the target token. This application is described as if the target token has not expired.

[0233] Optionally, if the target token has not expired, execute Figure 15 The token validity check sub-process shown is as follows; if the target token has expired, the request message is discarded.

[0234] S1404: Check the output of the token validity sub-process to determine whether the target token is valid.

[0235] Optionally, when the token validity check sub-process outputs a first result, the target token is valid; and when the token validity check sub-process outputs a second result, the target token is invalid. For example, the first result can be represented as Y, and the second result can be represented as N.

[0236] Optionally, if the target token is legal, execute the following step S1405; if the target token is illegal, discard the request message, or forward the request message to the data server through the first path, or add a label to the request message and forward it to the data server. Please refer to the relevant instructions in the above step S706 and will not repeat them here.

[0237] S1405: Forward the request message to the data server. Please refer to the relevant description in the above step S707, which will not be repeated here.

[0238] Optional, such as Figure 15 As shown, the token validity check sub-process includes the following steps:

[0239] S1501: Determine whether the requester of the target resource is trusted.

[0240] Optionally, the gateway device may determine whether to trust the target resource requester based on the check policy in the token description. For example, if the check policy is set to 0, the target resource requester is trusted; if the check policy is set to 1, the target resource requester is not trusted.

[0241] Optionally, if the requester of the target resource is not trusted, execute the following step S1502; if the requester of the target resource is trusted, execute the following step S1503.

[0242] S1502: Check the validity of the request message based on the exclusion information.

[0243] Optionally, when the request message does not carry the prohibited information indicated by the exclusion information, the request message is determined to be legal; when the request message carries the prohibited information, the request message is illegal and can be discarded.

[0244] Optional, such as Figure 15 As shown, when the exclusion information is the first value, execute step S15021; when the exclusion information is the second value, execute step S15022; when the exclusion information is the third value, execute step S15023; when the exclusion information is the fourth value, execute step S15024; when the exclusion information is the fifth value, execute step S15025.

[0245] S15021. Check whether the request message carries a payload.

[0246] Optionally, when the request message does not carry a payload, continue to execute the following step S1503; when the request message carries a payload, the request message may be discarded.

[0247] S15022. Check whether the request message carries a request end character.

[0248] Optionally, when the request message does not carry a request terminator, continue to execute the following step S1503; when the request message carries a request terminator, the request message may be discarded.

[0249] S15023. Check whether the request message carries request information.

[0250] Optionally, when the request message does not carry request information, continue to execute the following step S1503; when the request message carries request information, the request message can be discarded.

[0251] S15024. Check whether the request message carries request information and request terminator.

[0252] Optionally, when the request message does not carry request information and request terminator, continue to execute the following step S1503; when the request message carries request information or request terminator, the request message may be discarded.

[0253] S15025. Check whether the request message carries multiple request information and multiple request terminators.

[0254] Optionally, when the request message carries a single request message and a single request terminator, continue to execute the following step S1503; when the request message carries multiple request messages or multiple request terminators, the request message may be discarded.

[0255] S1503: Extract target information from the request message according to the authorization vector. After extracting the target information, the following step S1504 may be executed.

[0256] S1504: Generate a second authorization code based on the token description, target information, and cryptographic hash function.

[0257] Optionally, the relevant information of the cryptographic hash function may be determined based on the cryptographic suite in the token description. The specific implementation of step S1504 may refer to the relevant description in step S706 above, which will not be repeated here.

[0258] S1505: Determine whether the first authorization code and the second authorization code are the same.

[0259] Optionally, if the first authorization code and the second authorization code are the same, output the first result and return Figure 14 The process shown; if the first authorization code and the second authorization code are different, the second result is output and returned Figure 14 The process shown. Figure 15 In the example, the first result is represented as Y and the second result is represented as N.

[0260] This solution uses validity checks to prevent illegal users from using expired tokens to send requests. Exclusion information checks prevent illegal users from using valid tokens to send illegal requests, such as using TCP connection tokens to send HTTP requests. This allows for stricter access control and improves network security.

[0261] In the above-mentioned access control method, the use of tokens involves information interaction and coordination between the application layer and the network layer, and the existing network model may no longer be applicable. For example, when the network layer carries a token, the application of the token is mainly implemented by the application layer, and the application of the token (such as embedding in a message) is mainly implemented by the network layer. The application layer and the network layer need to interact so that the network layer can correctly embed the token in the message. For example, the application layer needs to indicate to the network layer the token corresponding to the TCP connection, the complete request message, and each segment of the complete request message. Based on this, the following embodiments of this application will provide an exemplary deployment method to support the implementation of the solution of this application.

[0262] Optional, such as Figure 16 As shown, the following three deployment methods can be used: 1) deployment based on request proxy middleware; 2) deployment based on a dedicated browser; 3) deployment based on a request proxy.

[0263] In the first deployment method, existing general-purpose browsers and request proxy middleware can be deployed on client devices. The request proxy middleware implements token proxy application and usage functions. For example, it implements functions such as sending token application information, establishing a mapping between resources and tokens, segmenting and queuing request messages, forward proxying, and embedding tokens into request messages.

[0264] For example, taking HTTP access control and the execution point of the access control policy as a gateway device as an example, the implementation process based on the deployment method of the request proxy middleware can be as follows: Figure 17 As shown:

[0265] The request proxy middleware sets up a browser proxy when it starts, generates a self-signed certificate, and then sends the self-signed certificate to the browser. The request proxy middleware can regenerate the self-signed certificate each time it starts.

[0266] After the browser receives the self-signed certificate, add the self-signed certificate to the browser or system trusted certificate list and log in to the proxy using the username and password.

[0267] After the user logs in, the request proxy middleware establishes a connection to the authorization server. For example, the request proxy middleware may include a built-in authorization server certificate and encrypt information related to the request proxy middleware, client device, and user to the authorization server. The authorization server may verify the legitimacy of the request proxy middleware, client device, and user. Once verification is successful, it establishes a connection with the request proxy middleware.

[0268] The browser then sends an HTTP request to the request proxy middleware. Upon receiving the HTTP request, if the request size is larger than the maximum segment size (MSS) of a TCP packet, the request proxy middleware segments the request and creates a request queue. If the request size is smaller than the MSS of a TCP packet, no segmentation is performed.

[0269] In addition, the request proxy middleware can extract parameters included in the token request information from the HTTP request, such as network layer information, transport layer information, and application layer information, and then send the token request information to the authorization server. After receiving the token request information, the authorization server generates a target token and returns the target token to the request proxy middleware. The target token can include a TCP connection token and an A_Token, or can include a TCP connection token, an S_Token, an M_Token, and an E_Token. After receiving the target token, the request proxy middleware establishes a correspondence between the resource and the token.

[0270] The request proxy middleware then initiates a TCP connection request to the data server, including a TCP connection token. The gateway device verifies the token's legitimacy and forwards the TCP connection request to the data server. The data server accepts the request and establishes a TCP connection.

[0271] After the TCP connection is established, the request proxy middleware initiates an HTTP request in the order of the request queue, carrying the corresponding token in the HTTP request. For example, if HTTP segmentation is used, the corresponding token is embedded in the request according to HTTPSeg. The gateway device verifies the validity of the token and forwards the HTTP request to the data server. The data server responds to the request. After receiving the response from the data server, the request proxy middleware sends it to the browser, which receives and parses the response.

[0272] As mentioned above, the request proxy middleware has the operation logic of both the application layer and the network layer. When it receives a request message from the application layer, it can query the corresponding token and call the underlying network application program interface (API) or raw socket to embed the token in the request message and send it.

[0273] In the second deployment method, a dedicated browser can be developed and deployed on client devices, allowing it to natively support the aforementioned request proxy functionality. Taking HTTP as an example, the dedicated browser needs to parse the user request to construct an HTTP request and extract relevant parameters to request a token from the authorization server. After receiving the authorization token, it selects the token corresponding to the HTTP request as a parameter, directly calls the underlying network API or raw socket to construct the network layer data packet of the HTTP request, embeds the corresponding token in the packet header, and then sends it to the network.

[0274] In the third deployment method, an existing general-purpose browser can be deployed on the client device, while a request proxy can be deployed independently of the client device. This proxy's functionality is similar to the request proxy middleware described above. In other words, the request proxy middleware's functionality is deployed on a separate device or proxy server, rather than on the client device. It's important to note that in this deployment method, a remote TCP connection must be established between the browser and the request proxy.

[0275] Optionally, this deployment method can be applied to scenarios where the client device cannot install a dedicated browser or request proxy middleware, for example, when the client device is a resource-constrained IoT node, a cloud center where the proxy is separated from the upper-layer application, etc.

[0276] It is understandable that the above three deployment methods are only exemplary descriptions and do not constitute any limitation on the access control method provided in this application. In actual use, other deployment methods can also be used without limitation.

[0277] It can be understood that in the above embodiments, the methods and / or steps implemented by each device can also be implemented by components that can be used for the device (such as a processor, chip, chip system, circuit, logic module, or software).

[0278] The above mainly introduces the solution provided by this application from the perspective of interaction between various devices. Correspondingly, this application also provides a communication device, which is used to implement the various methods mentioned above.

[0279] It is understandable that in order to implement the functions in the above embodiments, the communication device includes hardware structures and / or software modules corresponding to the execution of each function. It should be readily apparent to those skilled in the art that, in combination with the units and method steps of each example described in the embodiments disclosed in this application, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in hardware or in a manner driven by computer software depends on the specific application scenario and design constraints of the technical solution.

[0280] Figure 18 and Figure 19Schematic diagram of the structure of possible communication devices provided in the embodiments of the present application. These communication devices can be used to implement the functions of the authorization server, gateway device, client device, or data server in the above method embodiments, and thus can also achieve the beneficial effects of the above method embodiments. In the embodiments of the present application, the communication device can be as follows: Figure 6a The authorization server, gateway device, client device, or data server shown may also be a module (such as a chip) of the authorization server, gateway device, client device, or data server.

[0281] like Figure 18 As shown, the communication device 180 includes a processing module 1801 and a transceiver module 1802. The communication device 180 is used to implement the functions of the authorization server, gateway device, client device, or data server in the above method embodiment.

[0282] When the communication device 180 is used to implement the function of the authorization server in the above method embodiment:

[0283] The transceiver module 1802 is configured to receive token application information from a client device, where the token application information is used to apply for a target token;

[0284] Processing module 1801 is configured to generate a target token based on token application information, where the target token includes a token description and a first authorization code, where the token description includes an authorization vector, where the authorization vector indicates target information, and the first authorization code is generated based on the token description, the target information, and a cryptographic hash function;

[0285] The transceiver module 1801 is further configured to send a target token to the client device.

[0286] Optionally, processing module 1801 is used to generate a target token based on token application information, including: processing module 1801 is used to determine the access rights of the requester based on the requester description information in the token application information; processing module 1801 is also used to determine the authorization request start character based on the access rights of the requester.

[0287] When the communication device 180 is used to implement the function of the gateway device in the above method embodiment:

[0288] The transceiver module 1802 is configured to receive a request message from a client device, the request message including a target token and target information, the target token including a token description and a first authorization code, the token description including an authorization vector, and the authorization vector indicating the target information;

[0289] Processing module 1801, configured to generate a second authorization code based on the token description, target information, and a key hash function;

[0290] When the second authorization code is the same as the first authorization code, the transceiver module 1802 is further configured for the gateway device to forward the request message to the data server.

[0291] Optionally, the processing module 1801 is further configured to determine, based on the validity period of the target token, that the target token has not expired.

[0292] Optionally, the processing module 1801 is further used to determine the requester of the target resource that is trusted according to the inspection policy; or, the processing module 1801 is further used to determine the requester of the target resource that is not trusted according to the inspection policy, and determine the legitimacy of the request message according to the exclusion information.

[0293] Optionally, the processing module 1801 is further used to determine that the request message is legal based on the exclusion information, including: the processing module 1801 is further used to determine that the request message is legal when the request message does not carry prohibited information.

[0294] Optionally, the processing module 1801 is further configured to extract target information from the request message according to the authorization vector.

[0295] When the communication device 180 is used to implement the functions of the client device in the above method embodiment:

[0296] The transceiver module 1802 is used to send token application information to the authorization server, where the token application information is used to apply for a target token;

[0297] Processing module 1801 is configured to obtain a target token, the target token including a token description and a first authorization code, the token description including an authorization vector, the authorization vector indicating target information, and the first authorization code being generated based on the token description, the target information, and a cryptographic hash function;

[0298] The transceiver module 1802 is further configured to send a request message, where the request message includes a target token and target information.

[0299] Optionally, the processing module 1801 is used to obtain the target token, including: the processing module 1801 is used to search for the target token according to the authorization request start character corresponding to the target resource and the corresponding relationship between the authorization request start character and the token.

[0300] For a more detailed description of the processing module 1801 and the transceiver module 1802, please refer to Figure 7 The relevant description in the method embodiment shown is directly obtained and will not be repeated here.

[0301] like Figure 19 As shown, the communication device 190 includes one or more processors 1901, a communication circuit 1902, and at least one communication interface ( Figure 19The description is merely illustrative, taking a communication interface 1904 and a processor 1901 as an example), and optionally, a memory 1903 may also be included.

[0302] Processor 1901 is primarily used to process communication protocols and communication data, control the entire communication device, execute software programs, and process data from software programs. The processor can be a general-purpose central processing unit (CPU), a microprocessor, or an application-specific integrated circuit (ASIC).

[0303] The communication line 1902 may be used for communication between different components included in the communication device 190 .

[0304] Communication interface 1904 can be a device such as a transceiver. A transceiver can include a radio frequency circuit and an antenna. The radio frequency circuit is primarily used for converting baseband signals into radio frequency signals and processing radio frequency signals. The antenna is primarily used for transmitting and receiving radio frequency signals in the form of electromagnetic waves. Alternatively, communication interface 1904 can be a transceiver circuit located within processor 1901, used to implement signal input and output to the processor.

[0305] Memory 1903 is mainly used to store software programs and data. It can be a device with a storage function. For example, it can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to this. The memory can exist independently and be connected to the processor via a communication line 1902. The memory can also be integrated with the processor.

[0306] In a specific implementation, as an embodiment, the processor 1901 may include one or more CPUs, such as Figure 19 CPU0 and CPU1 in.

[0307] In a specific implementation, as an embodiment, the communication device 190 may include multiple processors, such as Figure 19 Processor 1901 and processor 1908 in FIG. Each of these processors can be a single-core processor or a multi-core processor. The processor here can include, but is not limited to, at least one of the following: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor, etc., and each computing device can include one or more cores for executing software instructions to perform calculations or processing.

[0308] In a specific implementation, as an embodiment, the communication device 190 may further include an output device 1905 and an input device 1906. The output device 1905 communicates with the processor 1901 and can display information in a variety of ways. For example, the output device 1905 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 1906 communicates with the processor 1901 and can receive user input in a variety of ways. For example, the input device 1906 can be a mouse, a keyboard, a touch screen device, or a sensor device.

[0309] It should be noted that Figure 19 The structure shown in the figure does not constitute a limitation on the communication device, except Figure 19 In addition to the components shown, the communication device may include more or fewer components than shown, or combine certain components, or arrange the components differently. The components shown may be implemented in hardware, software, or a combination of software and hardware.

[0310] When the communication device 190 is used to implement the method embodiment shown in the figure, the processor 910 can be used to implement the functions of the above-mentioned processing module 1801, and the communication interface 1904 can be used to implement the functions of the above-mentioned transceiver module 1802.

[0311] As an example, Figure 18 The function / implementation process of the processing module 1801 can be achieved by Figure 19 The processor 1901 shown calls the computer execution instructions stored in the memory 1903 to implement, Figure 18The function / implementation process of the transceiver module 1802 can be achieved by Figure 19 The communication interface 1904 is shown.

[0312] In some embodiments, the present application also provides a communication device, which includes a processor for implementing the method in any of the above method embodiments.

[0313] As a possible implementation, the communication device further includes a memory. The memory is used to store necessary program instructions and data. The processor can call the program code stored in the memory to instruct the communication device to execute any of the above-mentioned method embodiments. Of course, the memory may not be located in the communication device.

[0314] As another possible implementation, the communication device also includes an interface circuit, which is a code / data read / write interface circuit, and the interface circuit is used to receive computer execution instructions (computer execution instructions are stored in a memory, may be read directly from the memory, or may pass through other devices) and transmit them to the processor.

[0315] As another possible implementation, the communication device further includes a communication interface, where the communication interface is used to communicate with a module outside the communication device.

[0316] It can be understood that the communication device can be a chip or a chip system. When the communication device is a chip system, it can be composed of chips or include chips and other discrete devices. The embodiments of the present application do not specifically limit this.

[0317] The present application also provides a computer-readable storage medium having a computer program or instruction stored thereon, which implements the functions of any of the above method embodiments when executed by a computer.

[0318] The present application also provides a computer program product, which implements the functions of any of the above method embodiments when executed by a computer.

[0319] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented using a software program, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more media integrated therein. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state disk (SSD)). In the embodiment of the present application, the computer may include the aforementioned device.

[0320] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art can understand and implement other changes to the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple situations. A single processor or other unit can implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0321] Although the present application has been described with reference to specific features and embodiments thereof, it is apparent that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the drawings are merely illustrative of the present application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, the present application is intended to include such modifications and variations as fall within the scope of the claims of the present application and their equivalents.

Claims

1. An access control method, characterized in that: The method comprises: The authorization server receives token application information from the client device, where the token application information is used to apply for a target token; The authorization server generates the target token according to the token application information, wherein the target token includes a token description and a first authorization code, the token description includes an authorization vector, the authorization vector indicates target information, and the first authorization code is generated according to the token description, the target information, and a cryptographic hash function; The authorization server sends the target token to the client device.

2. The method according to claim 1, characterized in that The target information is information to be carried in the request message of the client device.

3. The method according to claim 1 or 2, characterized in that The method further comprises: The gateway device receives a request message from the client device, where the request message includes the target token and the target information; The gateway device generates a second authorization code based on the token description, the target information, and a keyed hash function; When the second authorization code is the same as the first authorization code, the gateway device forwards the request message to the data server.

4. The method according to claim 1 or 2, characterized in that The authorization vector includes an offset value and length information, wherein the offset value indicates a starting position of the target information, and the length information indicates a length of the target information; Alternatively, the authorization vector includes a bit map, and the bit map indicates a field carrying the target information.

5. The method according to claim 1 or 2, characterized in that The target information includes at least one of the following: network layer information, transport layer information, authorization request start character, request end character, requester description information, or responder description information corresponding to the target resource, and the target resource is the resource to be accessed by the client device.

6. The method according to claim 5, characterized in that The authorization request initiator includes request information and a partial or complete URL prefix of the target resource, and the request information indicates an operation related to the target resource.

7. The method according to claim 5, characterized in that The network layer information includes a source Internet Protocol (IP) address and a destination IP address; The transport layer information includes a destination port, or includes a destination port and a source port; The description information of the requesting party includes at least one of the following: identity information of the requesting party, status information of the requesting party, group identifier of the requesting party, security level of the requesting party, or network type of the network where the requesting party is located; The responder description information includes at least one of the following: a group identifier of the responder, a security level of the responder, or a network type of a network where the responder is located.

8. The method according to claim 2, characterized in that The token description also includes a validity period and at least one of: a check policy, an issuer identifier, a cipher suite, or exclusion information; Among them, the validity period indicates the validity period of the target token; the inspection policy indicates whether the requester of the target resource is trusted; the issuer identifier indicates the device that issues the target token; the cryptographic suite indicates the relevant information of the cryptographic hash function; and the exclusion information indicates the information that is prohibited from being carried.

9. The method according to claim 8, characterized in that When the request message is used to request establishment of a Transmission Control Protocol (TCP) connection corresponding to the target resource, the prohibited information is a payload; Alternatively, when the request message is the starting segment of a complete request message, the prohibited information is the request end character; Alternatively, when the request message is the last segment of a complete request message, the prohibited information is the request information; Alternatively, when the request message is an intermediate segment of a complete request message, the prohibited information is the request information and the request end character; Alternatively, when the request message is a complete request message, the exclusion information indicates that it is prohibited to carry multiple request information and multiple request terminators.

10. An access control method, characterized in that: The method comprises: The gateway device receives a request message from the client device, the request message including a target token and target information, the target token including a token description and a first authorization code, the token description including an authorization vector, and the authorization vector indicating the target information; The gateway device generates a second authorization code based on the token description, the target information, and a keyed hash function; When the second authorization code is the same as the first authorization code, the gateway device forwards the request message to the data server.

11. The method according to claim 10, characterized in that The authorization vector includes an offset value and length information, wherein the offset value indicates a starting position of the target information, and the length information indicates a length of the target information; Alternatively, the authorization vector includes a bit map, and the bit map indicates a field carrying the target information.

12. The method according to claim 10 or 11, characterized in that The target information includes at least one of the following: network layer information, transport layer information, authorization request start character, request end character, requester description information, or responder description information corresponding to the target resource, and the target resource is the resource to be accessed by the client device.

13. The method according to claim 12, characterized in that The authorization request initiator includes request information and a partial or complete URL prefix of the target resource, and the request information indicates an operation related to the target resource.

14. The method according to claim 12, characterized in that The network layer information includes a source Internet Protocol (IP) address and a destination IP address; The transport layer information includes a destination port, or includes a destination port and a source port; The description information of the requesting party includes at least one of the following: identity information of the requesting party, status information of the requesting party, group identifier of the requesting party, security level of the requesting party, or network type of the network where the requesting party is located; The responder description information includes at least one of the following: a group identifier of the responder, a security level of the responder, or a network type of a network where the responder is located.

15. The method according to claim 10 or 11, characterized in that The token description also includes a validity period and at least one of: a check policy, an issuer identifier, a cipher suite, or exclusion information; Among them, the validity period indicates the validity period of the target token; the inspection policy indicates whether the requester of the target resource is trusted; the issuer identifier indicates the device that issues the target token; the cryptographic suite indicates relevant information of the cryptographic hash function; and the exclusion information indicates prohibited information.

16. The method according to claim 15, characterized in that The method further comprises: The gateway device determines that the target token has not expired based on the validity period of the target token.

17. The method according to claim 15, characterized in that The method further comprises: The gateway device determines, according to the inspection policy, a requester that trusts the target resource; Alternatively, the gateway device determines that the requester of the target resource is not trusted according to the inspection policy, and determines that the request message is legal according to the exclusion information.

18. The method according to claim 17, characterized in that The gateway device determines, according to the exclusion information, that the request message is legal, including: when the request message does not carry the prohibited information, the gateway device determines that the request message is legal.

19. The method according to any one of claims 16 to 18, characterized in that: When the exclusion information is a first value, the prohibited information is a payload; When the exclusion information is a second value, the prohibited information is the request terminator; When the exclusion information is a third value, the prohibited information is the request information; When the exclusion information is a fourth value, the prohibited information is the request information and the request terminator; When the exclusion information is a fifth value, it indicates that it is prohibited to carry multiple request information and multiple request terminators.

20. An access control method, characterized in that: The method comprises: The client device sends token application information to the authorization server, where the token application information is used to apply for a target token; The client device obtains the target token, the target token including a token description and a first authorization code, the token description including an authorization vector, the authorization vector indicating target information, the first authorization code being generated based on the token description, the target information, and a cryptographic hash function; The client device sends a request message, where the request message includes the target token and the target information.

21. The method according to claim 20, characterized in that The authorization vector includes an offset value and length information, wherein the offset value indicates a starting position of the target information, and the length information indicates a length of the target information; Alternatively, the authorization vector includes a bit map, and the bit map indicates a field carrying the target information.

22. The method according to claim 20 or 21, characterized in that The target information includes at least one of the following: network layer information, transport layer information, authorization request start character, request end character, requester description information, or responder description information corresponding to the target resource, and the target resource is the resource to be accessed by the client device.

23. The method according to claim 22, characterized in that The authorization request initiator includes request information and a partial or complete URL prefix of the target resource, and the request information indicates an operation related to the target resource.

24. The method according to claim 22, characterized in that The network layer information includes a source Internet Protocol (IP) address and a destination IP address; The transport layer information includes a destination port, or includes a destination port and a source port; The description information of the requesting party includes at least one of the following: identity information of the requesting party, status information of the requesting party, group identifier of the requesting party, security level of the requesting party, or network type of the network where the requesting party is located; The responder description information includes at least one of the following: a group identifier of the responder, a security level of the responder, or a network type of a network where the responder is located.

25. The method according to claim 22, wherein The client device obtains a target token, including: The client device searches for the target token according to the authorization request initiator corresponding to the target resource and the corresponding relationship between the authorization request initiator and the token.

26. The method according to claim 20 or 21, characterized in that The token description also includes a validity period and at least one of: a check policy, an issuer identifier, a cipher suite, or exclusion information; Among them, the validity period indicates the validity period of the target token; the inspection policy indicates whether the requester of the target resource is trusted; the issuer identifier indicates the device that issues the target token; the cryptographic suite indicates the relevant information of the cryptographic hash function; and the exclusion information indicates the information that is prohibited from being carried.

27. The method according to claim 26, characterized in that When the request message is used to request establishment of a Transmission Control Protocol (TCP) connection corresponding to the target resource, the prohibited information is a payload; Alternatively, when the request message is the starting segment of a complete request message, the prohibited information is the request end character; Alternatively, when the request message is the last segment of a complete request message, the prohibited information is the request information; Alternatively, when the request message is an intermediate segment of a complete request message, the prohibited information is the request information and the request end character; Alternatively, when the request message is a complete request message, the exclusion information indicates that it is prohibited to carry multiple request information and multiple request terminators.

28. The method according to claim 20 or 21, characterized in that The token application information includes at least one of the following: network layer information, transport layer information, application layer information, requester description information, or requirement information corresponding to the target resource; the application layer information includes at least one of the following: the URL of the target resource, request information, or request terminator; the requirement information indicates at least one of the following: the expected token usage time, whether the complete request message is segmented, and whether a TCP connection is established.

29. A communication device, characterized in that: The communication device includes: a processor and a memory; The memory is used to store computer programs or instructions; The processor is configured to execute the computer program or instruction to implement the method according to any one of claims 1 to 9, or to implement the method according to any one of claims 10 to 19.

30. A communication device, characterized in that: The communication device includes: a processor and a memory; The memory is used to store computer programs or instructions; The processor is configured to execute the computer program or instructions to implement the method according to any one of claims 20 to 28.

31. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program or instruction. When the computer program or instruction is executed by the communication device, the method according to any one of claims 1 to 9 is implemented, or the method according to any one of claims 10 to 19 is implemented.

32. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program or instruction. When the computer program or instruction is executed by the communication device, the method according to any one of claims 20 to 28 is implemented.

Images