A communication method, apparatus, device, and medium

Abstract

The application provides a communication method, device, equipment and medium, relating to the technical field of communication. When implementing the method, the gateway device in the zero-trust network authenticates the user according to the user token of the user after successfully establishing a communication connection with the user terminal of the user; after the authentication is passed, the gateway device confirms the resource access authority of the user to the controller in the zero-trust network; receives and stores the resource information of the resources allowed to be accessed by the user under the gateway device fed back by the controller, wherein the resource information is confirmed by the controller after the authentication of the user is passed; receives a service packet, wherein the service packet carries the resource identifier of the target resource requested to be accessed by the user; and forwards the service packet if the resource information of the resources allowed to be accessed by the user stored locally contains the resource identifier of the target resource.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method, apparatus, device and medium. Background Technology

[0002] With the rise of internet technologies such as cloud computing, the Internet of Things, and mobile office, enterprise resources are no longer limited to internal use. The need for employees to access the enterprise intranet anytime, anywhere is becoming increasingly common. Traditional network protection boundaries are becoming increasingly blurred, and traditional security measures based on network boundaries are finding it increasingly difficult to meet the demands. To address these issues, SDP (Software Defined Perimeter) zero-trust technology has emerged. The core idea of ​​SDP zero-trust is to distrust no person, device, or system, and to continuously and dynamically authenticate and grant least privileges to all users accessing restricted resources.

[0003] SDP zero-trust functionality refers to a device acting as an SDP gateway, working in conjunction with an SDP controller to authenticate and authorize users accessing specified applications or APIs. This enables centralized control over user identity and access permissions, preventing unauthorized access. In a zero-trust scenario, the SDP gateway serves as an enterprise boundary device, connecting remote users to the enterprise's internal network.

[0004] Before providing services to a zero-trust network, an SDP gateway needs to register with the controller and successfully go online. After successful online access, the controller sends resource information for all resources to the SDP gateway. This means the SDP gateway stores all resource information locally. Then, when a user accesses resources on the internal network through the SDP gateway, the gateway controls access based on the user's permissions. However, in practice, users may not access all resources, leading to a waste of the SDP gateway's stored resources.

[0005] Therefore, how to save storage resources on the SDP gateway and avoid wasting storage resources is one of the technical issues worth considering. Summary of the Invention

[0006] In view of this, this application provides a communication method, apparatus, device and medium to save storage resources of SDP gateway and avoid waste of storage resources.

[0007] Specifically, this application is implemented through the following technical solution:

[0008] According to a first aspect of this application, a communication method is provided, applied to a gateway device in a zero-trust network, wherein the gateway device has been successfully registered on a controller in the zero-trust network; the method includes:

[0009] After successfully establishing a communication connection with the user's user terminal, if the user is confirmed to be online based on the user's user token, then the controller is notified to confirm the user's resource access permissions.

[0010] The controller receives and stores resource information that the user is allowed to access under the gateway device, which is confirmed by the controller after the user has been successfully authenticated.

[0011] Receive a service message, the service message carrying the resource identifier of the target resource requested by the user;

[0012] If the resource information of the resource that the user is allowed to access in the local storage contains the resource identifier of the target resource, then the service message is forwarded.

[0013] According to a second aspect of this application, another communication method is provided, applied in a controller in a zero-trust network, the method comprising:

[0014] After the authentication message sent to the user's user terminal is successfully authenticated, a user token is assigned to the user.

[0015] Assign resources that the user is allowed to access, and confirm the gateway device corresponding to the resource, which has been successfully registered on the controller in advance;

[0016] Send the user token and a list of resources that the user is allowed to access to the user terminal;

[0017] Send the user token to the gateway device corresponding to the resource;

[0018] Receive the user's resource access permission confirmation message sent by the gateway device;

[0019] After confirming that the resource that the user is allowed to access has been allocated, the resource information of the resource that the user is allowed to access is sent to the gateway device.

[0020] According to a third aspect of this application, a communication device is provided, disposed in a gateway device in a zero-trust network, the gateway device having been successfully registered on a controller in the zero-trust network; the device includes:

[0021] The confirmation module is used to confirm the user's resource access permissions with the controller if the user is confirmed to be online based on the user's user token after a successful communication connection is established with the user's user terminal.

[0022] The receiving module is used to receive resource information from the controller that the user is allowed to access under the gateway device, wherein the resource information is confirmed by the controller after the user has been successfully authenticated;

[0023] A storage module is used to store the resource information;

[0024] The receiving module is further configured to receive a service message, the service message carrying the resource identifier of the target resource requested by the user;

[0025] The forwarding module is used to forward the service message if the resource information of the resource that the user is allowed to access in the local storage contains the resource identifier of the target resource.

[0026] According to a fourth aspect of this application, another communication device is provided, disposed in a controller in a zero-trust network, the device comprising:

[0027] The allocation module is used to allocate a user token to the user after the authentication message sent to the user terminal is successfully authenticated; and to allocate resources that the user is allowed to access, and to confirm the gateway device corresponding to the resource, wherein the gateway device has been successfully registered on the controller in advance.

[0028] The sending module is configured to send the user token and a list of resources that the user is allowed to access to the user terminal; and to send the user token to the gateway device corresponding to the resource.

[0029] The receiving module is used to receive the resource access permission confirmation message sent by the gateway device;

[0030] The sending module is further configured to send resource information of the resources that the user is allowed to access to the gateway device after confirming that the resources have been allocated to the user.

[0031] According to a fifth aspect of this application, an electronic device is provided, including a processor and a machine-readable storage medium storing a computer program executable by the processor, the processor being prompted by the computer program to perform the method provided in the first or second aspect of the embodiments of this application.

[0032] According to a sixth aspect of this application, a machine-readable storage medium is provided, which stores a computer program that, when invoked and executed by a processor, causes the processor to perform the method provided in the first or second aspect of the embodiments of this application.

[0033] The beneficial effects of the embodiments of this application are as follows:

[0034] In the communication method, apparatus, device, and medium provided in this application embodiment, after successfully establishing a communication connection with a user's terminal, if the user is confirmed to be online based on their user token, the controller is notified of the user's resource access permissions. The controller receives and stores resource information from the controller that allows the user to access resources under the gateway device, the resource information being confirmed by the controller after successful user authentication. A service message is received, carrying the resource identifier of the target resource requested by the user. If the locally stored resource information allowing the user to access resources includes the resource identifier of the target resource, the service message is forwarded. In this way, after the gateway device successfully goes online to the controller, the controller does not need to send resource information for all resources to the gateway device. Resource information for resources accessible to the user under the gateway device is only sent to the gateway device when the gateway device confirms the user's resource access permissions with the controller. This not only facilitates the gateway device in providing resource access services to users but also significantly reduces the storage pressure on the gateway device because it does not need to store resource information for all resources. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0036] Figure 2 This is a flowchart illustrating another communication method provided in an embodiment of this application;

[0037] Figure 3 This is a schematic diagram of the structure of a zero-trust network implementing a communication method according to an embodiment of this application;

[0038] Figure 4 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0039] Figure 5 This is a schematic diagram of another communication device provided in an embodiment of this application;

[0040] Figure 6 This is a schematic diagram of the hardware structure of an electronic device implementing a communication method according to an embodiment of this application. Detailed Implementation

[0041] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0042] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the corresponding listed items.

[0043] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0044] The communication method provided in this application will be described in detail below.

[0045] See Figure 1 , Figure 1 This is a flowchart of a communication method provided in this application. This method can be applied to a gateway device in a zero-trust network, also known as an SDP gateway; the gateway device has been successfully registered with the controller in the zero-trust network. When implementing the above method, the gateway device may include the following steps:

[0046] S101. After successfully establishing a communication connection with the user's user terminal, if the user is confirmed to be online based on the user's user token, then the controller is notified to confirm the user's resource access permissions.

[0047] Specifically, before a gateway device provides resource access services to users, it first registers with the controller to indicate to the controller that the gateway device is online. At this point, after the gateway device successfully goes online, the controller does not send all resource information to the gateway device. Instead, it waits for the gateway device to request it before sending the information, which will be explained in detail later.

[0048] Furthermore, before establishing a communication connection between the user terminal and the gateway device, the user first authenticates with the controller, for example, by sending an SPA message to the controller. This SPA message carries the user's information. Upon receiving the SPA message, the controller can parse the user information from it and then authenticate the user based on that information. Successful authentication indicates that the user is allowed to access resources in the zero-trust network, so the controller assigns a user token for accessing resources in the zero-trust network. Simultaneously, it can determine the resources in the zero-trust network that the user is allowed to access based on the user information. To ensure the security of the zero-trust network, the user terminal needs to be authenticated by the gateway device in the zero-trust network when accessing resources; therefore, it is necessary to confirm the correspondence between resources and gateway devices. Based on this, after determining the resources that the user can access, the controller can determine the gateway device corresponding to each resource based on the above correspondence. Then, it feeds back a resource list of resources allowed to the user, which includes the resource identifier of each resource and the address information of the gateway device corresponding to each resource allowed to the user, to the user terminal. In addition, the controller will also send the user token back to the identified gateway devices, and the controller can also send information such as username and user IP address back to the gateway devices.

[0049] Furthermore, after receiving the aforementioned information from the controller, the user terminal can establish communication connections with the corresponding gateway devices based on the address information of each gateway device. During the connection establishment process, the user's user token is carried. The gateway device can then authenticate this user token by matching it with the user token returned by the controller. If the match is successful, the user is authenticated, and a communication connection can be established with the user terminal. In addition, to further ensure that the user can access user resources in the zero-trust network, the user's online status is checked. If the user is confirmed to be online, the subsequent process is executed; if the user is confirmed to be offline, it indicates that there is currently no need to provide resource access services to that user, and the subsequent process of this application is not executed, and the user terminal is no longer responded to.

[0050] Specifically, you can confirm whether a user is online by checking if their user token is currently valid. If it is valid, the user is still online; if it is invalid, the user is currently offline.

[0051] Based on this, when a user is confirmed to be online, the gateway device then confirms the user's resource access permissions with the controller, that is, determines the resources that the user can access. For example, the gateway device can send a resource access permission confirmation message to the controller. This confirmation message can carry the user's information, such as username, user token, etc. The username is returned by the controller after the user is successfully authenticated. In this way, after receiving the confirmation message, the controller can first authenticate the user based on the user token, and then confirm whether to allocate the resources that the user can access based on the user's username and user token. Then, it can return the resource list corresponding to the resources that the user is allowed to access to to the gateway device.

[0052] S102. Receive and store the resource information fed back by the controller regarding the resources that the user is allowed to access under the gateway device.

[0053] The aforementioned resource information is confirmed by the controller after the user authentication is successful.

[0054] In this step, the gateway device only needs to store the resource information that the controller allows the user to access under the gateway device. In this way, the gateway device does not need to store the resource information of all resources in the zero-trust network, which greatly alleviates the storage pressure on the gateway device. In addition, the controller does not need to distribute infrequently accessed resources to all gateway devices, further reducing the storage resource overhead of the gateway device.

[0055] S103. Receive a service message, the service message carrying the resource identifier of the target resource requested by the user.

[0056] In this step, when the user selects the resource to be accessed (denoted as the target resource) from the resource list returned by the controller, the gateway device corresponding to the target resource can be determined based on the correspondence between the resources and gateway devices fed back by the controller; then, the aforementioned service message for accessing the target resource can be sent to the gateway device.

[0057] S104. If the resource information of the resource that the user is allowed to access in the local storage contains the resource identifier of the target resource, then forward the service message.

[0058] In this step, after receiving a service message from a user terminal, the gateway device can determine whether the user has permission to access the target resource based on the resource information stored locally. If the resource information stored in step S103 that allows the user to access the resource includes the resource identifier of the target resource, it indicates that the user has permission to access the target resource, and therefore the service message can be allowed, such as by forwarding the service message to the resource server corresponding to the target resource.

[0059] Specifically, after receiving a service message, the gateway device will first decapsulate the service message to extract the resource identifier of the target resource. When it is confirmed that the user has the right to access the target resource, the service message will be recapsulated to configure the destination address of the service message as the destination address of the resource server, and then the recapsulated service message will be forwarded.

[0060] Therefore, by adopting the above method, after the gateway device successfully goes online to the controller, the controller no longer needs to send resource information for all resources to the gateway device. Resource information for the resources that a user can access under the gateway device is only sent to the gateway device when the controller confirms the user's resource access permissions with the controller. This not only facilitates the gateway device in providing resource access services to users, but also significantly reduces the storage pressure on the gateway device because it does not need to store resource information for all resources.

[0061] Optionally, based on the above embodiments, in this embodiment, the resource information includes resource IP addresses; furthermore, after executing step S102, the following process may be included: sending the resource IP addresses of the resources that the user is allowed to access under the gateway device to the user terminal.

[0062] Specifically, after obtaining the resource information of the resources that the user can access from the controller, the gateway device can send the resource IP address in the resource information to the user terminal in order to enable the user to access the target resource. In this way, when the user terminal accesses the target resource, it can access the target resource based on the resource IP address of the target resource.

[0063] Further, step S103 can be performed according to the following process: receiving the service message sent by the user terminal based on the resource IP address of the target resource.

[0064] Specifically, when a user terminal accesses a target resource, it can construct a data packet based on the resource's IP address, with the destination address of the data packet being the resource's IP address. Then, the data packet undergoes tunnel encapsulation processing according to the tunnel between the user terminal and the gateway device to obtain the aforementioned service packet. This service packet can then be sent to the gateway device.

[0065] Based on this, the communication method provided in this embodiment may further include: sending the virtual network card address assigned to the user by the controller to the user terminal, wherein the virtual network card address is fed back to the gateway device by the controller after the user is authenticated, so that the user terminal configures the address of the outgoing interface for accessing the target resource as the virtual network card address and sends service messages through the outgoing interface.

[0066] Specifically, to ensure the security of user terminals accessing resources in the zero-trust network, users need to access resources using addresses recognized by the zero-trust network. Therefore, when the controller successfully authenticates a user, it assigns the user a virtual network interface card (NIC) address for subsequent access to resources in the zero-trust network. Thus, when the controller sends the user's user token to the gateway device, it also sends the virtual NIC address assigned to the user. Based on this, after executing step S102, the gateway device can send the user's corresponding virtual NIC address and the resource IP addresses of the resources the user can access back to the user terminal.

[0067] Since users need to follow a specific access path to access a target resource, the user terminal needs to generate routing information for that access path locally. Therefore, the user terminal can generate routing information for accessing the target resource based on the resource's IP address and the virtual network interface card (NIC) address received from the gateway device, according to a predefined algorithm. Then, the outgoing interface involved in the generated routing information in the user terminal is configured as the virtual NIC address, allowing access to the target resource through the gateway device via the generated routing information.

[0068] Optionally, based on any of the above embodiments, in this embodiment, step S102 can be performed according to the following process: maintaining resource information of the resources that the user is allowed to access using resource table entries. Based on this, step S104 can be performed according to the following process: querying the resource table entries; if the aforementioned resource table entries include the resource identifier of the target resource, then forwarding the service message.

[0069] Specifically, the resource information mentioned above includes not only the resource IP address but also the resource identifier, the API and port used to access the resource IP address, etc. Therefore, for convenient querying, the resource table entries can be used to maintain resource information for each resource that the user can access. Furthermore, the resource table entries can also include the user's username, user token, etc., so that after receiving a service message, it can quickly find out from the resource table whether the user has access permission to access a certain resource. Since the gateway device may provide resource access services to multiple users, it will correspondingly maintain multiple resource table entries for each user locally. Therefore, when a service message is received, the service message may also include relevant user information, such as username and user token. Thus, based on the username and user token, the resource table entry containing the username and user token can be found. Then, it can be confirmed whether the resource table entry contains the resource identifier of the target resource. If it does, it is confirmed that the user has access permission to access the target resource, and the service message is then forwarded.

[0070] Optionally, based on any of the above embodiments, in this embodiment, after executing step S102, the following implementation process is also provided: start the timing function; if no service message is received within the set time indicated by the timing function, delete the stored resource information of the resource corresponding to the user.

[0071] Specifically, to further alleviate the storage pressure on the gateway device, after obtaining the user's corresponding resources from the controller, the gateway device can activate a timer function to start timing. If no service packets accessing resources in the zero-trust network are received within the aforementioned set time, it indicates that the resource information maintained for that user can be aged out. Therefore, the gateway device can delete the resource information corresponding to that user from its local storage, thereby achieving the goal of saving gateway device storage resources.

[0072] Optionally, when using resource entries to maintain the resource information of a user's resources, the resource entries may also include the set time, i.e. the idle time of the resource entries. Therefore, when starting the timed function, the timed function can be started according to the set time maintained in the resource entries.

[0073] It is worth noting that the main data structure of a resource table entry can be as follows:

[0074] “data”:{

[0075] "SslvpnContext":"default"

[0076] "UserToken":"abc", / / User token

[0077] "UserName":"test", / / Username

[0078] "PermitAppId":"1; 2; 3", / / Resource identifier for application resources that the user is allowed to access.

[0079] "PermitApiList":"1; 2; 3", / / Resource list

[0080] "IdleTimeout": "10min" / / Set time

[0081] "ValidTime":"5min", / / Valid time, i.e., the validity period of the user token.

[0082] }

[0083] The validity period of the aforementioned user token can be monitored starting from the moment the user token is received from the controller. That is, after receiving the user's username and user token, the aforementioned data structure can be created, and after obtaining the resource information of the resources that the user can access from the controller, it can be written into the aforementioned data structure.

[0084] It's important to note that before the controller sends resource information about resources accessed by users under a gateway device to the gateway device, the gateway device needs to register with the controller to notify the controller that it is online. Specifically, the gateway device can register with the controller via cloud pipelines and RESTful sub-connections. After allowing the gateway device to go online, the controller can send the Kafka connection address, port, and a device identifier assigned to the gateway device via the RESTful sub-connection. Different gateway devices have different device identifiers. The gateway device can then register using the Kafka address and port. Once registration is successful, the controller can display a message indicating that the gateway device is online successfully.

[0085] Optionally, the aforementioned user terminal may be configured with a client that interacts with the controller and gateway devices in the zero-trust network. This client may be, but is not limited to, an authentication client. The aforementioned communication connection may be, but is not limited to, a tunnel connection, and the tunnel may be, but is not limited to, an SSL VPN data tunnel, etc.

[0086] At this point, after the gateway device registers and goes online with the controller, the controller does not need to send resource information for all resources in the zero-trust network to the gateway device. Instead, the gateway device obtains the resource information for the resources that the user can access from the controller after confirming that the user is online. In this way, the gateway device does not need to store the resource information for all resources, but only the resource information for the resources that the user can access. This greatly alleviates the resource storage pressure on the gateway device and avoids the waste of storage resources caused by storing resources that users do not access in the gateway device.

[0087] Based on the same inventive concept, this embodiment also provides a communication method, see reference. Figure 2 The flowchart shown illustrates this communication method, which can be applied to controllers in zero-trust networks. When implementing this communication method, the controller can follow the steps outlined below:

[0088] S201. After the authentication message sent to the user's user terminal is successfully authenticated, a user token is assigned to the user.

[0089] In this step, before accessing resources in the zero-trust network, users need to be authenticated by the controller. This involves the user sending an authentication message to the controller via their terminal. This authentication message can be, but is not limited to, an SPA message. Taking an SPA message as an example, the SPA message carries the user's information. After receiving the SPA message, the controller can parse the user information from it and then authenticate the user based on that information. If authentication is successful, it indicates that the user is allowed to access resources in the zero-trust network, and the controller will assign the user a user token for accessing those resources.

[0090] S202. Assign resources that the user is allowed to access, and confirm the gateway device corresponding to the resource, which has been successfully registered on the controller in advance.

[0091] In this step, the controller can also determine the resources that the user is allowed to access in the zero-trust network based on the user information. Furthermore, to ensure the security of the zero-trust network, user terminals need to be authenticated by gateway devices within the network when accessing resources. Therefore, it is necessary to confirm the correspondence between resources and gateway devices. Based on this, after determining the resources that the user can access, the controller can determine the corresponding gateway device for each resource based on the aforementioned correspondence.

[0092] S203. Send the user token and a list of resources that the user is allowed to access to the user terminal.

[0093] In this step, based on steps S201 to S202, the controller will also send a resource list of resources that the user is allowed to access. This resource list includes the resource identifier of the corresponding resource and the address information of the gateway device corresponding to each resource that the user is allowed to access back to the user terminal.

[0094] S204. Send the user token to the gateway device corresponding to the resource.

[0095] Based on step S203, the controller will also send the user token back to each of the identified gateway devices. In addition, the controller can also send information such as username and user IP address back to the gateway devices so that the gateway devices can authenticate the user when establishing a communication connection with the user, and authenticate the user's access permissions to resources based on the above information when the user accesses resources.

[0096] S205. Receive the resource access permission confirmation message sent by the gateway device for the user.

[0097] In this step, after the gateway device registers with the controller, the controller does not need to send all resource information to the gateway device at this time. Instead, the controller sends the information to the gateway device only after the gateway device confirms with the controller. Therefore, when the gateway device needs to confirm the resources that a user can access, it sends a resource access permission confirmation message to the controller. For example, this confirmation message can carry the user's user information. When the controller receives this user information, it can then confirm whether a user token has been assigned to the user indicated by the user information, and whether the resources that the user can access have been allocated to that user.

[0098] S206. After confirming that the resource that the user is allowed to access has been allocated, send the resource information of the resource that the user is allowed to access to the gateway device.

[0099] In this step, the controller confirms, based on the user's information, that the local system has configured the resources that the user is allowed to access. Since the gateway devices that provide services for each resource may be different, the controller will configure the correspondence between the resources and the gateway devices. In this way, the controller can confirm the resources that the user can access under the gateway device, and then the controller can send the resource information of the resources that the user can access under the gateway device to the gateway device.

[0100] It is worth noting that the above confirmation message may carry the device identifier of the gateway device, so that the controller can determine the corresponding gateway device based on the device identifier; or, the controller may configure different ingress interfaces for different gateway devices, so that the controller can determine the gateway device corresponding to the ingress interface based on the confirmation message entering the controller's ingress interface.

[0101] Therefore, by adopting the above method, after the gateway device successfully goes online to the controller, the controller no longer needs to send resource information for all resources to the gateway device. Resource information for the resources that a user can access under the gateway device is only sent to the gateway device when the controller confirms the user's resource access permissions with the controller. This not only facilitates the gateway device in providing resource access services to users, but also significantly reduces the storage pressure on the gateway device because it does not need to store resource information for all resources.

[0102] Optionally, the aforementioned user terminal may be configured with a client that interacts with the controller and gateway devices in the zero-trust network. This client may be, but is not limited to, an authentication client.

[0103] It is worth noting that when the controller feeds back the corresponding information to the user terminal and the gateway device respectively, it can do so through the control channel; the communication connection between the user terminal and the gateway device can be an SSLVPN data channel.

[0104] To better understand this embodiment, Figure 3 Using the zero-trust network shown as an example, and taking the SDP gateway device as an example, when a user accesses resources in the zero-trust network through a user terminal configured with a client, the interaction process between the client, controller, and SDP gateway is roughly as follows:

[0105] Step 1: The SDP gateway registers with the controller and goes online, establishing cloud pipelines and RESTful sub-connections.

[0106] Step 2: The controller sends the Kafka connection address, port, and unique device identifier of the SDP gateway to the gateway through a RESTful subconnection. After the SDP gateway successfully registers with Kafka, the controller displays that the SDP gateway is online.

[0107] Step 3: User 1 performs SPA (Single Package Authorization) authentication with the controller through the client in the user terminal.

[0108] Step 4: After successful SPA gateway authentication, User 1 logs in. After successful username and password authentication, the following two operations are performed: The controller sends the username, user IP address, and user token to the SDP gateway; The controller returns the user token, a list of resources that User 1 can access, and the gateway address information corresponding to the accessible resources to the client.

[0109] Step 5: When user 1 confirms access to a resource based on the resource list, based on the correspondence between the resource and the gateway device fed back by the controller, SPA authentication is initiated to the SDP gateway corresponding to the resource.

[0110] Step 6: After confirming that the SDP gateway is authenticated, initiate an SSL handshake connection to the gateway and successfully establish the handshake, thus completing the communication connection with the gateway.

[0111] Step 9: After establishing a communication connection with the client, the SDP gateway will confirm whether User 1 is online based on User 1's user token. If User 1 is confirmed to be online, the gateway will confirm User 1's resource access permissions with the controller.

[0112] Step 10: After confirming the resources that user 1 can access under the SDP gateway, the controller can send resource information of the resources that user 1 is allowed to access under the SDP gateway to the SDP gateway.

[0113] Step 11: The SDP gateway stores the resource information of the resources that user 1 can access under the SDP gateway, which is fed back by the controller; and sends the resource IP address and the virtual network card address assigned to user 1 by the controller from the resource information to the client.

[0114] Step 12: After the client receives the above resource IP address and virtual network card address, when it confirms from the controller's resource list that it wants to access resource 1 through SDP gateway 1, it can generate routing information for accessing resource 1 based on the resource IP address and virtual network card address of resource 1 fed back by the SDP gateway.

[0115] Step 13: The client sets the address of the outgoing interface in the routing information of Resource 1 to the virtual network card address; then it can encapsulate the service packets that initiate access to Resource 1 with SSL and send them to the SDP gateway.

[0116] Step 14: The SDP gateway decapsulates the service message, checks the request permissions, and forwards it to the resource server after the check is passed.

[0117] Step 15: The resource server responds to the SDP gateway, which encapsulates the response and forwards it to the client, thus enabling user 1 to successfully access resource 1 as requested.

[0118] Therefore, in scenarios where multiple gateway devices share the load, since different gateway devices may support different resources, by adopting the method provided in any embodiment of this application, the controller only needs to send resource information of the resources accessible to users under that gateway device to the gateway device. The controller no longer needs to repeatedly send resource information of all resources to all gateways, thus solving the problem of resource storage redundancy and high storage pressure on gateway devices caused by sending resource information of all resources to all gateways separately. In addition, the controller does not need to send resources that users do not frequently access to all gateways, but only to the gateway that serves the resource, thereby reducing the storage pressure on the gateways and saving resource overhead.

[0119] Based on the same inventive concept, this application also provides a communication device corresponding to the communication method provided by the aforementioned gateway device. Specific implementation details of this communication device can be found in the description of the communication method provided by the aforementioned gateway device, and will not be elaborated upon here.

[0120] See Figure 4 , Figure 4 This application provides an exemplary embodiment of a communication device, which is installed in a gateway device in a zero-trust network. The gateway device has been successfully registered on a controller in the zero-trust network. The device includes:

[0121] The confirmation module 401 is used to confirm the user's resource access permissions to the controller if the user is confirmed to be online based on the user's user token after a successful communication connection is established with the user's user terminal.

[0122] The receiving module 402 is used to receive resource information fed back by the controller regarding resources that the user is allowed to access under the gateway device, wherein the resource information is confirmed by the controller after the user has been successfully authenticated;

[0123] Storage module 403 is used to store the resource information;

[0124] The receiving module 402 is further configured to receive a service message, the service message carrying the resource identifier of the target resource requested by the user;

[0125] The forwarding module 404 is used to forward the service message if the resource information of the resource that the user is allowed to access in the local storage contains the resource identifier of the target resource.

[0126] By providing the aforementioned device, after the gateway device successfully connects to the controller, the controller no longer needs to send resource information for all resources to the gateway device. Resource information about the resources accessible to the user under the gateway device is only sent to the gateway device when the controller confirms the user's resource access permissions with the controller. This not only facilitates the gateway device in providing resource access services to users, but also significantly reduces the storage pressure on the gateway device because it does not need to store resource information for all resources.

[0127] Optionally, based on the above embodiments, the communication device provided in this embodiment may further include:

[0128] The startup module (not shown in the figure) is used to start the timing function after the receiving module receives and stores the resource information of the resources that the user is allowed to access, which is fed back by the controller.

[0129] The deletion module (not shown in the figure) is used to delete the stored resource information of the resource corresponding to the user if the receiving module 402 does not receive the service message within the set time indicated by the timing function.

[0130] Furthermore, the aforementioned storage module 403 is specifically used to maintain resource information of the resources that the user is allowed to access using resource table entries;

[0131] Based on this, the aforementioned forwarding module 404 is specifically used to query the resource table entry; if the resource table entry includes the resource identifier of the target resource, then the service message is forwarded.

[0132] Furthermore, the aforementioned startup module (not shown in the figure) is specifically used to start the timing function according to the set time maintained in the resource table entry.

[0133] Based on any of the above embodiments, the resource information in this embodiment includes a resource IP address; furthermore, the communication device provided in this embodiment may include:

[0134] The sending module (not shown in the figure) is used to send the resource IP address of the resource that the user is allowed to access under the gateway device to the user terminal after the receiving module 402 receives and stores the resource information of the resource that the user is allowed to access under the gateway device fed back by the controller.

[0135] Furthermore, the receiving module 402 is specifically used to receive service packets sent by the user terminal based on the resource IP address of the target resource.

[0136] Based on this, the aforementioned sending module (not shown in the figure) is also used to send the virtual network card address assigned to the user by the controller to the user terminal. The virtual network card address is fed back to the gateway device by the controller after the user is successfully authenticated, so that the user terminal configures the address of the outgoing interface for accessing the target resource as the virtual network card address and sends the service message through the outgoing interface.

[0137] Based on the same inventive concept, this application also provides a communication device corresponding to the communication method provided by the controller described above. Specific implementation details of this communication device can be found in the controller's description of the communication method, and will not be elaborated upon here.

[0138] See Figure 5 , Figure 5 This application provides an exemplary embodiment of a communication device, disposed in a controller in a zero-trust network, the device comprising:

[0139] The allocation module 501 is used to allocate a user token to the user after the authentication message sent to the user terminal is successfully authenticated; and to allocate resources that the user is allowed to access, and to confirm the gateway device corresponding to the resource, wherein the gateway device has been successfully registered on the controller in advance.

[0140] Sending module 502 is used to send the user token and a list of resources that the user is allowed to access to the user terminal; and to send the user token to the gateway device corresponding to the resource.

[0141] The receiving module 503 is used to receive the resource access permission confirmation message sent by the gateway device;

[0142] The sending module 502 is further configured to send resource information that allows the user to access the resources to the gateway device after confirming that the resources have been allocated to the user.

[0143] By providing the communication device in the controller, after the gateway device successfully connects to the controller, the controller does not need to send all resource information to the gateway device. Resource information about the resources that a user can access under the gateway device is only sent to the gateway device when the gateway device confirms the user's resource access permissions with the controller. This not only facilitates the gateway device in providing resource access services to users, but also significantly reduces the storage pressure on the gateway device because it does not need to store all resource information.

[0144] Based on the same inventive concept, embodiments of this application provide an electronic device, which may be, but is not limited to, the aforementioned controller and gateway device. For example... Figure 6 As shown, the electronic device includes a processor 601 and a machine-readable storage medium 602. The machine-readable storage medium 602 stores a computer program executable by the processor 601. The processor 601 is prompted by the computer program to execute the communication method provided in any embodiment of this application. Furthermore, the electronic device also includes a communication interface 603 and a communication bus 604, wherein the processor 601, the communication interface 603, and the machine-readable storage medium 602 communicate with each other via the communication bus 604.

[0145] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0146] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0147] The machine-readable storage medium 602 described above can be a memory, which may include random access memory (RAM), DDR SRAM (Double Data Rate Synchronous Dynamic Random Access Memory), or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0148] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0149] For embodiments of electronic devices and machine-readable storage media, since the methods involved are basically similar to those described in the foregoing method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0150] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0151] The specific implementation process of the functions and roles of each unit / module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0152] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units / modules described as separate components may or may not be physically separate. The components shown as units / modules may or may not be physical units / modules, that is, they may be located in one place or distributed across multiple network units / modules. Some or all of the units / modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0153] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A communication method, characterized in that, The method, applied to a gateway device in a zero-trust network, wherein the gateway device has been successfully registered on the controller of the zero-trust network, includes: After successfully establishing a communication connection with the user's user terminal, if the user is confirmed to be online based on the user's user token, then the controller is notified to confirm the user's resource access permissions. The controller receives and stores resource information that the user is allowed to access under the gateway device, which is confirmed by the controller after the user has been successfully authenticated. Receive a service message, the service message carrying the resource identifier of the target resource requested by the user; If the resource information of the resource that the user is allowed to access in the local storage contains the resource identifier of the target resource, then the service message is forwarded.

2. The method according to claim 1, characterized in that, After receiving and storing the resource information from the controller that allows the user to access resources, the process further includes: Start the timer function; If a service message is not received within the set time indicated by the timing function, the resource information of the resource corresponding to the user is deleted from storage.

3. The method according to claim 1, characterized in that, The resource information includes the resource IP address; After receiving and storing the resource information fed back by the controller regarding the resources that the user is allowed to access under the gateway device, the method further includes: Send the resource IP addresses of the resources that the user is allowed to access under the gateway device to the user terminal; Receive service messages, including: Receive the service message sent by the user terminal based on the resource IP address of the target resource.

4. The method according to claim 3, characterized in that, Also includes: The controller sends the virtual network interface card (NIC) address assigned to the user to the user terminal. The virtual NIC address is fed back to the gateway device by the controller after the user is successfully authenticated, so that the user terminal configures the address of the outgoing interface for accessing the target resource as the virtual NIC address and sends the service message through the outgoing interface.

5. The method according to claim 2, characterized in that, The system stores resource information fed back by the controller regarding resources that the user is allowed to access under the gateway device, including: The resource information of the resources that the user is allowed to access is maintained using resource table entries; If the resource information of the resource that the user is allowed to access in the locally stored database contains the resource identifier of the target resource, then the service message is forwarded, including: Query the resource table entries; If the resource entry includes the resource identifier of the target resource, then the service message is forwarded.

6. The method according to claim 5, characterized in that, Start the timer function, including: The timed function is started according to the set time maintained in the resource table entry.

7. A communication method, characterized in that, The method, applied in a controller in a zero-trust network, includes: After the authentication message sent to the user's user terminal is successfully authenticated, a user token is assigned to the user. Assign resources that the user is allowed to access, and confirm the gateway device corresponding to the resource, which has been successfully registered on the controller in advance; Send the user token and a list of resources that the user is allowed to access to the user terminal; Send the user token to the gateway device corresponding to the resource; Receive the user's resource access permission confirmation message sent by the gateway device; After confirming that the resource that the user is allowed to access has been allocated, the resource information of the resource that the user is allowed to access is sent to the gateway device.

8. A communication device, characterized in that, The device is a gateway device installed in a zero-trust network, and the gateway device has been successfully registered with the controller of the zero-trust network; the device includes: The confirmation module is used to confirm the user's resource access permissions with the controller if the user is confirmed to be online based on the user's user token after a successful communication connection is established with the user's user terminal. The receiving module is used to receive resource information from the controller that the user is allowed to access under the gateway device, wherein the resource information is confirmed by the controller after the user has been successfully authenticated; A storage module is used to store the resource information; The receiving module is further configured to receive a service message, the service message carrying the resource identifier of the target resource requested by the user; The forwarding module is used to forward the service message if the resource information of the resource that the user is allowed to access in the local storage contains the resource identifier of the target resource.

9. A communication device, characterized in that, The device, located in a controller within a zero-trust network, includes: The allocation module is used to allocate a user token to the user after the authentication message sent to the user terminal is successfully authenticated; and to allocate resources that the user is allowed to access, and to confirm the gateway device corresponding to the resource, wherein the gateway device has been successfully registered on the controller in advance. The sending module is configured to send the user token and a list of resources that the user is allowed to access to the user terminal; and to send the user token to the gateway device corresponding to the resource. The receiving module is used to receive the resource access permission confirmation message sent by the gateway device; The sending module is further configured to send resource information of the resources that the user is allowed to access to to the gateway device after confirming that the resources have been allocated to the user.

10. An electronic device, characterized in that, The method includes a processor and a machine-readable storage medium storing a computer program executable by the processor, which is prompted by the computer program to perform the method of any one of claims 1-6, or the method of claim 7.

11. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores a computer program that, when invoked and executed by a processor, causes the processor to perform the method of any one of claims 1-6, or the method of claim 7.

Images