WO2023065969A1

WO2023065969A1 - Access control method, apparatus, and system

Info

Publication number: WO2023065969A1
Application number: PCT/CN2022/120910
Authority: WO
Inventors: 陈博; 刘冰洋; 江伟玉; 王闯
Original assignee: 华为技术有限公司
Priority date: 2021-10-20
Filing date: 2022-09-23
Publication date: 2023-04-27
Also published as: CN115996122A

Abstract

The present application provides an access control method, apparatus, and system, which allows for efficient and flexible access control, thereby reducing data leakage. The method comprises: an authorization server issues a token to a client device on the basis of an application from the client device, the token comprising a token description and a first authorization code, the token description comprising an authorization vector, the authorization vector indicating target information, and the first authorization code being generated according to the token description, the target information, and a cryptographic hash function; when sending a request packet, the client device carries the token and the target information in the request packet; after receiving the request packet, a gateway device generates a second authorization code according to the token description, the target information, and the cryptographic hash function, and forwards the request packet to a data server when the second authorization code is the same as the first authorization code.

Description

Access control method, device and system

This application claims the priority of a Chinese patent application with application number 202111223457.5 and application title "Access Control Method, Device and System" filed with the State Intellectual Property Office on October 20, 2021, the entire contents of which are incorporated by reference in this application middle.

technical field

The embodiments of the present application relate to the communication field, and in particular, to an access control method, device and system.

Background technique

With the wide popularization of the network, new software application models emerge in an endless stream, which greatly affects and changes the way people work and live, and increases people's dependence on network information. However, due to the complexity of the network itself, wide accessibility and other factors, the network is facing increasing security threats, and security issues have become increasingly prominent.

Currently, an important security issue is data leakage due to unauthorized access. Exemplarily, as shown in FIG. 1 , in a campus network scenario, normal employees in the internal area of the campus normally access internal data, while malicious employees access data centers with unauthorized access, resulting in data leakage. In addition, normal users in the external area of the park normally access public data, while malicious hackers have unauthorized access to internal data, resulting in data leakage. Therefore, it is necessary to implement reasonable access control to prevent data leakage caused by unauthorized access.

Contents of the invention

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

In the first aspect, an access control method is provided, which can be executed by an authorization server, or by components of the authorization server, such as processors, chips, or chip systems, etc., or can be implemented by all or part of the authorization server. A logical module or software implementation of a function. Taking the method executed by the authorization server as an example, the method includes: the authorization server receives the token application information for applying for the target token from the client device, generates the target token according to the token application information, and sends the client The device sends the target token. 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, target information, and a password hash function.

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. Target information, so that after receiving the request message, 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, and generate the second authorization code. According to whether the first authorization code and the second authorization code are compared Consistent access control, for example, allowing access when the second authorization code is consistent with the first authorization code, and denying access when the second authorization code is inconsistent with the first authorization code, thereby preventing data leakage.

With reference to the first aspect, in some implementation manners of the first aspect, the target information is information to be carried in a request packet 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.

Based on this embodiment, the information in the request message is used to participate in the calculation of the authorization code, and subsequent token verification can prevent illegal requests from being sent using the target token. For example, when an illegal user uses the target token to send a request, since the calculation of the authorization code needs the information in the request message to participate, if he wants to pass the token verification, he needs to falsify the target information in the request message at the same time. The information falsification in this article may not be able to complete the illegal request of illegal users, so the target token of this application can be used freely within the scope of authorization without worrying about theft, which can further improve security performance.

With reference to the first aspect, in some 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 Bitmap, the bitmap indicates the fields that carry the target information.

With reference to the first aspect, in some implementations of the first aspect, the target information includes at least one of the following: network layer information corresponding to the target resource, transport layer information, authorization request initiator, request end identifier, requester description information , or responder description information, the target resource is the resource to be accessed by the client device.

Based on this embodiment, the content included in the target information can be adjusted as needed, so as to flexibly adjust the granularity of access control, and realize multi-level and refined access control. For example, the target information can include information at the network layer to implement access control at the network layer, or the target information can include information at the network layer, transport layer, and application layer to achieve fine-grained control at the URL level, or the target information can include the requester or The responder describes information to implement access control on security level, network type, etc.

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

When the requirement information indicates that the complete request message is not segmented, the target information includes network layer information, transport layer information, authorization request initiator, and request end identifier corresponding to the target resource;

When the requirement information indicates a complete request message segment, the target information includes the first sub-target information corresponding to the initial segment of the complete request message, the second sub-target information corresponding to the middle segment of the complete request message, and the complete The third sub-target information corresponding to the end segment of the request message. The first sub-object information includes network layer information, transport layer information, and authorization request initiator; the second sub-object information includes network layer information and transport layer information; the third sub-object information includes network layer information, transport layer information, and Request terminator.

With reference to the first aspect, in some embodiments of the first aspect, the authorization request initiator includes request information and part or all of the Uniform Resource Locator URL prefix of the target resource, and the request information indicates operations related to the target resource.

With reference to the first aspect, in some implementations of the first aspect, the authorization server generates the target token according to the token application information, including: the authorization server determines the requester's access authority according to the requester description information in the token application information ; and determine the authorization request initiator according to the requester's access rights.

With reference to the first aspect, in some 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 Including at least one of the following: identity information of the requesting party, status information of the requesting party, group identification of the requesting party, security level of the requesting party, or network type of the network where the requesting party is located; description information of the responding party includes at least one of the following: The group ID of the responder, the security level of the responder, or the network type of the network where the responder is located.

In conjunction with the first aspect, in some implementations of the first aspect, the token description further includes a validity period and at least one of the following: checking policy, issuer ID, cipher suite, or exclusion information; wherein the validity period indicates the target token's The validity period; the check policy indicates whether to trust the requester of the target resource; the issuer ID indicates the device that issued the target token; the cipher suite indicates information about the cryptographic hash function; and the exclusion information indicates information that is prohibited from being carried.

Based on the token description of this embodiment, the execution point of the access control policy can be further verified according to the validity period, inspection policy, exclusion information, etc., and the security performance can be further improved.

In combination with the first aspect, in some implementations of the first aspect, when the request message is used to request the establishment of a transmission control protocol TCP connection corresponding to the target resource, the prohibited information is the payload; or, the request message is a complete request message When the initial segment of the message, the prohibited information is the request end character; or, when the request message is the end segment of the complete request message, the prohibited information is the request information; or, the request message is the complete request message When the middle segment of the text is used, the prohibited information is the request information and the request terminator; or, 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 the second aspect, an access control method is provided, which can be executed by a gateway device, or by a component of the gateway device, such as a processor, a chip, or a chip system, etc., and can also be implemented by all or part of the gateway device A logical module or software implementation of a function. Taking the method performed 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 includes a token description and a first authorization code, and the token The description includes the authorization vector, and the authorization vector indicates the target information; then, the gateway device generates a second authorization code according to the token description, target information, and secret key hash function; when the second authorization code is the same as the first authorization code, the gateway device sends The data server forwards the request message.

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, and the authorization vector indicates the target information participating in the calculation of the authorization code, thus After receiving the request message, the gateway device can obtain the information involved in the calculation of the authorization code (that is, the target information) based on the authorization vector, and generate a second authorization code, and perform access based on whether the first authorization code and the second authorization code are consistent. Controlling, forwarding the request message to the data server when the second authorization code is consistent with the first authorization code, thereby preventing data leakage.

On the other hand, the gateway device does not need to maintain access control policies or access control lists. Compared with the existing ACL and firewall solutions, it can be deployed flexibly, reducing the cost of deployment and use.

On the other hand, the gateway device does not need to analyze the application layer semantics of the request message, and does not need to query the access control policy and user information. Scale decoupling enables efficient access control.

With reference to the second aspect, in some 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 Bitmap, the bitmap indicates the fields that carry the target information.

With reference to the second aspect, in some implementations of the second aspect, the target information includes at least one of the following: network layer information corresponding to the target resource, transport layer information, authorization request initiator, request end identifier, requester description information , or responder description information, the target resource is the resource to be accessed by the client device.

With reference to the second aspect, in some implementations of the second aspect, the authorization request initiator includes request information and a part or all of the Uniform Resource Locator URL prefix of the target resource, and the request information indicates operations related to the target resource.

In conjunction with the second aspect, in some implementations of the second 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 Including at least one of the following: identity information of the requesting party, status information of the requesting party, group identification of the requesting party, security level of the requesting party, or network type of the network where the requesting party is located; description information of the responding party includes at least one of the following: The group ID of the responder, the security level of the responder, or the network type of the network where the responder is located.

In conjunction with the second aspect, in some implementations of the second aspect, the token description further includes a validity period and at least one of the following: checking policy, issuer ID, cipher suite, or exclusion information; wherein the validity period indicates the target token's The validity period; the check policy indicates whether to trust the requester of the target resource; the issuer ID indicates the device that issued the target token; the cipher suite indicates information about the cryptographic hash function; and the exclusion information indicates information that is prohibited from being carried.

With reference to the second aspect, in some implementation manners of the second aspect, the method further includes: the gateway device determines that the target token has not expired according to the validity period of the target token. Based on this embodiment, by checking the validity period, it is possible to prevent illegal users from using expired tokens to send requests.

With reference to the second aspect, in some implementation manners of the second aspect, the method further includes: the gateway device determines, according to the inspection policy, that the requester of the target resource is trusted; or, the gateway device determines, according to the inspection policy, that the requester of the target resource is not trusted, And determine that the request message is legal according to the exclusion information.

With reference to the second aspect, in some implementations of the second aspect, the gateway device determines that the request message is legal according to the exclusion information, including: when the request message does not carry prohibited information, the gateway device determines that the request message is legal.

Based on this embodiment, according to the inspection of exclusion information, it is possible to prevent illegal users from sending illegal requests using legitimate tokens, for example, prevent illegal users from sending HTTP requests using TCP connection tokens, thereby performing stricter access control and improving network security .

In conjunction with the second aspect, in some implementations of the second aspect, when the exclusion information is the first value, the prohibited information is the payload; when the exclusion information is the second value, the prohibited information is the request terminator; the exclusion information When it is the third value, the prohibited information is the request information; when the excluded information is the fourth value, the prohibited information is the request information and the request terminator; when the excluded information is the fifth value, it indicates that it is forbidden to carry multiple request information and Multiple request terminators.

With reference to the second aspect, in some implementation manners of the second aspect, the method further includes: the gateway device extracts target information from the request message according to the authorization vector.

Wherein, for the technical effects brought about by the various implementations of the second aspect, reference may be made to the technical effects brought about by the corresponding implementations in the first aspect above, and details are not repeated here.

In the third aspect, an access control method is provided, which 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, etc., and can also be implemented by all or part of the Logical modules or software implementations of client device functionality. Taking this method performed by a client device as an example, the method includes: the client device sends token application information for applying for a target token to the authorization server, then obtains the target token, and sends a request message, and the request message The text includes target token and target 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, target information, and a password hash function.

Based on this solution, the authorization server issues a token to the client device based on the application of the client device, and the client device carries the token when sending a request message. The token includes a token description and a first authorization code, and the token description includes an authorization vector, which indicates the target information involved in the calculation of the authorization code, so that after receiving the request message, the gateway device or the data server side can The vector obtains the information involved in the calculation of the authorization code, and generates the second authorization code, and performs access control based on whether the first authorization code is consistent with the second authorization code, for example, access is allowed when the second authorization code is consistent with the first authorization code , deny access when the second authorization code is inconsistent with the first authorization code, thereby preventing data leakage.

With reference to the third aspect, in some 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 Bitmap, the bitmap indicates the fields that carry the target information.

In conjunction with the third aspect, in some embodiments of the third aspect, the target information includes at least one of the following: network layer information corresponding to the target resource, transport layer information, authorization request initiator, request end identifier, requester description information , or responder description information, the target resource is the resource to be accessed by the client device.

With reference to the third aspect, in some implementations of the third aspect, the authorization request initiator includes request information and part or all of the Uniform Resource Locator URL prefix of the target resource, and the request information indicates operations related to the target resource.

In conjunction with the third aspect, in some implementations of the third 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; requester description information Including at least one of the following: identity information of the requesting party, status information of the requesting party, group identification of the requesting party, security level of the requesting party, or network type of the network where the requesting party is located; description information of the responding party includes at least one of the following: The group ID of the responder, the security level of the responder, or the network type of the network where the responder is located.

With reference to the third aspect, in some implementations of the third aspect, the client device acquires the target token, including: the client device according to the authorization request initiator corresponding to the target resource, and the authorization request initiator and token Correspondence, find the target token.

In conjunction with the third aspect, in some implementations of the third aspect, the token description further includes a validity period and at least one of the following: checking policy, issuer ID, cipher suite, or exclusion information; wherein the validity period indicates the target token's The validity period; the check policy indicates whether to trust the requester of the target resource; the issuer ID indicates the device that issued the target token; the cipher suite indicates information about the cryptographic hash function; and the exclusion information indicates information that is prohibited from being carried.

In conjunction with the third aspect, in some implementations of the third aspect, when the request message is used to request the establishment of a transmission control protocol TCP connection corresponding to the target resource, the prohibited information is the payload; or, the request message is a complete request message When the initial segment of the message, the prohibited information is the request end character; or, when the request message is the end segment of the complete request message, the prohibited information is the request information; or, the request message is the complete request message When the middle segment of the text is used, the prohibited information is the request information and the request terminator; or, 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.

With reference to the third aspect, in some 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 demand 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 to establish a TCP connection .

Wherein, for the technical effects brought about by the various implementations of the third aspect, reference may be made to the technical effects brought about by the corresponding implementations in the first aspect above, and details are not repeated here.

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

In some possible designs, the communication device may include a transceiver module and a processing module. The transceiver module, which may also be referred to as a transceiver unit, is configured to implement the sending and/or receiving functions in any of the above aspects and any possible implementation manners thereof. The transceiver module may be composed of a transceiver circuit, a transceiver, a transceiver or a communication interface. The processing module may be used to implement the processing functions in any of the above aspects and any possible implementation manners thereof.

In some possible designs, the transceiver module includes a sending module and a receiving module, respectively configured to implement the sending and receiving functions in any of the above aspects and any possible implementations thereof.

In a fifth aspect, a communication device is provided, including: a processor and a communication interface; the communication interface is used to communicate with modules other than the communication device; the processor is used to execute computer programs or instructions, so that the communication device Perform the method described in any one of the above aspects. The communication device may be the authorization server in the first aspect, or a device included in the authorization server, such as a chip or a module; or, the communication device may be the gateway device in the second aspect, or a device included in the gateway device, such as a chip or a module; or, the communication device may be the client device in the third aspect, or a device included in the client device, such as a chip.

In a sixth aspect, a communication device is provided, including: an interface circuit and a processor, the interface circuit is a code/data read and write interface circuit, and the interface circuit is used to receive computer-executed instructions (computer-executed instructions are stored in a memory, possibly read directly from the memory, or possibly through other devices) and transmit to the processor; the processor is used to execute computer-executed instructions to enable the communication device to perform the method described in any aspect above. The communication device may be the authorization server in the first aspect, or a device included in the authorization server, such as a chip or a module; or, the communication device may be the gateway device in the second aspect, or a device included in the gateway device, such as a chip or a module; or, the communication device may be the client device in the third aspect, or a device included in the client device, such as a chip.

In a seventh aspect, a communication device is provided, including: at least one processor; the processor is configured to execute computer programs or instructions, so that the communication device executes the method described in any aspect above. The communication device may be the authorization server in the first aspect, or a device included in the authorization server, such as a chip or a module; or, the communication device may be the gateway device in the second aspect, or a device included in the gateway device, such as a chip or a module; or, the communication device may be the client device in the third aspect, or a device included in the client device, such as a chip.

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

In some possible designs, the communication device may be a chip or system-on-a-chip. When the device is a system-on-a-chip, it may consist of chips, or may include chips and other discrete devices.

In an eighth aspect, a computer-readable storage medium is provided, and instructions are stored in the computer-readable storage medium. When the computer-readable storage medium is run on a communication device, the method described in any one of the above aspects is executed.

In a ninth aspect, there is provided a computer program product including instructions, which, when run on a communication device, enable the method described in any one of the above aspects to be executed.

It can be understood that when the communication device provided by 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.

Wherein, the technical effect brought by any one of the design methods from the fourth aspect to the ninth aspect can refer to the technical effects brought by the different design methods in the above-mentioned first aspect or the second aspect or the third aspect, and no longer repeat.

In a tenth aspect, a communication system is provided, and the communication system includes the authorization server, the gateway device, and the client device described in the above aspect.

Description of drawings

Fig. 1 is a schematic diagram of normal access and unauthorized access in a campus network;

FIG. 2 is a schematic diagram of access control based on an access control list;

FIG. 3 is a schematic diagram of access control based on a firewall;

Fig. 4 is a schematic diagram of access control based on JWT;

Fig. 5 is a schematic diagram of access control based on network cookies;

FIG. 6a is a schematic structural diagram of a communication system applicable to the present application;

FIG. 6b is a schematic diagram of an access control provided by the present application;

FIG. 7 is a schematic flowchart of an access control method provided by the present application;

FIG. 8 is a schematic diagram of the types of parameters included in target information provided by the present application;

FIG. 9 is a schematic diagram of the types of parameters included in target information provided by the present application;

Fig. 10a is a schematic diagram of the types of parameters included in the target information provided by the present application;

Fig. 10b is a schematic diagram of the types of parameters included in the target information provided by the present application;

Fig. 10c is a schematic diagram of the types of parameters included in the target information provided by the present application;

Figure 11a is a schematic diagram of the format of a token provided by this application;

Figure 11b is a schematic diagram of the format of another token provided by this application;

FIG. 12a is a schematic structural diagram of an IP packet load provided by the present application;

FIG. 12b is a schematic structural diagram of an IP packet load provided by the present application;

FIG. 12c is a schematic structural diagram of an IP packet load provided by the present application;

FIG. 12d is a schematic structural diagram of an IP packet load provided by the present application;

Figure 13a is a schematic diagram of the format of a token provided by this application;

Figure 13b is a schematic diagram of the format of another token provided by this application;

Figure 14 is a schematic diagram of a token verification process provided by this application;

Fig. 15 is a schematic diagram of a sub-sub-process of checking token validity provided by the present application;

FIG. 16 is a schematic diagram of a client deployment method provided by this application;

FIG. 17 is a schematic flow diagram of an access control method when deploying request proxy middleware provided by the present application;

FIG. 18 is a schematic structural diagram of a communication device provided by the present application;

FIG. 19 is a schematic structural diagram of another communication device provided by the present application.

Detailed ways

In the description of this application, unless otherwise specified, "/" means that the objects associated with each other are an "or" relationship, for example, A/B can mean A or B; "and/or" in this application is only It is an association relationship describing associated objects, which means that there can be three kinds of relationships, for example, A and/or B, which can mean: A exists alone, A and B exist at the same time, and B exists alone, among which A, B Can be singular or plural.

In the description of the present application, unless otherwise specified, "plurality" means two or more than two. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one item (piece) of a, b, or c can represent: a, b, c, a and b, a and c, b and c, a and b and c, where a, b, c Can be single or multiple.

In addition, in order to clearly describe 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 the same or similar items with basically the same function and effect. Those skilled in the art can understand that words such as "first" and "second" do not limit the number and execution order, and words such as "first" and "second" do not necessarily limit the difference. Meanwhile, in the embodiments of the present application, words such as "exemplary" or "for example" are used as examples, illustrations or illustrations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of the present application shall not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. To be precise, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete manner for easy understanding.

It is to be understood that references to "an embodiment" throughout the specification mean that a particular feature, structure, or characteristic related to the embodiment is included in at least one embodiment of the present application. Thus, the various embodiments throughout the specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments. It can be understood that in various embodiments of the present application, the serial numbers of the processes do not mean the order of execution, and the execution order of the processes should be determined by their functions and internal logic, and should not be used in the embodiments of the present application. The implementation process constitutes no limitation.

It can be understood that in this application, "...when" and "if" both refer to the corresponding processing under certain objective circumstances, and are not time-limited, nor do they require that there must be an action of judgment when it is realized. No other limitations are implied.

It can be understood that some optional features in the embodiments of the present application, in some scenarios, can be independently implemented without relying on other features, such as the current solution on which they are based, to solve corresponding technical problems and achieve corresponding effects , and can also be combined with other features according to requirements in some scenarios. Correspondingly, the devices provided in the embodiments of the present application can also correspondingly implement these features or functions, which will not be repeated here.

In this application, unless otherwise specified, the parts that are the same or similar among the various embodiments can be referred 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 description and logical conflict, different embodiments, and each implementation method/implementation method in each embodiment The terms and/or descriptions between implementation methods/implementation methods are consistent and can be referred to each other. Different embodiments, and the technical features in each implementation manner/implementation method/implementation method in each embodiment are based on their inherent Logical relationships can be combined to form new embodiments, implementation modes, implementation methods, or implementation methods. The following embodiments of the present application are not intended to limit the protection scope of the present application.

As a widely used data transfer protocol, Hypertext Transfer Protocol (HTTP) is the key to access control. At present, the methods for HTTP access control are mainly divided into the following five categories:

The first type of solution is to deploy access control list (access control list, ACL) services on the data plane of the network layer (such as routers/switches), and its principle is shown in Figure 2. First, the authorization server formulates an access control policy from the client address to the data server address, and generates ACL entries. Then perform ACL configuration, that is, send the ACL entry to the gateway through a specific transmission protocol, software, or an out-of-band method. Finally, when the gateway receives the data request from the client, it searches and matches the ACL rules by querying the ACL entries. If the ACL match passes, the data request is forwarded to the data server; if the ACL match fails, the data request is discarded.

Optionally, the ACL entry may include an ACL number (ACL Number) and one or more rules (rule). Each rule includes a rule identifier (identifier, ID), that is, rule ID, access policy (permit/deny), source address, destination address, and effective time range wait. Exemplarily, a specific ACL entry can be as follows:

acl number 2000

rule 5 permit source 10.108.234.100 destination 10.108.234.114 time-range time 1

rule 10 permit source 10.108.234.101 destination 10.108.234.114 time-range time 2

…

However, it can be seen from the above introduction that when access control is performed based on ACL, the control granularity is relatively coarse. It is limited by the expression of ACL rules and the limited information that the network layer can obtain. At most, it can only perform access control at the network quintuple level (ie, source address, destination address, source port, destination port, protocol), that is, HTTP Access control at the data server address level cannot be fine-tuned at the HTTP Uniform Resource Locator (URL) level. On the other hand, ACL entries grow individually and are dependent on each other, making it difficult to delete and other operations. At the same time, ACL entries are bound to addresses, which is very inflexible when address changes and migration deployments are performed, making update and maintenance difficult. On the other hand, the search and storage of ACL entries generally require the use of special hardware, which is highly dependent on the hardware and requires high deployment and use costs.

The second type of solution is firewall-based access control, which mainly implements request filtering and connection blocking by deploying a firewall. The basic principle is shown in Figure 3. Mainly through the dedicated software and hardware deployed on the firewall device, the information of each layer of the message is analyzed, and many functions such as access policy enforcement, content audit monitoring, and harmful traffic filtering can be realized. When the firewall receives the request from the client, it can execute the access policy, and if the request is legal, it will forward the request to the data server; if the request is not legal, it will discard the request.

The access control granularity and scope of the firewall are very flexible, and it is one of the main methods of access control in the current campus network. However, the firewall-based access control scheme is implemented by the logic of the data plane. It needs to deploy special equipment and software to analyze the information of each layer of the network. The complexity is high, and the communication overhead and computing overhead are relatively large.

The third type of scheme is based on application layer token (token) access control. The fine-grained access control of data is mainly carried out through the application layer token issued by the server. The basic principle is shown in Figure 4. First, the user logs in to the server on the client side and initiates a request. The server (Figure 4 takes the data server as an example, and it can also be a trusted authorization server) verifies the username and password, and issues tokens with corresponding permissions according to user permissions, such as JSON network tokens ( JSON web token, JWT), returned to the client. Subsequently, the client stores the token from the server, and embeds the token in the header (usually the Authorization header) of the HTTP request when the request is initiated. After the data server receives the request, it extracts the token and uses methods such as querying the database or signature verification to verify the legitimacy of the token. If the token is legal, the request will be responded to, and if the token is not valid, the request will be rejected.

However, the above token-based access control needs to consume resources on the data server side for permission verification, and cannot intercept illegal requests before reaching the data server, and cannot block the establishment of unauthorized request connections.

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 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 (access proxy) acts as a backward proxy and is the logic center for the first stage of access policy enforcement. It is used to complete functions such as user/device authentication, credential uninstallation, and sending requests to the backend. , you can deploy ACL to implement 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.

As a systematic solution, the access control solution based on zero trust architecture has a high cost of deployment and overhead; in addition, this solution is more about the integration and use of existing access control technologies (such as JWT, ACL engine), and does not Solve the problems existing in the related technology itself.

The fifth type of scheme is a scheme based on network cookies. The basic framework of the Network cookies system is shown in Figure 5. The client requests a cookie descriptor (descriptor) from the cookie server (server) according to its own needs (for example, to access resources). Exemplarily, the information included in the cookie descriptor is as follows:

After the client obtains the cookie descriptor, it can locally generate the cookie carried when sending the message. Exemplarily, the information included in the cookie is as follows:

When the switch or middleware receives the cookie-carrying message sent by the client, it searches for the signature key according to the cookie_id, and uses the signature key to calculate the cookie digest, and compares the calculated cookie digest with the cookie's own signature. If the two are the same, further verification is performed according to the cookie timestamp, and if the verification passes, the message is forwarded to the data server, so that the data server provides services corresponding to the cookie_descriptor.

In the solution based on network cookies, the method of generating cookies locally after the client obtains the cookie descriptor is adopted. However, the cookie descriptor needs to be synchronized between the client, the cookie server, and the switch/middleware. When the number of clients increases, the communication and storage complexity of synchronizing cookie descriptor between client-cookie server-switch/middleware will increase linearly.

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 validity of the cookie will increase linearly.

On the other hand, cookie verification is only done through the cookie itself and the information stored in the switch/middleware. If HTTP access control is implemented, there may be cases where illegal users use legitimate cookies to send unauthorized HTTP requests. There will be security gaps in the environment.

It can be seen from the above that there are various problems in the current access control method. Based on this, the present application provides an access control method, which can perform access control reasonably, efficiently and flexibly, thereby reducing data leakage.

It can be understood that the method provided by 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 (file transfer protocol, FTP).

Fig. 6a is a schematic structural diagram of a communication system 600 applied by an embodiment of the present application. As shown in FIG. 6 a , 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 .

Optionally, the authorization server is a setting point for access control policies, such as issuing tokens. Data servers are responders for data or resources. The gateway device is the execution point of the access control policy, for example, for token verification; or, the execution point of the access control policy may also be the data server, that is, the token verification can be performed on the data server side.

Based on the communication system 600, as shown in Figure 6b, 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 token application information to the authorization server, and then the authorization server Return the target token to the client device. When the client device sends the request message, it sends the target token in the request message. The gateway device verifies the legitimacy of the token after receiving the request message, and forwards the request message to the data server when the token is legal. Subsequently, the data server may send a response to the request message.

When the data server is used as the execution point of the access control policy, the gateway device can directly forward the request message to the data server after receiving the request message, and the data server will perform token verification, and can send the request message to the client device when the token is valid. response. The detailed description of the above solutions will be described in subsequent embodiments, and will not be repeated here.

Optionally, the authorization server and the data server may be an application server or a personal computer (personal computer, PC). The gateway device may be a network device capable of forwarding data packets, such as a router and a switch.

Optionally, the client device may be a terminal device with a communication function. Exemplarily, the client device may be: an Internet of Things (Internet of Things, IoT) device (for example, a sensor, an electric meter, a water meter, etc.), a vehicle networking (vehicle to everything, V2X) device, a wireless local area network (wireless local area networks, Station (station, ST) in WLAN), personal digital assistant (PDA) equipment, handheld equipment (such as mobile phone) with wireless communication function, computing equipment or other processing equipment connected to a wireless modem, vehicle equipment, Wearable devices (also called wearable smart devices), tablet computers or computers with wireless transceiver functions, etc.

It should be noted that the communication system described in the embodiment of the present application is to illustrate the technical solutions of the embodiments of the present application more clearly, and does not constitute a limitation to the technical solutions provided in the embodiments of the present application. With the evolution of the network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

The method provided in the embodiment of the present application will be described below with reference to the accompanying drawings. It can be understood that in the embodiments of the present application, the executive body may perform some or all of the steps in the embodiments of the present application, these steps or operations are only examples, and the embodiments of the present application may also perform other operations or variations of various operations. In addition, each step may be performed in a different order presented in the embodiment of the present application, and it may not be necessary to perform all operations in the embodiment of the present application.

It should be noted that the name of each information or parameter in the following embodiments of this application is just an example, and other names may also be used in specific implementations, which are not specifically limited in this embodiment of this application.

As shown in Figure 7, it is an access control method provided by the present application, which includes the following steps:

S701. The client device sends token application information to the authorization server. Correspondingly, the authorization server receives token application information from the client device.

Wherein, the token application information is used to apply for the target token.

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 demand information.

Optionally, the target resource is a resource to be accessed by the client device. The target resource can be any resource on the Internet, and its location on the Internet can be identified by a uniform resource locator (URL). This application refers to The data server provides (or responds to) the target resource as an example for illustration. Exemplarily, a specific URL may be w3.huawei.com/next/indexa.html.

The network layer information may include a source Internet Protocol (internet protocol, IP) address and a 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.

The transport layer information may include a destination port (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.

The application layer information may include at least one of the following: URL of the target resource, request information, and request terminator. The request information indicates the operation related to the target resource, and the URL and the request information can indicate the resource that a certain request wants to access and the metadata to be operated on. Exemplarily, for the HTTP protocol, the request information may be a method (method), such as Get, Post, Connect, etc.; for the FTP protocol, the request information may be a command (command), such as Put, Delete, etc.

Exemplarily, for the HTTP protocol, when there is no request body in the HTTP request, the request terminator can be /r/n/r/n; when there is a request body in the HTTP request, the request terminator can be 0/r/n/r /n. When there is a request body in the HTTP request, the form of the request terminator may be pre-negotiated between the authorization server and the client device, or may be configured or notified by the authorization server to the client device.

The requestor corresponding to the target resource may include a client device and/or a user. The user may log in on the client device as an account (ie, user name), and request to access the target resource. The requester description information corresponding to the target resource may include at least one of the following: identity information of the requester (such as user name and password, certificate of the client device, etc.), status information of the requester (such as a summary of the running state of the client device), The group identifier of the requesting party, the security level of the requesting party, or the network type of the network where the requesting party is located (such as a mobile network or a fixed network).

The requirement information indicates at least one of the following: expected token usage time, whether the complete request message is segmented, and whether a transmission control protocol (transmission control protocol, TCP) connection is established. The TCP connection refers to the TCP connection corresponding to the target resource, or refers to the TCP connection between the client device and the data server. Usually before a certain request, a TCP connection between the client device and the data server needs to be established.

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

S702. The authorization server generates a target token according to the token application information.

Wherein, the target token includes a token description (TokenDescrption) and a first authorization code (AuthCode). The token description includes an authorization vector (AuthVector), which indicates target information. The first authorization code is generated based on the token description, target information, and a cryptographic hash function.

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

AuthVector＝HMAC(TokenDescrption||target information, MasterKey) (1)

Among them, || indicates connection; MasterKey is the key of password hash function, and MasterKey can be generated by the authorization server and updated periodically. In addition, the authorization server can also send the MasterKey to the gateway device or data server for token verification.

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 some 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 with the following formula (2):

AuthVector＝HMAC(TokenDescrption||AuthSegments，MasterKey) (2)

Based on this scheme, the information in the request message is used to participate in the calculation of the authorization code, and subsequent token verification can prevent illegal requests from being sent using the target token. For example, when an illegal user uses the target token to send a request, since the calculation of the authorization code needs the information in the request message to participate, if he wants to pass the token verification, he needs to falsify the target information in the request message at the same time. The information falsification in this article may not be able to complete the illegal request of illegal users, so the target token of this application can be used freely within the scope of authorization without worrying about theft. Compared with the network cookies scheme, it can further improve security performance.

Optionally, the target information may include at least one of the following: network layer information, transport layer information, authorization request initiator, request end identifier, requester description information, or responder description information corresponding to the target resource.

Optionally, the destination IP address in the network layer information included in the destination information may be the complete IP address of the data server, or may be a prefix of the IP address of the data server. When the destination IP is the IP address prefix of the data server, the destination token can be used when accessing multiple data servers under the IP address prefix.

Optionally, the authorization request initiator includes 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 URL of the target resource as w3.huawei.com/next/indexa.html as an example, if the URL prefix part of the target resource in the authorization request initiator is w3.huawei.com, it means that the authorization server is the requester Authorize the relevant operation permissions under the host; if the URL prefix part of the target resource in the authorization request initiator is w3.huawei.com/next, it means that the authorization server grants the requester the relevant operation permissions under the next target in the host. Based on the relevant operation permissions granted to the host, the access scope of the requester is narrowed.

Optionally, the authorization server may determine the requester's access rights according to the requester's description information, and then determine the authorization request initiator according to the requester's access rights. Exemplarily, the authorization server may pre-store or configure the corresponding relationship between the access authority and the requesting party, and after receiving the requesting party description information of the client device, it may obtain the information of the requesting party, and then search for the requesting party according to the corresponding relationship. access rights.

Optionally, the responder is a data server, and the responder description information may include 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. For descriptions of other parameters included in the target information, reference may be made to relevant descriptions in the above-mentioned step S701, and details are not repeated here. Optionally, the authorization server may determine the parameters included in the target information according to the requirement information in the token application information. Exemplary:

When the requirement information indicates to establish a TCP connection, as shown in FIG. 8 , the target information includes network layer information and transport layer information corresponding to the target resource. At this time, the target token may be called a TCP connection token.

When the requirement information indicates that the complete request message is not segmented, as shown in FIG. 9 , the target information includes network layer information, transport layer information, authorization request initiator, and request end identifier corresponding to the target resource. At this point, the target token can be recorded as A_Token.

When the demand information indicates the segment of the complete request message, the target information includes the first sub-target information corresponding to the start 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 end segment. subgoal information. Correspondingly, the target token includes the first sub-target token (denoted as S_Token) corresponding to the start segment, the second sub-target token (denoted as M_Token) corresponding to the middle segment, and the third sub-target token corresponding to the end segment Sub-target token (denoted as E_Token).

Optionally, as shown in FIG. 10a, the initial segment of the complete request message includes an IP header, a TCP header, and a payload (payload), and the payload includes request information, URL, and part of request bytes. The first sub-object information corresponding to the initial segment includes network layer information, transport layer information, and authorization request initiator.

Optionally, as shown in FIG. 10b, the middle segment of the complete request message includes an IP header, a TCP header, and a payload (payload), and the payload includes part of the request bytes. The second sub-object information corresponding to the middle segment includes network layer information and transport layer information.

Optionally, as shown in FIG. 10c, the end segment of the complete request packet includes an IP header, a TCP header, and a payload (payload), and the payload includes a part of request bytes and a request terminator. The third sub-object information corresponding to the end segment includes network layer information, transport layer information, and a request terminator.

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

Based on this solution, the content of the target information can be adjusted as needed, so as to flexibly adjust the granularity of access control and realize multi-level and refined access control. For example, the target information can include information at the network layer to implement access control at the network layer, or the target information can include information at the network layer, transport layer, and application layer to achieve fine-grained control at the URL level, or the target information can include the requester or The responder describes information to implement access control on security level, network type, etc.

Optionally, regarding the way the authorization vector indicates target information:

As a possible implementation, the authorization vector may include offset value (offset) and length (length) information, the offset value indicates the starting position of the target information, and the length information indicates the length of the target information. Exemplarily, the offset value may be an offset of the start position of the target information relative to the start position or end position of the request message. The length information indicates the length from offset.

Optionally, when the target information includes multiple parameters, the grant vector may include multiple offset values and multiple length information, respectively indicating the multiple parameters. For example, the target information includes parameter 1 and parameter 2, and the authorization vector may include offset value 1 and length 1 to indicate the starting position and length of parameter 1, and offset value 2 and length 2 to indicate the starting position and length of parameter 2. start position and length. In this case, for example, the format of the target token may be as shown in FIG. 11a.

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

It can be understood that since the request message has a standardized format, the authorization server can know the format of the request message even if the client device does not send the request message, and then can indicate the target information through the authorization vector.

S703. The authorization server sends the target token to the client device. Accordingly, the client device receives the target token from the authorization server.

Optionally, the authorization server may send the target token to the client device through a secure and trusted channel with the client device.

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

Optionally, the client device may 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 according to the authorization vector of the target token, or it can be sent by the authorization server to the client device, that is, in addition to the target token, the authorization server also sends The end device returns the authorization request initiator corresponding to the target resource.

Afterwards, the above steps S701-S703 may be continued to obtain tokens corresponding to other resources, so as to establish a correspondence table between authorization request initiators and tokens. Exemplarily, the correspondence table may be shown in Table 1 below.

Table 1

Subsequently, when the client device requests to access the target resource or establish a TCP connection corresponding to the target resource, the following step S704 is performed.

S704. The client device acquires the target token.

Optionally, in the case where the client device has established a correspondence table between the authorization request initiator and the token, the acquisition and use of the target token are decoupled, that is, the client device can request the target token from the authorization server in advance and Store and use the target token when a request message needs to be sent. At this point, step S704 may include: searching 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.

Optionally, in the case that the client device has not established the correspondence between the authorization request initiator and the token, this step S704 can be understood as the above: the client device receives the target token from the authorization server. After the client device receives the target token from the authorization server, it can be used directly.

S705. The client device sends a request packet. The gateway device receives the request message from the client device. Wherein, the request message includes the target token and target information.

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.

Optionally, the target token can be carried in the network layer header of the request message. The specific position of the target token in the network layer header can be determined according to the specific network layer protocol. Exemplarily, when the network layer protocol is IPv6, the target token can be carried in option fields such as the destination option (destination option) of the network layer header; when the network layer protocol is New IP (NewIP), the target token can carry or in the security option field of the network layer header. Alternatively, the target token can be carried in the application layer of the request message.

Optionally, when the target token is carried in the network layer header of the request message, the execution point of the access control policy may be a gateway device, that is, the gateway device performs token verification. When the target token is carried in the application layer of the request message, the execution point of the access control policy can be the data server, that is, the data server performs token verification.

Optionally, when the request message is used to request to establish a TCP connection corresponding to the target resource, the target token may be a TCP connection token. When the execution point of the access control policy is the gateway device, the use of the TCP connection token enables the unauthorized client device to be identified and filtered when requesting to establish a TCP connection, realizing the first communication between the client device and the data server. Packet interception.

Optionally, taking the target token carried in the network layer header of the request message as an example, the application layer of the client device may generate a complete request message for requesting access to the target resource. Subsequently, the application layer delivers the complete request message to the transport layer, and the transport layer determines whether to perform TCP segmentation on the complete request message, and in the case of TCP segmentation, marks the type of each segment and delivers it to the network layer. After the network layer receives the message from the transport layer, it identifies the segment type and adds the corresponding target token to the network layer header.

Exemplarily, taking an HTTP request message as an example, as shown in Figure 12a, when the HTTP segment (HTTPSeg) is equal to 0, it means that there is no need to segment the HTTP request message, and the load of the IP message includes a complete HTTP request, corresponding to The target token for is A_Token.

As shown in Figure 12b, when HTTPSeg is equal to 1, it indicates the initial segment of the complete request message. The load of the IP message includes the HTTP request initiator (ie method+URL) and the remaining HTTP request part, and the corresponding target token For S_Token.

As shown in Figure 12c, when HTTPSeg is equal to 2, it means the middle segment of the complete request message, the payload of the IP message includes the rest of the HTTP request, and the corresponding target token is M_Token.

As shown in Figure 12d, when HTTPSeg is equal to 3, it means 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.

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.

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 the data server, step S706 is executed by the data server. At this time, before step S706, the gateway device needs to forward the request message to the data server. In FIG. 7, the step S706 performed by the gateway device is taken as an example for illustration.

Optionally, the method of generating the second authorization code by the gateway device or the data server and the key used are the same as those of the authorization server.

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.

Optionally, when the second authorization code is the same (or consistent) with the first authorization code, if step S706 is executed by the gateway device, the following step S707 can be continued; if step S706 is executed by the data server, the following step can be continuously executed Step S708.

Optionally, when the second authorization code is different (or inconsistent) from the first authorization code, the gateway device or the data server may discard the request message. Or, if step S706 is performed by the gateway device, the gateway device can forward the request message to the data server through the first path; or, the gateway device can add a label to the request message, and forward the tagged request message to the data server. server. When the data server receives a request message through the first path or receives a request message with a label, it can know that the request message is a message that fails token verification, and then perform corresponding processing, for example, discard the request message text or respond to partial requests.

Based on this scheme, when the execution point of the access control policy is the gateway device, compared with the existing JWT scheme, the illegal request can be intercepted before reaching the data server.

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

Optionally, the gateway device may forward the request message to the data server through the second path. When the data server receives the request message through the second path, it can know that the request message is a message that passes the token verification, so as to execute the following step S708.

S708. The data server sends a response message to the client device. Correspondingly, the client device receives the response message from the data server. Wherein, the response message is a response to the above request message.

Optionally, after receiving the response message, the client device can perform related processing according to the response message, which is not specifically limited in this application.

In this application, on the one hand, the authorization server issues a token to the client device based on the application of the client device, and the client device carries the token when sending a request message. The token includes a token description and a first authorization code, and the token description includes an authorization vector, which indicates the target information involved in the calculation of the authorization code, so that after receiving the request message, the gateway device or the data server side can The vector obtains the information involved in the calculation of the authorization code, and generates the second authorization code, and performs access control based on whether the first authorization code is consistent with the second authorization code, for example, access is allowed when the second authorization code is consistent with the first authorization code , deny access when the second authorization code is inconsistent with the first authorization code, thereby preventing data leakage.

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 with the gateway device, so that the gateway device does not need to maintain access control policies or access control lists. Compared with the existing ACL and The firewall solution can be deployed flexibly, reducing the cost of deployment and use.

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, and does not need to query the access control policy and user information. Policies and user scales are decoupled to achieve efficient access control.

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: check policy (CheckPolicy), issuer ID (IssuerID), cipher suite (CypherSuit), or exclusion information (Exclude). In this scenario, the format of the target token may be as shown in Figure 13a or Figure 13b.

Optionally, the validity period indicates the limited duration of the target token. The limited period may be determined by the authorization server according to the expected token usage time indicated by the requirement information.

Optionally, the checking policy indicates whether to trust the requester of the target resource, or indicates whether to trust the user of the target token. Exemplarily, when CheckPolicy is set to 0, it means that the requester of the target resource is trusted; when CheckPolicy is set to 1, it means that the requester of the target resource is not trusted. When the global inspection strategy is unique, that is, when all requesters in the network are trusted or distrusted, the inspection strategy can be omitted.

In the above step S702, the authorization server may determine whether to trust the requester of the target resource according to the description information of the requester, so as to set the checking policy. For example, when the client device is authenticated by the authorization server and the user is a trusted user, it is determined to trust the requester of the target resource, and CheckPolicy is set to 0. When the client device is not authenticated by the authorization server or the user is untrustworthy, it is determined that the requester of the target resource is not trusted, and CheckPolicy is set to 1.

Optionally, the issuer identifier indicates the device that issues the target token (referred to as a token issuing device), that is, indicates the authorization server. The enforcement point of the access control policy can look up the relevant information of the token issuing device through this identification. When the token issuing device is globally unique, the issuer ID can be omitted.

Optionally, the cipher suite indicates information about a cryptographic hash function used to calculate the authorization code. The enforcement point of the access control policy can determine the cryptographic information required for token verification according to the cipher suite. For example, the cipher suite may include the identifier of the MasterKey, so that the execution point of the access control policy determines the MasterKey according to the identifier; or, the execution point of the access control policy may also determine the type and length of the cryptographic hash function according to the cipher suite.

Optionally, the exclusion information indicates information that is prohibited from being carried, and the information that is prohibited from being carried is information that is prohibited from being carried in the request message of the client device. In other words, the exclusion information indicates information that cannot appear in the request message. Exclusion information MAY be omitted when the checking policy indicates that the requestor of the target resource is trusted.

Optionally, when the request message is used to request to establish a TCP connection corresponding to the target resource, the prohibited information is payload. At this time, the exclusion information may be set as a first value, for example, the first value may be 0.

When the request message is the initial segment of a complete request message, the prohibited information is the request terminator. At this time, the exclusion information may be set as a second value, for example, the second value may be 1.

When the request message is the end segment of a complete request message, the prohibited information is request information. At this time, the exclusion information may be set as a third value, for example, the third value may be 2.

When the request message is the middle segment of a complete request message, the prohibited information is the request information and the request terminator. At this time, the exclusion information may be set as a fourth value, for example, the fourth value may be 3.

When the request message is a complete request message, the exclusion information indicates that it is forbidden to carry multiple request information and multiple request terminators. At this time, the exclusion information may be set to a fifth value, for example, the fifth value may be 4.

In the above step S702, the authorization server may determine the relevant information of the request message according to the requirement information from the client device, so as to set the exclusion information. For example, when the demand information indicates the establishment of a TCP connection, the request message is used to establish the TCP connection corresponding to the target resource, and the exclusion information can be set to the first value; when the demand information indicates a complete request message segment, the exclusion information corresponding to the initial segment Can be set to a second value, etc.

Optionally, based on the token description above, the execution point of the access control policy can be further verified according to the validity period, inspection policy, and exclusion information. Exemplarily, taking the execution point of the access control policy as the gateway device as an example, Figure 14 is a verification process of the gateway device, as shown in Figure 14, the verification process includes the following steps:

S1401. Determine whether the destination port in the request message is a port corresponding to the target protocol.

Wherein, the target protocol is a protocol currently undergoing access control, such as HTTP protocol or FTP protocol, and of course other transmission protocols, which are not specifically limited in this application.

Optionally, if the destination port is a port corresponding to the target protocol, perform the following step S1402; if the destination port is not a port corresponding to the target protocol, perform other access control procedures. For other access control procedures, this application does not limit, here I won't go into details.

S1402. Determine whether the request message carries the target token.

Optionally, if the request message carries the target token, perform the following step S1403; if the request message does not carry the token, discard the request message.

S1403. Determine whether the target token is expired.

Optionally, the gateway device may acquire the valid period of the target token from the token description, so as to determine whether the target token has expired according to the valid period of the target token. This application assumes that the target token has not expired.

Optionally, if the target token has not expired, execute the token validity checking sub-process shown in Figure 15; if the target token has expired, discard the request message.

S1404. Determine whether the target token is legal according to the output of the token validity checking sub-process.

Optionally, when the token legality checking sub-process outputs the first result, the target token is legal; when the token legality checking sub-process outputs the second result, the target token is invalid. Exemplarily, the first result may be expressed as Y, and the second result may be expressed as N.

Optionally, if the target token is legal, perform the following step S1405; if the target token is invalid, 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 After forwarding to the data server, you can refer to the relevant description in the above step S706, and will not repeat it here.

S1405. Forward the request message to the data server. Reference may be made to relevant descriptions in the above step S707, which will not be repeated here.

Optionally, as shown in Figure 15, the token validity checking sub-process includes the following steps:

S1501. Determine whether to trust the requester of the target resource.

Optionally, the gateway device may determine whether to trust the requester of the target resource according to the check policy in the token description. For example, when the check policy is set to 0, it is determined to trust the requester of the target resource; when the check policy is set to 1, it is determined not to trust the requester of the target resource.

Optionally, if the requester of the target resource is not trusted, perform the following step S1502; if the requester of the target resource is trusted, perform the following step S1503.

S1502. Check the validity of the request message according to the exclusion information.

Optionally, if the request message does not carry the prohibited information indicated by the exclusion information, it is determined that the request message is legal; if the request message carries the prohibited information, the request message is invalid, and the request message can be discarded.

Optionally, as shown in Figure 15, 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 value is four, execute step S15024; when the exclusion information is the fifth value, execute step S15025.

S15021. Check whether the request packet carries a payload.

Optionally, if the request packet does not carry a payload, continue to perform the following step S1503; if the request packet carries a payload, the request packet may be discarded.

S15022. Check whether the request message carries a request terminator.

Optionally, if the request message does not carry a request terminator, continue to perform the following step S1503; if the request message carries a request terminator, the request message may be discarded.

S15023. Check whether the request message carries request information.

Optionally, if the request message does not carry the request information, continue to perform the following step S1503; if the request message carries the request information, the request message may be discarded.

S15024. Check whether the request message carries request information and a request terminator.

Optionally, if the request message does not carry the request information and the request terminator, continue to perform the following step S1503; if the request message carries the request information or the request terminator, the request message may be discarded.

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

Optionally, when the request message carries a single request information and a single request terminator, continue to perform the following step S1503; when the request message carries multiple request information or multiple request terminators, the request message can be discarded.

S1503. Extract target information from the request packet according to the authorization vector. After the target information is extracted, the following step S1504 can be continued.

S1504. Generate a second authorization code according to the token description, target information, and cryptographic hash function.

Optionally, the relevant information of the cryptographic hash function may be determined according to the cryptographic suite in the token description. For the specific implementation of step S1504, reference may be made to the relevant description in the above-mentioned step S706, which will not be repeated here.

S1505. Determine whether the first authorization code is the same as the second authorization code.

Optionally, when the first authorization code is the same as the second authorization, output the first result and return to the process shown in Figure 14; when the first authorization code is different from the second authorization code, output the second result and return to the process shown in Figure 14 process. In FIG. 15 , the first result is expressed as Y and the second result is expressed as N as an example for illustration.

Based on this scheme, by valid period checking, illegal users can be prevented from using expired tokens to send requests. According to the inspection of exclusion information, it can prevent illegal users from sending illegal requests using legal tokens, such as preventing illegal users from sending HTTP requests using TCP connection tokens, so as to implement stricter access control and improve network security.

In the above access control method, the use of tokens involves information interaction and cooperation between the application layer and the network layer, and the existing network model may no longer be applicable. For example, when the token is carried at the network layer, the token application is mainly implemented by the application layer, and the application of the token (such as embedding a message) is mainly implemented by the network layer. The application layer and the network layer need to interact so that the network layer correctly The token is embedded 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 the present application will provide an exemplary deployment manner to support the realization of the solution of the present application.

Optionally, as shown in FIG. 16 , the following three deployment methods can be adopted: 1) deployment based on request proxy middleware; 2) deployment based on a dedicated browser; 3) deployment based on request proxy.

In the first deployment mode, the existing general browser and request proxy middleware can be deployed in the client device, and the request proxy middleware realizes the functions of token proxy application and use. For example, realize the sending of token application information, the establishment of the corresponding relationship between resources and tokens, the segmentation and queue sorting of request messages, forward proxy, and the embedding of tokens into request messages, etc.

Exemplarily, taking HTTP access control and the execution point of the access control policy as the gateway device as an example, the implementation process of the deployment method based on the request proxy middleware can be shown in Figure 17:

The request proxy middleware sets the browser proxy at startup, generates a self-signed certificate, and then issues a self-signed certificate to the browser. Among them, the request proxy middleware can regenerate the self-signed certificate after each startup.

After the browser receives the self-signed certificate, it adds the self-signed certificate to the browser or system trust certificate list, and uses the username and password to log in to the agent.

After the user logs in, the proxy middleware is requested to establish a connection to the authorization server. Exemplarily, the request proxy middleware may have a built-in authorization server to approve the certificate, and encrypt and send relevant information of the request proxy middleware, the client device, and the user to the authorization server. The authorization server can verify the legitimacy of the request agent middleware, the client device, and the user, and establish a connection with the request agent middleware after passing the verification.

Subsequently, the browser sends an HTTP request to the request proxy middleware. After the proxy middleware receives the HTTP request, if the size of the HTTP request is greater than the maximum segment size (MSS) of the TCP packet, the proxy middleware is requested to segment the received HTTP request and build a request queue. If the size of the HTTP request is smaller than the MSS size of the TCP packet, no segmentation is performed.

In addition, the proxy middleware can extract the parameters included in the token application information from the HTTP request, such as network layer information, transport layer information, application layer information, etc., and then send the token application information to the authorization server. The authorization server generates the target token after receiving the token application information, and returns the target token to the request proxy middleware. The target token may include a TCP connection token and A_Token, or may include a TCP connection token, S_Token, M_Token, and E_Token. After receiving the target token, the request proxy middleware establishes the corresponding relationship between resources and tokens.

Afterwards, the request proxy middleware initiates a TCP connection request to the data server, and the TCP connection request carries a TCP connection token. The gateway device forwards the TCP connection request to the data server after verifying that the token is legal. The data server accepts and establishes a TCP connection.

After the TCP connection is established, the request proxy middleware initiates HTTP requests according to the queue order of the request queue, and carries the corresponding token in the HTTP request. For example, in the case of HTTP segmentation, embed the corresponding token in the request according to HTTPSeg token. The gateway device forwards the HTTP request to the data server after verifying that the token is valid. The data server responds to the request. After receiving the response from the data server, the request proxy middleware sends the response to the browser, and the browser receives and parses the response.

As mentioned above, the request proxy middleware has the operation logic of the application layer and the network layer at the same time. When receiving the request message from the application layer, it can query the corresponding token and call the underlying network application program interface (application program interface, API ) or raw sockets, and send the token embedded in the request message.

In the second deployment mode, a dedicated browser can be developed and deployed in the client device, so that the dedicated browser natively supports the above-mentioned functions in the middle of the request agent. Taking HTTP as an example, a dedicated browser needs to parse the user request to construct an HTTP request, and can extract relevant parameters to apply for a token from the authorization server. After receiving the authorization token, select the token corresponding to the HTTP request as a parameter, directly call the underlying network API or raw socket to construct the network layer data packet of the HTTP request, embed the corresponding token into the packet header, and then send it to in the network.

In the third deployment mode, an existing general browser can be deployed in the client device, and a request proxy is deployed independently of the client device. The function of the request proxy is similar to the above-mentioned request proxy middleware. That is to say, the function of the request proxy middleware is deployed on an independent device or proxy server instead of being deployed in the client device. It should be noted that in this deployment method, a remote TCP connection needs to be established between the browser and the request agent.

Optionally, this deployment method can be applied to scenarios where the client device cannot install a dedicated browser or request proxy middleware, for example, the client device is an IoT node with limited resources, or a cloud center where the agent is separated from the upper-layer application, etc. Scenes.

It can be understood that the above three deployment modes are only exemplary descriptions, and do not constitute any limitation to the access control method provided in this application. In actual use, other deployment methods may also be adopted without limitation.

It can be understood that, in each of the above embodiments, the methods and/or steps implemented by each device may also be implemented by components (such as processors, chips, chip systems, circuits, logic modules, or software) that can be used in the device .

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

It can be understood that, in order to realize the functions in the foregoing embodiments, the communication device includes hardware structures and/or software modules corresponding to each function. Those skilled in the art should easily realize that the present application can be implemented in the form of hardware or a combination of hardware and computer software with reference to the units and method steps of the examples described in the embodiments disclosed in the present application. Whether a certain function is executed by hardware or computer software drives the hardware depends on the specific application scenario and design constraints of the technical solution.

FIG. 18 and FIG. 19 are schematic structural diagrams of possible communication devices provided by the embodiments of the present application. These communication devices can be used to realize the functions of the authorization server, the gateway device, the client device, or the data server in the above method embodiments, so the beneficial effects of the above method embodiments can also be realized. In the embodiment of the present application, the communication device may be an authorization server, a gateway device, a client device, or a data server as shown in FIG. 6a, and may also be an authorization server, a gateway device, a client device, or a Modules (such as chips).

As shown in FIG. 18 , the communication device 180 includes a processing module 1801 and a transceiver module 1802 . The communication device 180 is configured to realize functions of an authorization server, a gateway device, a client device, or a data server in the foregoing method embodiments.

When the communication device 180 is used to realize the function of the authorization server in the above method embodiment:

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

The processing module 1801 is configured to generate a target token according to the token application 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 based on the order card description, target information, and a cryptographic hash function;

The transceiver module 1802 is also configured to send the target token to the client device.

Optionally, the processing module 1801 is configured to generate the target token according to the token application information, including: the processing module 1801 is configured to determine the access authority of the requester according to the requester description information in the token application information; the processing module 1801 , which is also used to determine the authorization request initiator according to the requester's access rights.

When the communication device 180 is used to implement the functions of the gateway device in the above method embodiments:

The transceiver module 1802 is configured to receive a request message from a client device, the request message includes a target token and target information, the target token includes a token description and a first authorization code, the token description includes an authorization vector, and the authorization vector Indicate target information;

A processing module 1801, configured to generate a second authorization code according to the token description, target information, and key hash function;

When the second authorization code is the same as the first authorization code, the transceiver module 1802 is also used for the gateway device to forward the request message to the data server.

Optionally, the processing module 1801 is further configured to determine that the target token has not expired according to the validity period of the target token.

Optionally, the processing module 1801 is further configured to determine the requester of the trusted target resource according to the inspection policy; or, the processing module 1801 is further configured to determine the requester of the untrusted target resource according to the inspection policy, and determine the requester of the requester according to the exclusion information. The text is legal.

Optionally, the processing module 1801 is further configured to determine that the request message is legal according to the exclusion information, including: the processing module 1801 is further configured to determine that the request message is legal when the request message does not carry information prohibited from being carried.

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

When the communication device 180 is used to implement the functions of the client device in the above method embodiments:

Transceiver module 1802, configured to send token application information to the authorization server, where the token application information is used to apply for a target token;

The processing module 1801 is used to acquire a target token, 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 based on the token description, target information, and generated by cryptographic hash functions;

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

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 initiator corresponding to the target resource and the corresponding relationship between the authorization request initiator and the token. Card.

Wherein, more detailed descriptions about the processing module 1801 and the transceiver module 1802 can be directly obtained by referring to the relevant descriptions in the method embodiment shown in FIG. 7 , and will not be repeated here.

As shown in FIG. 19, the communication device 190 includes one or more processors 1901, communication lines 1902, and at least one communication interface (in FIG. description), optionally, a memory 1903 may also be included.

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

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

The communication interface 1904 may be a transceiver or a device such as a transceiver; the transceiver may include a radio frequency circuit and an antenna, and the radio frequency circuit is mainly used for converting baseband signals to radio frequency signals and processing radio frequency signals. Antennas are mainly used to send and receive radio frequency signals in the form of electromagnetic waves. Alternatively, the communication interface 1904 may be a transceiver circuit located in the processor 1901 to realize signal input and signal output of the processor.

The memory 1903 is mainly used to store software programs and data. It may be a device with a storage function. For example, it can be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (random access memory, RAM) or other types of memory that can store information and instructions A dynamic storage device can also be 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.), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store desired program code in the form of instructions or data structures and can be stored by a computer Any other medium, but not limited to. The memory may exist independently and be connected to the processor through the communication line 1902. Memory can also be integrated with the processor.

In a specific implementation, as an example, the processor 1901 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 19 .

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

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

It should be noted that the composition structure shown in FIG. 19 does not constitute a limitation to the communication device. Except for the components shown in FIG. certain components, or a different arrangement of components. The illustrated components can be realized in hardware, software or a combination of software and hardware.

When the communication device 190 is used to implement the method embodiment shown in the figure, the processor 1901 may be used to implement the functions of the processing module 1801 described above, and the communication interface 1904 may be used to implement the functions of the transceiver module 1802 described above.

As an example, the function/implementation process of the processing module 1801 in FIG. 18 can be realized by the processor 1901 shown in FIG. The process can be implemented through the communication interface 1904 shown in FIG. 19 .

In some embodiments, the present application further provides a communication device, where the communication device includes a processor, configured to implement the method in any one of the foregoing method embodiments.

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

As another possible implementation, the communication device further includes an interface circuit, the interface circuit is a code/data read and write interface circuit, and the interface circuit is used to receive computer-executed instructions (computer-executed instructions are stored in the memory, and may be directly read from memory read, or possibly through other devices) and transferred to the processor.

As yet another possible implementation manner, the communication device further includes a communication interface, where the communication interface is used to communicate with modules other than the communication device.

It can be understood that the communication device may be a chip or a system-on-a-chip. When the communication device is a system-on-a-chip, it may consist of a chip, or may include a chip and other discrete devices, which is not specifically limited in this embodiment of the present application.

The present application also provides a computer-readable storage medium, on which a computer program or instruction is stored, and when the computer program or instruction is executed by a computer, the functions of any one of the above method embodiments are realized.

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

In the above embodiments, all or part of them may be implemented by software, hardware, firmware or any combination thereof. When implemented using a software program, it may be implemented in whole or in part 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 the computer, the processes or functions according to the embodiments of the present application will be generated in whole or in part. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website, computer, server, or data center Transmission to another website site, computer, server or data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer, or may be a data storage device including one or more servers, data centers, etc. that can be integrated with the medium. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, or a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (solid state disk, SSD)), etc. In the embodiment of the present application, the computer may include the aforementioned apparatus.

Although the present application has been described in conjunction with various embodiments here, however, in the process of implementing the claimed application, those skilled in the art can understand and Other variations of the disclosed embodiments are implemented. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that these measures cannot be combined to advantage.

Although the application has been described in conjunction with specific features and embodiments thereof, it will be apparent that various modifications and combinations can be made thereto without departing from the spirit and scope of the application. Accordingly, the specification and drawings are merely illustrative of the application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of this application. Obviously, those skilled in the art can make various changes and modifications to the application without departing from the spirit and scope of the application. In this way, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these modifications and variations.

Claims

An access control method, characterized in that the method comprises:

The authorization server receives token application information from the client device, and 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, the target token includes a token description and a first authorization code, the token description includes an authorization vector, and the authorization vector indicates the target information , 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.
The method according to claim 1, wherein the target information is information to be carried in a request message of the client device.
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 according to the token description, the target information, and a key 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.
The method according to any one of claims 1-3, wherein 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 message;

Alternatively, the authorization vector includes a bitmap, and the bitmap indicates a field carrying the target information.
The method according to any one of claims 1-4, wherein the target information includes at least one of the following: network layer information corresponding to the target resource, transport layer information, authorization request initiator, request end identifier, The requester description information or the responder description information, the target resource is the resource to be accessed by the client device.
The method according to claim 5, wherein the authorization request initiator includes request information and part or all of the Uniform Resource Locator URL prefix of the target resource, and the request information indicates that it is related to the target resource operation.
The method according to claim 5 or 6, wherein 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 requester's the network type of the network;

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.
The method according to any one of claims 2-7, wherein the token description further includes validity period and at least one of the following: checking policy, issuer ID, cipher 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 ID indicates the device that issued the target token; the cipher suite indicates the Information related to cryptographic hash functions; the exclusion information indicates information that is prohibited from being carried.
The method according to claim 8, wherein 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;

Or, when the request message is the initial segment of a complete request message, the prohibited information is the request terminator;

Or, when the request message is a segment at the end of a complete request message, the prohibited information is request information;

Or, when the request message is an intermediate segment of a complete request message, the prohibited information is request information and a request terminator;

Alternatively, when the request message is a complete request message, the exclusion information indicates that it is forbidden to carry multiple request information and multiple request terminators.
An access control method, characterized in that the method comprises:

The gateway device receives a request message from the client device, the request message includes a target token and target information, the target token includes a token description and a first authorization code, the token description includes an authorization vector, and The authorization vector indicates the target information;

The gateway device generates a second authorization code according to the token description, the target information, and a key 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.
The method according to claim 10, wherein the grant 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 length;

Alternatively, the authorization vector includes a bitmap, and the bitmap indicates a field carrying the target information.
The method according to claim 10 or 11, wherein the target information includes at least one of the following: network layer information corresponding to the target resource, transport layer information, authorization request initiator, request end identifier, requester description Information, or responder description information, the target resource is the resource to be accessed by the client device.
The method according to claim 12, wherein the authorization request initiator includes request information and part or all of the Uniform Resource Locator URL prefix of the target resource, and the request information indicates that it is related to the target resource operation.
The method according to claim 12 or 13, wherein 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 requester's the network type of the network;

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.
The method according to any one of claims 10-14, wherein the token description further includes validity period and at least one of the following: checking policy, issuer ID, cipher 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 ID indicates the device that issued the target token; the cipher suite indicates the Information related to cryptographic hash functions; the exclusion information indicates information that is prohibited from being carried.
The method according to claim 15, further comprising:

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

The gateway device determines, according to the check policy, the 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.
The method according to claim 17, wherein the gateway device determines that the request message is legal according to the exclusion information, comprising: when the request message does not carry the prohibited information, the gateway device The device determines that the request packet is legal.
The method according to any one of claims 15-18, wherein when the exclusion information is a first value, the prohibited information is payload;

When the exclusion information is the second value, the prohibited information is the request terminator;

When the exclusion information is the third value, the prohibited information is the request information;

When the exclusion information is the fourth value, the prohibited information is the request information and the request terminator;

When the exclusion information is the fifth value, it indicates that carrying multiple request information and multiple request terminators is prohibited.
An access control method, characterized in that the method comprises:

The client device sends token application information to the authorization server, and the token application information is used to apply for a target token;

The client device acquires the target token, 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;

The client device sends a request packet, where the request packet includes the target token and the target information.
The method according to claim 20, wherein 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. length;

Alternatively, the authorization vector includes a bitmap, and the bitmap indicates a field carrying the target information.
The method according to claim 20 or 21, wherein the target information includes at least one of the following: network layer information corresponding to the target resource, transport layer information, authorization request initiator, request end identifier, requester description Information, or responder description information, the target resource is the resource to be accessed by the client device.
The method according to claim 22, wherein the authorization request initiator includes request information and part or all of the Uniform Resource Locator URL prefix of the target resource, and the request information indicates that it is related to the target resource operation.
The method according to claim 22 or 23, wherein 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 requester's the network type of the network;

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.
The method according to any one of claims 22-24, wherein the acquiring the target token by the client device comprises:

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.
The method according to any one of claims 20-25, wherein the token description further includes validity period and at least one of the following: checking policy, issuer ID, cipher 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 ID indicates the device that issued the target token; the cipher suite indicates the Information related to cryptographic hash functions; the exclusion information indicates information that is prohibited from being carried.
The method according to claim 26, wherein 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;

Or, when the request message is the initial segment of a complete request message, the prohibited information is the request terminator;

Or, when the request message is a segment at the end of a complete request message, the prohibited information is request information;

Or, when the request message is an intermediate segment of a complete request message, the prohibited information is request information and a request terminator;

Alternatively, when the request message is a complete request message, the exclusion information indicates that it is forbidden to carry multiple request information and multiple request terminators.
The method according to any one of claims 20-27, wherein the token application information includes at least one of the following: network layer information, transport layer information, application layer information, requester description information corresponding to the target resource , or demand information; the application layer information includes at least one of the following: the URL of the target resource, request information, or request terminator; the demand information indicates at least one of the following: expected token usage time, complete request Whether the packet is segmented and whether a TCP connection is established.
A communication device, characterized in that the communication device includes: a processor and a memory;

said memory for storing 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-9, or to implement the method according to any one of claims 10-19.
A communication device, characterized in that the communication device includes: a processor and a memory;

said memory for storing 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-28.
A computer-readable storage medium, characterized in that computer programs or instructions are stored in the computer-readable storage medium, and when the computer programs or instructions are executed by a communication device, as claimed in any one of claims 1-9 The method described above is implemented, or, the method described in any one of claims 10-19 is implemented.
A computer-readable storage medium, characterized in that computer programs or instructions are stored in the computer-readable storage medium, and when the computer programs or instructions are executed by a communication device, as claimed in any one of claims 20-28 The method described above is implemented.