Command verification at intermediate device

Abstract

Embodiments of the invention relate to command verification at an intermediary device. In some examples, an intermediary device receives, from a client device, a command associated with a security protocol that ensures a connection between the client device and a server system, where the intermediary device includes an inline authentication and authorization service between the client device and the server system. The authentication and authorization service determines, at the intermediary device, whether to authorize a command received from the client device based on the command enforcement policy information.

Description

Technical Field

[0001] The embodiments of the present application relate to command verification at an intermediate device. Background Art

[0002] A client device can access services provided by a server system. An example of a server system is a Network Access Device (NAD) to which a client device can connect to access a network. Other examples of server systems include server systems that provide programs available to a client device (e.g., web programs, applications, or other programs), resources accessible by a client device on demand (e.g., processing resources, storage resources, communication resources, or other resources), or other types of server systems having functions that a client device can use. Brief Description of the Drawings

[0003] Some implementations of the present disclosure are described with reference to the following drawings.

[0004] Figure 1 is a block diagram of an arrangement including a client device, an intermediate device, and a server system according to some examples;

[0005] Figure 2 is a message flow diagram of a process involving a client device, an intermediate device, and a server system according to some examples;

[0006] Figure 3 is a block diagram of a storage medium storing machine-readable instructions according to some examples;

[0007] Figure 4 is a block diagram of an intermediate device according to some examples; and

[0008] Figure 5 is a flowchart of a process according to some examples.

[0009] Throughout the drawings, like reference numerals represent similar but not necessarily identical elements. These figures are not necessarily drawn to scale, and the dimensions of some parts may be exaggerated to more clearly illustrate the examples shown. Additionally, the drawings provide examples and / or implementations consistent with the specification; however, the specification is not limited to the examples and / or implementations provided in the drawings. Detailed Description

[0010] An enterprise (e.g., a commercial company, a government agency, an educational organization, an individual user or group of users, or any other entity) can adopt security mechanisms to control access to services. For example, a Zero Trust Network Access (ZTNA) arrangement can be adopted to securely provide access to services according to specific access control policies. Using ZTNA or any other access control mechanism, authentication of the client device occurs before the client device can be permitted to access the service. The ZTNA arrangement includes an authentication and authorization system for authenticating the client device and authorizing the activities of the client device. The authentication and authorization system can operate according to an Authentication, Authorization, and Accounting (AAA) protocol, such as the Terminal Access Controller Access-Control System Plus (TACACS+) protocol. Another AAA protocol is the Remote Authentication Dial-In User Service (RADIUS) protocol.

[0011] Typically, a client device connects to a server system to obtain services from the server system, and the server system in turn contacts the authentication and authorization system to authenticate the client device. In such an arrangement, the server system is a client of the authentication and authorization system. For example, if the authentication and authorization system is a TACACS+ system, the server system is a TACACS+ client of the TACACS+ system.

[0012] The client device can further send commands to the server system. As described in Request for Comments (RFC) 8907, titled “The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol,” submitted in September 2020, the TACACS+ protocol provides the ability to restrict command execution based on user authorization. This is typically used when an administrator (using the client device) connects to the server system to modify the configuration of the server system. For traditional TACACS+ access, the server system must use an external access control system to obtain authorization for each command the client device attempts to execute. For example, in response to a command, the server system can contact the authentication and authorization system to determine whether the command received from the client device is authorized. If the command is authorized by the authentication and authorization system, the server system can execute the command. If the command is not authorized by the authentication and authorization system, the server system can reject the command from the client device.

[0013] There can be many client devices connected to the server system. In an arrangement including multiple server systems, an authentication and authorization system can receive a large number of requests (for authentication and authorization purposes) from the server systems. Therefore, the authentication and authorization system may have to be configured with sufficient computing power to handle potentially a large number of requests from the server systems. When deployed in an enterprise's premises, such a heavyweight (in terms of the resources supplied) authentication and authorization system can be expensive for the enterprise (e.g., due to increased equipment and software costs, increased maintenance costs, and other costs). Additionally, a large number of requests can result in a large amount of interaction between each server system and the authentication and authorization system, which consumes the processing and communication resources of the server system. As a result, the server system may become overburdened due to the authentication and authorization activities being performed for the client devices, which may reduce the server system's ability to perform its target services.

[0014] According to some implementations of the present disclosure, an intermediate device including an inline authentication and authorization engine is provided between the client device and the server system. The authentication and authorization engine is "inline" between the client device and the server system because requests associated with authentication and authorization activities from the client device are first received at the authentication and authorization engine, such that the authentication and authorization engine performs the authentication and authorization activities of the client device, and the requests do not reach the server system. As a result, the server system that is to provide various target services to the client device does not have to contact a remote authentication and authorization system to authorize the activities of the client device.

[0015] Furthermore, in some examples, an intermediate device including an inline authentication and authorization engine can be provided in a cloud computing environment. Requests associated with authentication and authorization activities from the client device can be routed through a network such as the Internet to the intermediate device in the cloud computing environment. The advantage of implementing the intermediate device in the cloud computing environment is that as the number of requests to be processed by the intermediate device increases, additional resources (including processing resources, communication resources, and storage resources) can be provided to the intermediate device on demand. With the intermediate device in the cloud computing environment, the enterprise does not have to deploy an expensive authentication and authorization system in the enterprise's premises. Instead, when resources are allocated by the cloud computing provider, the enterprise can pay for the resource usage of the intermediate device as needed.

[0016] Although reference is made to an intermediate device having an inline authentication and authorization engine in a cloud computing environment, it should be noted that in other examples, the intermediate device can be implemented in different computing environments, such as in a data center or other computing environments.

[0017] In addition to authenticating client devices, the inline authentication and authorization engine is also capable of authorizing commands issued by the client devices, where the commands are directed to the server system and cause certain operations to be initiated at the server system. In response to a command from the client device, the inline authentication and authorization engine identifies a command enforcement policy based on information about the client device, and the inline authentication and authorization engine determines whether to authorize the command based on the command enforcement policy.

[0018] Figure 1 FIG. is a block diagram of an example arrangement including a client device 102, a server system 104, and an intermediate device 106 between the client device 102 and the server system 104. Although Figure 1 one client device 102 and one server system 104 are shown, in other examples, the intermediate device 106 can be connected between multiple client devices and multiple server systems. Additionally, in other examples, there can be more than one intermediate device.

[0019] A "client device" can refer to any electronic device capable of accessing the services of the server system 104. Examples of electronic devices can include any or some combination of the following: a computer (e.g., a desktop computer, a server computer, a laptop computer, a tablet computer, or another type of computer), a smartphone, an Internet of Things (IoT) device, a household appliance, a gaming console, a vehicle, or any other type of electronic device.

[0020] The server system 104 can be implemented using one or more computers. Examples of server systems can include any or some combination of the following: a network access device providing access to a network, a web server providing web-based services, a cloud server providing cloud-based services, a storage system, or any other type of system having services accessible by client devices. Services provided by the server system 104 can include any or some combination of the following: a network access service providing access to a network, web services, applications, use of resources (e.g., processing resources, storage resources, communication resources, or other resources), or another type of functionality. In an example where the server system 104 is a network access device, the server system 104 can include a switch, a router, a gateway, or any other device allowing client devices to access the network. As discussed further below, in some examples, commands related to administrative tasks to be performed on the server system 104 (e.g., by a network administrator at the client device 102) can be authorized by the intermediate device 106.

[0021] The intermediate device 106 can be implemented using one or more computers. The intermediate device 106 is connected to the client device 102 via a communication link 108, and the intermediate device 106 is connected to the server system 104 via a communication link 110. A "communication link" can refer to any type of communication medium that allows electronic devices to communicate with each other. Examples of communication links can include wireless links or wired links, including links that are part of a network.

[0022] As Figure 1 shown, for authentication and authorization purposes, the client device 102 is not directly connected to the server system 104. A client device "directly connects" to a server system if the client device is able to transmit authentication and authorization (AA)-related messages to the server system and the AA-related messages will be processed by the server system. An "AA-related message" refers to any message that triggers an authentication task or an authorization task. A "message" can refer to a packet, an information element within a packet, or any other information unit. In Figure 1 this case, the intermediate device 106 processes the AA-related messages from the client device 102, such that the server system 104 does not have to process the AA-related messages. Effectively, the intermediate device 106 acts as a server to the client device 102, and the intermediate device 106 acts as a client to the server system 104.

[0023] According to some implementations of the present disclosure, the intermediate device 106 includes an inline authentication and authorization engine 112 that is capable of performing authentication and authorization tasks (e.g., ZTNA authentication and authorization tasks) for client devices including the client device 102. As used herein, an "engine" can refer to one or more hardware processing circuits, which can include any or some combination of the following: a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit. Alternatively, an "engine" can refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) executable on the one or more hardware processing circuits.

[0024] As Figure 1 shown, an authentication process 120 can be performed between the client device 102 and the inline authentication and authorization engine 112 to allow the intermediate device 106 to authenticate the client device 102. The client device 102 can also send a command (122) to the inline authentication and authorization engine 112. The inline authentication and authorization engine 112 can determine whether the command 122 is authorized. In some examples, the inline authentication and authorization engine 112 can authorize the command 122 based on command enforcement policy information 124 stored in the memory 126 of the intermediate device 106.

[0025] The memory may be implemented using one or more memory devices. Examples of memory devices include any or some combination of the following: dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, flash memory devices, or any other type of memory device. Although Figure 1 An example is shown where the command enforcement policy information 124 is stored in the memory 126 that is part of the intermediate device 106, but in other examples, the command enforcement policy information 124 (or a portion thereof) may be stored on an external storage device external to the intermediate device 106.

[0026] The command enforcement policy information 124 may be in the form of one or more files (or one or more other data structures). The command enforcement policy information 124 may include entries that specify the conditions under which a corresponding command is allowed (or not allowed). In other words, if the (multiple) conditions associated with a given command specified in the command enforcement policy information 124 are met, the given command is authorized (or denied).

[0027] Although some examples of entries in the command enforcement policy information 124 are listed above, in other examples, other entries may specify conditions for other commands.

[0028] In some examples, the inline authentication and authorization engine 112 is capable of using the command enforcement policy information 124 to authorize commands without having to use a dictionary provided at the server system, such as a TACACS+ dictionary. The TACACS+ dictionary provides the conversion of responses from the authentication and authorization system to device-specific information for a given server system. Removing the dictionary allows for a more precise and flexible definition of the command enforcement policy information 124 without the need to know the correct conversion applied to the actual server system.

[0029] If the inline authentication and authorization engine 112 cannot authorize the command 122 based on the command enforcement policy information 124, the inline authentication and authorization engine 112 blocks the execution of the command 122 by preventing the command 122 from being sent to the server system 104. The inline authentication and authorization engine 112 may discard the command 122 and may send an indication to the client device 102 that the command 122 was not authorized (e.g., an error indication, a rejection indication, etc.).

[0030] If the inline authentication and authorization engine 112 can authorize the command 122 based on the command enforcement policy information 124, the inline authentication and authorization engine 112 allows the intermediate device 106 to forward the command 122 to the server system 104 (the forwarded command is denoted as 122A). The server system 104 may execute the command 122A received from the intermediate device 106 to perform the (multiple) tasks requested by the command 122A.

[0031] In some examples, command 122A can be an administrative command or any other type of command that causes server system 104 to perform a task. For example, an administrative command can include an enabling command for enabling a feature (such as a program, an electronic component, a function, etc.) of server system 104. Another administrative command can be a command for disabling a feature of server system 104 or a command for shutting down server system 104. Another administrative command can be a command for opening or closing a port of server system 104, such as a port of a network access device included in server system 104. Another administrative command can be a command for allowing a user or a client device to log in to server system 104.

[0032] Commands from client device 102 can conform to a security protocol, such as the Secure Shell (SSH) protocol or other protocols. The SSH protocol provides a secure way to issue remote commands, such as the example commands mentioned above. A "security protocol" refers to any protocol used to protect communications between devices, such as between a client device and a server system.

[0033] Although some example commands are listed above, it should be noted that client device 102 can issue many other commands to server system 104. Any such command can be authorized by inline authentication and authorization engine 112 according to command enforcement policy information 124.

[0034] Examples of entries of command enforcement policy information 124 are listed below. The first entry can specify authorizing the "show run" command (which is used to cause server system 104 to show the configuration of server system 104) under the following conditions: the client device that issues the command is owned or managed by a given enterprise, and the malware protection program in the client device is up-to-date. The second entry can specify that the "enable" command (which enables a function of server system 104) is authorized under the following conditions: the client device that issues the command is owned or managed by a given enterprise, and the malware protection program in the client device is up-to-date. The third entry can specify that any administrative command is prohibited if the malware protection program in the client device has expired. The fourth entry can specify that any command is not allowed if the client device is not enterprise-owned. The fifth entry can specify that a command is allowed if the rate of incoming commands from the client device does not exceed a rate threshold (e.g., a threshold number of commands per unit time). The sixth entry can specify that a command is allowed if the client device is not connected to more than a threshold number of server systems.

[0035] In some examples, the communication between the client device 102 and the intermediate device 106 is encrypted in a first session established between the client device 102 and the intermediate device 106, and the communication between the intermediate device 106 and the server system 104 is encrypted in a second session established between the intermediate device 106 and the server system 104. In some examples, the encryption of the messages can conform to SSH encryption. In other examples, the messages can be encrypted according to other security protocols.

[0036] The first session can be established between the client device 102 and the intermediate device 106 based on the exchange of certificates or keys between the client device 102 and the intermediate device 106. Similarly, the second session can be established between the intermediate device 106 and the server system 104 based on the exchange of certificates or keys between the intermediate device 106 and the server system 104.

[0037] For example, the client device 102 can send an encrypted message to the intermediate device 106 in the first session. The encrypted message can be related to the authentication process 120 or can include a command 122. The inline authentication and authorization engine 112 can decrypt the encrypted message to obtain the decrypted message and perform authentication or authorization tasks based on the decrypted message. If the inline authentication and authorization engine 112 is to forward an authorized command to the server system 104, the inline authentication and authorization engine 112 encrypts the command and sends the encrypted command to the server system 104 in the second session.

[0038] Message encryption between the intermediate device 106 and each of the client device 102 and the server system 104 can protect the messages from unauthorized access by attackers.

[0039] In other examples, the communication between the client device 102 and the intermediate device 106, and the communication between the intermediate device 106 and the server system 104 are not encrypted.

[0040] For each command processed by the inline authentication and authorization engine 112, the inline authentication and authorization engine 112 can add an entry regarding the processed command to an audit log 128, which can be stored in the memory 126. An "audit log" can refer to any data structure for storing information related to events that have occurred in the intermediate device 106 (including processed commands). In some examples where the memory 126 is a persistent memory, the audit log 128 is persistently stored (i.e., the audit log remains stored in the memory 126 even if power is removed from the memory 126 or the intermediate device 106).

[0041] In response to processing a given command, the inline authentication and authorization engine 112 adds a corresponding entry to the audit log 128, where the corresponding entry can indicate whether the given command is authorized. Different entries are added to the audit log 128 for corresponding commands processed by the inline authentication and authorization engine 112. The audit log 128 can be reviewed by an entity (e.g., a person, a program, or a machine) to determine which commands were processed and the results of the processing of those commands.

[0042] Figure 2 is a message flow diagram of a process involving the client device 102, the intermediate device 106, and the server system 104. To perform authentication, the client device 102 can send (at 202) an authentication request to the inline authentication and authorization engine 112 in the intermediate device 106. Note that the client device 102 is able to access the server system 104 after the client device 102 is authenticated. If the client device 102 is not authenticated, the client device 102 will not be able to access the server system 104.

[0043] In response to the authentication request 202, an authentication process (at 204) is performed between the client device 102 and the inline authentication and authorization engine 112. Assuming the client device 102 has been authenticated by the inline authentication and authorization engine 112, the client device 102 is able to send commands to be executed by the server system 104. The commands sent can include SSH commands for performing administrative tasks, or other commands conforming to other protocols, whether standardized protocols, open-source protocols, or proprietary protocols.

[0044] The client device 102 sends (at 206) a command that is intercepted by the intermediate device 106. As described above, the command can be an administrative command or another type of command. In response to the command, the inline authentication and authorization engine 112 accesses (at 208) the command enforcement policy information 124 to determine whether there are any entries for the command in the command enforcement policy information 124. The inline authentication and authorization engine 112 determines (at 210) whether the command is authorized. If the command enforcement policy information 124 does not contain any entries for the command, the command is not authorized by the inline authentication and authorization engine 112. If there are entries for the command in the command enforcement policy information 124, the inline authentication and authorization engine 112 determines whether the (multiple) conditions specified for the command in the entry are satisfied. If the (multiple) conditions are not satisfied, the inline authentication and authorization engine 112 does not authorize the command. However, if the (multiple) conditions are satisfied, the inline authentication and authorization engine 112 authorizes the command.

[0045] If the command is not authorized, the in-line authentication and authorization engine 112 discards (at 212) the command, and the command is not allowed to be executed. In some examples, the in-line authentication and authorization engine 112 may also send an indication to the client device 102 that the command is not authorized.

[0046] However, if the command is authorized by the command enforcement policy, the intermediate device 106 forwards (at 214) the command to the server system 104. At the server system 104, the server system 104 executes (at 216) the command to perform a task according to the command.

[0047] By performing authentication and authorization tasks at the intermediate device 106, the intermediate device 106 does not have to interact with a remote system to perform authentication and authorization tasks. For example, the intermediate device 106 does not have to perform encryption and decryption of AA-related messages (which would otherwise be performed in the communication between the intermediate device 106 and the remote system). In addition, not transmitting AA-related messages outside the intermediate device 106 avoids exposing AA-related messages to external attackers. Further, if the intermediate device 106 is implemented in a cloud computing environment, the enterprise does not have to maintain a local device to support in-line authentication and authorization tasks.

[0048] In addition, the command enforcement policy information 124 can be dynamically updated over time, such as by an administrator or other entity. For example, as new commands are added or commands are modified, and as the conditions under which commands are allowed are changed, the command enforcement policy information 124 can be updated accordingly. This increases the flexibility of authorizing commands.

[0049] In some examples, the in-line authentication and authorization engine 112 can add information (whether allowed or discarded) for each processed command to the audit log 128 ( Figure 1 ).

[0050] Figure 3 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 that stores machine-readable instructions that, when executed, cause an intermediate device to perform various tasks. An example of an intermediate device is Figure 1 the intermediate device 106.

[0051] The machine-readable instructions include client command receiving instructions 302 for receiving, at the intermediate device, a command associated with a security protocol from a client device, the security protocol ensuring a connection between the client device and the server system. The intermediate device includes an in-line authentication and authorization service between the client device and the server system. For example, the in-line authentication and authorization service is provided by Figure 1Services performed by the inline authentication and authorization engine 112. An example of a security protocol is the SSH protocol, which ensures message communication (encryption-based application) between a client device and a server system and provides command communication to a remote entity such as the server system, where commands can control features of the server system.

[0052] The machine-readable instructions include command authorization instructions 304 for determining whether to authorize a command received from a client device based on command enforcement policy information (e.g., Figure 1 124 in

[0053] In some examples, a command received from a client device at an intermediate device is in encrypted form. The machine-readable instructions can decrypt the command to produce a decrypted command, and authorization is performed for the decrypted command. Based on the authorization of the decrypted command, the machine-readable instructions can re-encrypt the decrypted command to produce an encrypted command, and the machine-readable instructions can cause the encrypted command to be sent from the intermediate device to the server system.

[0054] In some examples, the machine-readable instructions can establish a first session between the intermediate device and the client device, where the encrypted command is received from the client device in the first session. The machine-readable instructions can allow or deny the establishment of a second session between the intermediate device and the server system, where the sending of the encrypted command from the intermediate device to the server system occurs in the second session.

[0055] In some examples, the inline authentication and authorization service can use a certificate of the client device to authenticate the client device. In some examples, the authentication of the client device and the authorization of the command are performed without involving the server system.

[0056] In some examples, the intermediate device is in a cloud computing environment.

[0057] In some examples, the machine-readable instructions can update an audit log by adding information related to the command to the audit log (e.g., Figure 1 128 in

[0058] In some examples, the conditions specified by the command enforcement policy information can include conditions based on ownership information indicating the owner or manager of the client device (e.g., the client device is owned or managed by an enterprise).

[0059] In some examples, the conditions specified by the command enforcement policy information can include conditions based on information about malware protection programs of a client device.

[0060] In some examples, the conditions specified by the command enforcement policy information can include conditions based on the rate of commands received from a client device.

[0061] In some examples, the conditions specified by the command enforcement policy information can include conditions based on the number of server systems to which a client device is connected.

[0062] Figure 4 is a block diagram of an intermediate device 400 according to some examples. The intermediate device 400 includes a hardware processor 402 (or multiple hardware processors). The hardware processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

[0063] The intermediate device 400 includes a storage medium 404 that stores machine-readable instructions for an in-line authentication and authorization service 406, which are executable on the hardware processor to perform various tasks. The in-line authentication and authorization service 406 is provided between a client device and a server system. The machine-readable instructions executable on the hardware processor can refer to instructions executable on a single hardware processor or instructions executable on multiple hardware processors.

[0064] The machine-readable instructions in the storage medium 404 include client command receiving instructions 408 for receiving, at the in-line authentication and authorization service, commands from a client device for controlling features of a server system. The command can conform to a security protocol such as the SSH protocol.

[0065] The machine-readable instructions in the storage medium 404 include command authorization instructions 410 for the in-line authentication and authorization service 406 to determine whether to authorize a command received from a client device according to command enforcement policy information. The command enforcement policy information can include entries containing conditions under which the corresponding command is allowed (or prohibited).

[0066] The machine-readable instructions include command forwarding instructions 412 for causing a command to be sent from the intermediate device 400 to a server system for execution at the server system based on determining that the command is authorized according to the command enforcement policy information.

[0067] In some examples, the intermediate device 400 appears as a server to a client device, and the intermediate device appears as a client to a server system.

[0068] Figure 5 is a flowchart of a process 500 according to some examples. The process 500 can be performed by an intermediate device (e.g.,Figure 1 is executed at 106).

[0069] Process 500 includes performing (at 502), by an inline authentication and authorization service in an intermediate device, an authentication process with a client device, where the inline authentication and authorization service is between the client device and the server system. The authentication process can be triggered by, for example, an authentication request from the client device.

[0070] Process 500 includes receiving (at 504), during the authentication process after authenticating the client device, a command associated with a security protocol from the client device. In some examples, the security protocol can be the SSH protocol.

[0071] Process 500 includes determining (at 506), by the inline authentication and authorization service in accordance with policy information for the command, whether to authorize the command received from the client device.

[0072] Based on determining that the command is authorized in accordance with policy information for the command, process 500 includes sending (at 508) the command from the intermediate device to the server system for execution at the server system.

[0073] A storage medium (e.g., Figure 3 300 in or Figure 4 404 in) can include any or some combination of the following: semiconductor memory devices such as DRAM or SRAM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed disks, floppy disks, and removable disks; another magnetic medium including magnetic tape; optical media such as compact discs (CDs) or digital versatile discs (DVDs); or another type of storage device. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system that may have multiple nodes. Such one or more computer-readable or machine-readable storage media are considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any single manufactured component or multiple components. One or more storage media can be located in a machine that runs the machine-readable instructions, or at a remote site from which the machine-readable instructions can be downloaded over a network for execution.

[0074] In this disclosure, unless the context clearly dictates otherwise, the use of the terms "a", "an", or "the" also includes the plural forms. Additionally, when used in this disclosure, the terms "includes", "including", "comprises", "comprising", "have", or "having" specify the presence of the stated element, but do not preclude the presence or addition of other elements.

[0075] In the foregoing description, numerous specific details are set forth to provide a thorough understanding of the subject matter disclosed herein. However, implementations may be practiced without these specific details. Other implementations may include modifications and variations to the above details. The appended claims are intended to cover such modifications and variations.

Claims

1. A non-transitory machine-readable storage medium, comprising instructions that, when executed, cause an intermediate device to: Receive, at the intermediate device, a command associated with a security protocol from a client device, the security protocol ensuring a connection between the client device and a server system, wherein the intermediate device includes an inline authentication and authorization service between the client device and the server system; and Determine, by the inline authentication and authorization service at the intermediate device, whether to authorize the command received from the client device based on policy information for the command.

2. The non-transitory machine-readable storage medium according to claim 1, wherein the server system includes a network access device that provides access to a network by the client device.

3. The non-transitory machine-readable storage medium according to claim 1, wherein the security protocol includes a Secure Shell (SSH) protocol and the command is associated with the SSH protocol.

4. The non-transitory machine-readable storage medium according to claim 1, wherein the command is used to control a feature of the server system and the command is protected by the security protocol.

5. The non-transitory machine-readable storage medium according to claim 1, wherein the command received from the client device at the intermediate device is in an encrypted form, and wherein the instructions, when executed, cause the intermediate device to: Decrypt the command to produce a decrypted command, wherein the authorization is performed for the decrypted command; And Based on the authorization of the decrypted command, re-encrypt the decrypted command to produce an encrypted command; And Cause the encrypted command to be sent from the intermediate device to the server system.

6. The non-transitory machine-readable storage medium according to claim 5, wherein the instructions, when executed, cause the intermediate device to: Establish a first session between the intermediate device and the client device, wherein the command in the encrypted form is received from the client device in the first session; and Establish a second session between the intermediate device and the server system, wherein the sending of the encrypted command from the intermediate device to the server system occurs in the second session.

7. The non-transitory machine-readable storage medium according to claim 1, wherein the instructions, when executed, cause the intermediate device to: Authenticate the client device by the inline authentication and authorization service using a certificate of the client device.

8. The non-transitory machine-readable storage medium according to claim 7, wherein the authentication of the client device and the authorization of the command are performed without involving the server system.

9. The non-transitory machine-readable storage medium according to claim 1, wherein the intermediate device is in a cloud computing environment.

10. The non-transitory machine-readable storage medium according to claim 1, wherein the instructions, when executed, cause the intermediate device to: Update an audit log by adding information related to the command to the audit log, wherein the audit log includes information about commands processed at the inline authentication and authorization service in the intermediate device.

11. The non-transitory machine-readable storage medium according to claim 1, wherein the command enforcement policy information specifies one or more conditions under which the corresponding command is permitted.

12. The non-transitory machine-readable storage medium according to claim 11, wherein the one or more conditions include a condition based on ownership information indicating an owner or administrator of the client device.

13. The non-transitory machine-readable storage medium according to claim 11, wherein the one or more conditions include a condition based on information of a malware protection program of the client device.

14. The non-transitory machine-readable storage medium according to claim 11, wherein the one or more conditions include a condition based on a rate of commands received from the client device.

15. The non-transitory machine-readable storage medium according to claim 11, wherein the one or more conditions include a condition based on a number of server systems to which the client device is connected.

16. An intermediate device, comprising: a hardware processor; and a non-transitory storage medium including instructions for an in-line authentication and authorization service, the instructions being executable on the hardware processor to: receive, at the in-line authentication and authorization service, a command from a client device for controlling a feature of a server system, wherein the in-line authentication and authorization service is provided between the client device and the server system; determine, at the intermediate device by the in-line authentication and authorization service, whether to authorize the command received from the client device according to command enforcement policy information; and based on determining that the command is authorized according to the command enforcement policy information, cause the command to be sent from the intermediate device to the server system for execution at the server system.

17. The intermediate device according to claim 16, wherein the intermediate device acts as a server to the client device and acts as a client to the server system.

18. The intermediate device according to claim 16, wherein the instructions are executable on the hardware processor to: receive, at the in-line authentication and authorization service, an authentication request from a client device; and based on receiving the authentication request, perform an authentication process between the client device and the intermediate device to authenticate the client device, wherein the command from the client device is transmitted by the client device after the authentication of the client device.

19. A method, comprising: performing, by an in-line authentication and authorization service in an intermediate device, an authentication process with a client device, wherein the in-line authentication and authorization service is between the client device and a server system; after authentication of the client device during the authentication process, receiving a command associated with a security protocol from the client device; determining, by the in-line authentication and authorization service, whether to authorize the command received from the client device according to command enforcement policy information; and Based on determining that the command is authorized according to the implementation of the policy information for the command, sending the command from the intermediate device to the server system for execution at the server system.

20. The method according to claim 19, wherein the command is an administrative command for controlling a feature of the server system.

Images