COMMAND VALIDATION IN AN INTERMEDIATE DEVICE

Abstract

In some examples, an intermediate device receives a command from a client device associated with a secure protocol that secures a connection between the client device and a server system, where the intermediate device includes an inline authentication and authorization service between the client device and the server system. The authentication and authorization service at the intermediate device determines whether to authorize the command received from the client device based on information about the command enforcement policy.

Description

BackgroundClient devices may access services provided by server systems. An example of a server system is a network access device (NAD) to which a client device can connect to access a network. Further examples of server systems include server systems that provide programs (e.g., web programs, application programs, or other programs) that may be used by client devices, resources (e.g., processing resources, storage resources, communication resources, or other resources) that may be accessed by client devices as needed, or other types of server systems having functionalities that may be used by client devices.Brief Description of the DrawingsSome embodiments of the present disclosure will be described with reference to the following drawings. FIG. 1 is a block diagram of an arrangement including a client device, an intermediate device, and a server system, in accordance with some examples. FIG. 2 is a message flow diagram of a process involving the client device, the intermediate device, and the server system, in accordance with some examples. FIG. 3 is a block diagram of a storage medium storing machine readable instructions, according to some examples. FIG. 4 is a block diagram of an intermediate device, in accordance with some examples. FIG. 5 is a flow diagram of a method according to some examples.In the drawings, identical reference numerals designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to clarify the example shown. Moreover, the drawings include examples and / or embodiments consistent with the description; however, the description is not limited to the examples and / or embodiments illustrated in the drawings.Detailed DescriptionA business (e.g., a business business, government agency, imaging facility, a single user or group of users, or other entity) may employ security mechanisms to control access to the services. For example, a Zero Trust Network Access (ZTNA) agreement may be used to ensure access to the services according to specific access control policies. In the case of ZTNA or another access control mechanism, authentication of a client device takes place before the client device can be allowed to access the services. A ZTNA arrangement comprises an authentication and authorization system for authenticating client devices and for authorizing activities of the client devices. The authentication and authorization system may 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.Typically, a client device connects to a server system to take services of the server system, and the server system in turn contacts an 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. If the authentication and authorization system is, for example, a TACACS+ system, then the server system is a TACACS+ client of the TACACS+ system.The client device may also send commands to the server system. The TACACS+ protocol described in Request for Comments (RFC) 8907 entitled "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol", dated September 2020, provides the ability to limit instruction execution based on user authorization. This is typically used when administrators (with client devices) connect to server systems to change configurations of a server system. In conventional TACACS+ access, the server system must use an external access control system to obtain the permissions for each command that the client device is attempting to execute. For example, in response to the commands, the server system may contact an authentication and authorization system to determine whether the commands received from the client device are authorized. When a command is authorized by the authentication and authorization system, the server system may execute the command. If a command from the authentication and authorization system is not authorized, the server system may reject the command from the client device.There may be many client devices that connect to the server system. In an arrangement comprising multiple server systems, the authentication and authorization system may receive a large number of requests (for authentication and authorization purposes) from the server systems. As a result, the authentication and authorization system must be configured with sufficient computing power to process the potentially large amount of requests from the server systems. Such a heavy weight (with respect to resources provided) authentication and authorization system, when deployed at the premises of a company, may be expensive for the company (e.g., due to increased cost of equipment and software, increased maintenance costs, and other costs). In addition, the large number of requests may result in a large number of interactions 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 congested with authentication and authorization activities for client devices, which may reduce the capacity of the server system to provide its target services.In accordance with some implementations of the present disclosure, an intermediate device having an inline authentication and authorization engine is provided between a client device and a server system. The authentication and authorization engine is "inline" between the client device and the server system in the sense that requests associated with authentication and authorization activities from the client device are first received at the authentication and authorization engine, so that the authentication and authorization engine can perform the authentication and authorization activities for 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 need to contact a remote authentication and authorization system to authorize client device activities.In some examples, the intermediary device including the inline authentication and authorization engine may be provided in a cloud computing environment. Requests associated with authentication and authorization activities of client devices may be forwarded over a network such as the Internet to the intermediary device in the cloud computing environment. An advantage of implementing the intermediary in the cloud computing environment is that additional resources (including processing resources, communication resources, and storage resources) may be provided to the intermediary as needed as the amount of requests to be processed by the intermediary increases. With the intermediary device in the cloud computing environment, a business would not need to establish a costly authentication and authorization system in the premises of the business. Instead, the enterprise may pay for the use of the resources for the intermediary device as needed, as the resources are allocated by a cloud computing provider.Although reference is made to an intermediary device having an inline authentication and authorization engine in a cloud computing environment, it should be appreciated that in other examples, the intermediary device may be implemented in another computing environment, such as a data center or other computing environment.In addition to authenticating client devices, the inline authentication and authorization module is also capable of authorize commands issued by client devices, the commands being targeted to a server system and causing certain actions to be initiated at the server system. In response to a command from a client device, the inline authentication and authorization module identifies a command enforcement policy based on information about the client device, and the inline authentication and authorization module determines whether to authorize the command based on the command enforcement policy.FIG. 1 is a block diagram of an example arrangement that includes a client device 102, a server system 104, and an intermediate device 106 between the client device 102 and the server system 104. Although FIG. 1 shows a client device 102 and a server system 104, in other examples, the intermediate device 106 may be connected between multiple client devices and multiple server systems. Also, in further examples, there may be more than one intermediate device.A "client device" may refer to any electronic device capable of accessing the services of the server system 104. Examples of electronic devices may be any one or combination of the following devices: a computer (e.g., a desktop computer, a server computer, a notebook computer, a tablet computer, or other type of computer), a smartphone, an Internet of Things (IOT) device, a household appliance, a gaming device, a vehicle, or other type of electronic device.The server system 104 may be implemented with one or more computers. Examples of server systems may include one or a combination of the following: a network access device that provides access to a network, a web server that provides web-based services, a cloud server that provides cloud-based services, a storage system, or any other type of system that has services that can be accessed by client devices. Services offered by the server system 104 may include any one or combination of the following: a network access service that provides access to a network, a web service, an application program, the use of resources (e.g., processing resources, storage resources, communication resources, or other resources), or other types of functionalities. In examples where the server system 104 is a network access device, the server system 104 may include a switch, router, gateway, or other device that allows client devices to access a network. As discussed further below, in some examples, commands issued by the client device 102 (e.g., by a network administrator at the client device 102) and related to management tasks to be performed with respect to the server system 104 may be authorized by the intermediary device 106.The switch 106 may be implemented with 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" may refer to any type of communication medium that allows electronic devices to communicate with each other. Examples of communication links may be wireless links or wired links, including links that are part of networks.As shown in FIG. 1, the client device 102 is not directly connected to the server system 104 for authentication and authorization purposes. A client device is "directly connected to a server system" when the client device is capable of communicating authentication and authorization related messages (AA) with the server system and the AA related message is to 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" may refer to a packet, an information element within a packet, or another information unit. In FIG. 1, the intermediary device 106 handles an AA-related message from the client device 102 so that the server system 104 does not need to handle the AA-related messages. Effectively, the intermediary device 106 behaves as a server for the client device 102, and the intermediary device 106 behaves as a client for the server system 104.In accordance with some implementations of the present disclosure, the intermediary 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" may refer to one or more hardware processing circuits, which may include any one or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuit. Alternatively, an "engine" may 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.As shown in FIG. 1, an authentication process 120 may 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 may also send a command (122) to the inline authentication and authorization engine 112. The inline authentication and authorization engine 112 may determine whether the command 122 is authorized. In some examples, the inline authentication and authorization engine 112 may authorize the command 122 based on command enforcement policy information 124 stored in a memory 126 of the intermediary 106.A memory may be realized by one or more memory devices. Examples of memory devices include any one or a combination of the following: a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory device, or any other type of memory device. Although FIG. 1 shows an example where the information to enforce the command policies 124 is stored in memory 126, which is part of the intermediary device 106, in other examples, the information to enforce the command policies 124 (or a portion thereof) may be stored on an external memory that is external to the intermediary device 106.The instruction force policy information 124 may be in the form of one or more files (or in one or more other data structures). The instruction force policy information 124 may include entries that indicate the conditions under which the respective instructions are permitted (or not permitted). In other words, a given command is permitted (or rejected) when the condition(s) associated with the given command as indicated in the command enforcement policy information 124 is(are) satisfied.Although some examples of entries of instruction force policy 124 are listed above, in other examples, other entries may indicate conditions for other instructions.In some examples, the inline authentication and authorization engine 112 is capable of authorize commands using the command force policy information 124 without having to use dictionaries, such as TACACS+ dictionaries, provided on server systems. A TACACS+ dictionary provides a translation of a response from an authentication and authorization system into device specific information for a particular server system. Removing the dictionary allows more precise and flexible definitions of instruction force policy information without knowing the correct translation for the actual server system.If the inline authentication and authorization system 112 is unable to authorize the command 122 according to the information about the penetration policy for commands 124, the inline authentication and authorization system 112 inhibits execution of the command 122 by inhibiting the command 122 from being sent to the server system 104. The inline authentication and authorization engine 112 may discard the command 122 and send an indication (e.g., an error indication, a rejection indication, etc.) to the client device 102 that the command 122 is unauthorized.If the inline authentication and authorization engine 112 is capable of authorize the command 122 according to the command enforcement policy information 124, then the inline authentication and authorization engine 112 allows the intermediary device 106 to forward the command 122 to the server system 104 (the forwarded command is represented as 122A). The server system 104 may execute the command 122A received from the intermediary device 106 to perform the task(s) requested by the command 122A.In some examples, the command 122A may be a management command or other type of command that causes the server system 104 to perform a task. The administrative commands may include, for example, an activation command to activate a function (e.g., a program, electronic component, functionality, etc.) of the server system 104. Another administrative command may be a command to disable a function of the server system 104 or a command to power down the server system 104. Another administrative command may be a command to turn a port of the server system 104 on or off, such as a port of a network access device included in the server system 104. Another management command may be a command that allows a user or client device to log into the server system 104.Commands from the client device 102 may be via a secure protocol such as the secure shell (SSH) protocol or another protocol. The SSH protocol provides a secure way to issue remote commands, such as the example commands mentioned above. A "secure protocol" refers to any protocol that ensures communication between devices, e.g., between a client device and a server system.Although some example commands are listed above, there may be numerous other commands that may be issued from the client device 102 to the server system 104. Such commands may be authorized by the inline authentication and authorization engine 112 according to the command enforcement policy information 124.Examples of entries of the instruction force policy information 124 are given below. A first entry may specify that a "show run" command (causing the server system 104 to indicate a configuration of the server system 104) is permitted under the following conditions: a client device that issued the command belongs to or is managed by a particular enterprise, and a malware protection program in the client device is up-to-date. A second entry may indicate that an "enable" command (activating a function of the server system 104) is authorized under the following conditions: a client device that issued the command belongs to or is managed by a particular enterprise, and a malware protection program in the client device is up-to-date. A third entry may specify that a management command is not allowed when a malware protection program on the client device is expired. A fourth entry may specify that all commands are not permitted if the client device does not belong to the enterprise. A fifth entry may specify that a command is allowed if the number of commands arriving from the client device does not exceed a threshold (e.g., the number of commands per unit time). A sixth entry may specify that a command is allowed if the client device is not connected to more than a particular number of server systems.In some examples, communication between the client device 102 and the broker device 106 is encrypted in a first session established between the client device 102 and the broker device 106, and communication between the broker device 106 and the server system 104 is encrypted in a second session established between the broker device 106 and the server system 104. In some examples, the encryption of messages may be according to SSH encryption. In other examples, the messages may be encrypted according to other secure protocols.The first session may be established between the client device 102 and the broker device 106 based on the exchange of login information or keys between the client device 102 and the broker device 106. Similarly, the second session between the broker device 106 and the server system 104 may be established based on the exchange of credentials or keys between the broker device 106 and the server system 104.For example, in the first session, client device 102 may send an encrypted message to broker device 106. The encrypted message may refer to the authentication method 120 or include the command 122. The inline authentication and authorization system 112 may decrypt the encrypted message to derive a decrypted message and perform an authentication or authorization task corresponding to the decrypted message. When the inline authentication and authorization module 112 is to forward an authorized command to the server system 104, the inline authentication and authorization module 112 encrypts the command and sends the encrypted command to the server system 104 in the second session.Encrypting the messages between the intermediate device 106 and each of the client devices 102 and the server system 104 protects the messages from unauthorized access by attackers.In other examples, the communication between the client device 102 and the broker device 106, as well as the communication between the broker device 106 and the server system 104, is not encrypted.For each command processed by the inline authentication and authorization engine 112, the inline authentication and authorization engine 112 may include an entry regarding the processed command in a audit log 128, which may be stored in the memory 126. A "test protocol" may refer to any data structure in which information about events, including processed commands, that have occurred in the switching device 106 is stored. In some examples where the memory 126 is persistent memory, the test log 128 is persistently stored (i.e., the test log 128 remains stored in the memory 126 even when power to the memory 126 or the interposer 106 is interrupted).In response to processing a given command, inline authentication and authorization engine 112 inserts a corresponding entry into audit log 128, where the corresponding entry may indicate whether the given command was authorized. For corresponding commands processed by the inline authentication and authorization engine 112, different entries are added to the audit log 128. The test log 128 may be reviewed by a device (e.g., a human, program, or machine) to determine which instructions were processed and which results had the processing of the instructions.FIG. 2 is a message flow diagram of a process involving client device 102, intermediate device 106, and server system 104. To perform authentication, the client device 102 may send (at 202) an authentication request to the inline authentication and authorization system 112 in the intermediary 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 cannot access the server system 104.In response to the authentication request 202, an authentication procedure is performed (at 204) between the client device 102 and the inline authentication and authorization engine 112. Assuming that the client device 102 has been authenticated by the inline authentication and authorization engine 112, the client device 102 may send commands executed by the server system 104. The commands sent may include SSH commands for performing administration tasks or other commands according to other protocols, be they standardized protocols, open source protocols or proprietary protocols.The client device 102 sends (at 206) a command intercepted by the intermediate device 106. As mentioned above, the command may be a management command or another type of command. In response to the command, the inline authentication and authorization system 112 accesses the command enforcement policy information 124 (at 208) to determine whether an entry exists in the command enforcement policy information 124 for the command. The inline authentication and authorization module 112 determines (at 210) whether the command is authorized. The command is not authorized by the inline authentication and authorization engine 112 if the command force policy information 124 does not contain an entry for the command. If an entry for the command is present in the instruction force policy information 124, the inline authentication and authorization system 112 determines whether the condition(s) for the command indicated in the entry is(are) satisfied. If the condition(s) are not(are) satisfied, the inline authentication and authorization system 112 does not authorize the command. However, if the condition(s) is(are) satisfied, the inline authentication and authorization system 112 authorizes the command.If the command is not authorized, the inline authentication and authorization system 112 discards the command (at 212) and the command is not permitted to be executed. In some examples, the inline authentication and authorization engine 112 may also send an indication to the client device 102 that the command is unauthorized.However, if the command is authorized by the command force policy, the intermediary device 106 forwards the command to the server system 104 (by 214). In the server system 104, the server system 104 executes the command (at 216) to execute a task corresponding to the command.By performing the authentication and authorization tasks on the intermediary device 106, the intermediary device 106 would not need to interact with a remote system to perform the authentication and authorization tasks. For example, the intermediary device 106 would not need to perform encryption and decryption of AA-related messages that would otherwise occur in communication between the intermediary device 106 and the remote system. By not communicating AA-related messages outside the intermediary device 106, the AA-related messages are also prevented from being exposed to external attackers. Additionally, if the intermediary device 106 is implemented in a cloud computing environment, a company would not need to maintain devices on site to support inline authentication and authorization tasks.Moreover, the instruction force policy information 124 may be dynamically updated over time, e.g., by an administrator or other entity. For example, if new commands are added or commands are changed, and if the conditions under which commands are allowed are changed, the information on the command force policy 124 may be updated accordingly. This increases the flexibility of how commands are authorized.In some examples, the inline authentication and authorization engine 112 may include information about each processed command (whether permitted or discarded) in the audit log 128 (FIG. 1 ).FIG. 3 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 storing machine-readable instructions that, when executed, cause an intermediate device to perform various tasks. An example of the intermediate device is the intermediate device 106 from FIG. 1.The machine readable instructions include client command receiving instructions 302 to receive at the intermediate device from a client device a command associated with a secure protocol that ensures connection between the client device and a server system. The intermediate device includes an inline authentication and authorization service between the client device and the server system. The inline authentication and authorization service is, for example, a service executed by the inline authentication and authorization engine 112 of FIG. 1. An example of a secure protocol is the SSH protocol that secures communication (based on application of encryption) of messages between a client device and a server system and enables communication of commands to a remote entity such as the server system, which commands may control functions of the server system.The machine readable instructions include command authorization instructions 304 to determine, by the inline authentication and authorization service at the intermediary device, whether to authorize the command received from the client device based on command enforcement policy information (e.g., 124 in FIG. 1 ). The instruction force policy information may include entries with conditions under which the respective instructions are allowed (or not allowed).In some examples, the command that the intermediary device receives from the client device is in an encrypted form. The machine readable instructions may decrypt the instruction to generate a decrypted instruction, and the authorization is performed with respect to the decrypted instruction. Based on the authorization of the decrypted command, the machine readable instructions may re-encrypt the decrypted command to generate an encrypted command, and the machine readable instructions may cause the encrypted command to be sent from the intermediate device to the server system.In some examples, the machine readable instructions may establish a first session between the intermediate device and the client device, wherein the command is received in the encrypted form from the client device in the first session. The machine readable instructions may allow or deny establishment of a second session between the intermediate device and the server system, wherein transmission of the encrypted command from the intermediate device to the server system occurs in the second session.In some examples, the inline authentication and authorization service may authenticate the client device based on a certificate of the client device. In some examples, authentication of the client device and authorization of the command are performed without involvement of the server system.In some examples, the intermediary device is in a cloud computing environment.In some examples, the machine readable instructions may update a test log (e.g., 128 in FIG. 1 ) by adding information about the instruction to the test log. The verification protocol contains information about commands processed in the inline authentication and authorization service in the intermediate device.In some examples, the conditions specified by the command force policy information may include a condition based on ownership information indicating an owner or manager of the client device (e.g., the client device is owned or managed by a company).In some examples, the conditions specified by the command force policy information may include a condition based on information of a malware protection program of the client device.In some examples, the conditions specified by the command force policy information may include a condition based on a rate of commands received from the client device.In some examples, the conditions specified by the command force policy information may include a condition based on the number of server systems to which the client device is connected.FIG. 4 is a block diagram of an intermediate device 400, in accordance with some examples. The intermediary 400 includes a hardware processor 402 (or multiple hardware processors). A hardware processor may include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuit.The intermediate device 400 includes a storage medium 404 having machine readable instructions stored thereon of an inline authentication and authorization service 406 executable on the hardware processor to perform various tasks. The inline authentication and authorization service 406 is provided between the client device and the server system. Machine readable instructions executable on a hardware processor may refer to the instructions executable on a single hardware processor or on multiple hardware processors.The machine readable instructions in storage medium 404 include client command receiving instructions 408 to receive, at inline authentication and authorization service 406, from a client device a command to control a function of a server system. The command may be according to a secure protocol such as the SSH protocol.The machine readable instructions in storage medium 404 include instruction authorization instructions 410 to determine, by inline authentication and authorization service 406, according to the instruction throughput policy information, whether to authorize the instruction received from the client device. The instruction force policy information may include entries with conditions under which corresponding instructions are permitted (or prohibited).The machine readable instructions include command forwarding instructions 412 to cause the command to be sent from the intermediate device 400 to the server system for execution in the server system based on the determination that the command is authorized according to the instruction force policy information.In some examples, the intermediary 400 behaves as a server for the client device and the intermediary behaves as a client for the server system.FIG. 5 is a flowchart of a process 500 according to some examples. The process 500 may be performed by an intermediary device (e.g., 106 in FIG. 1 ).The process 500 includes performing (at 502), with the client device, an authentication procedure by an inline authentication and authorization service in the intermediary device, wherein the inline authentication and authorization service exists between the client device and a server system. The authentication procedure may be triggered by an authentication request, e.g., from the client device.The process 500 includes receiving (at 504) a command associated with a secure protocol from the client device after authenticating the client device in the authentication process. The secure protocol may be the SSH protocol in some examples.The process 500 includes determining (at 506), by the inline authentication and authorization service, according to the command enforcement policy information whether to authorize the command received from the client device.Based on the determination that the command is authorized according to the command force policy information, the process 500 includes sending (at 508) the command from the intermediate device to the server system for execution in the server system.A storage medium (e.g., 300 in FIG. 3 or 404 in FIG. 4 ) may include any one or a combination of the following: a semiconductor memory device such as a DRAM or SRAM, an erasable and programmable read only memory (EPROM), an electrically erasable and programmable read only memory (EEPROM), and a flash memory; a magnetic disk such as a hard disk, a floppy disk, and a removable disk; another magnetic medium including a tape; an optical medium such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. It should be appreciated that the instructions described above may be provided on a single computer- or machine-readable storage medium, or alternatively on multiple computer- or machine-readable storage media distributed in a large system having possibly multiple nodes. Such a computer readable or machine readable storage medium or media is considered part of an article (or article of manufacture). An article or article of manufacture may refer to any individual component or multiple components produced. The storage medium or media may be located either on the machine on which the machine readable instructions are executed or at a remote location from which machine readable instructions may be downloaded via a network for execution.In the present disclosure, the use of the term "a", "an" or "the" also includes the plural forms unless the context clearly indicates otherwise. Also, the term "comprises", "including", "comprises", "comprises", "have" or "have" when used in this disclosure specifies the presence of the stated elements, but does not exclude the presence or addition of other elements.In the foregoing description, numerous details are set forth in order to provide an understanding of the subject matter disclosed herein. However, implementations without some of these details may be practiced. Other implementations may include modifications and variations from the details described above. It is intended that the appended claims cover such modifications and variations.References included in the specificationThis list of documents cited by the applicant has been produced in an automated manner and is only included for the better information of the reader. The list is not part of the German patent application or utility model application. The DPMA does not take any adhesion for any faults or omissions.Cited Non-Patent LiteratureThe Terminal Access Controller Access-Control System Plus (TACACS+) Protocol", dated September 2020

[0006]

Claims

A non-transitory machine readable storage medium containing instructions that, when executed, cause an intermediate device to: receive a command associated with a secure protocol that secures a connection between the client device and a server system at the intermediate device of a client device, the intermediate device comprising 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 command enforcement policy information.The non-transitory machine readable storage medium of claim 1, wherein the server system comprises a network access device that enables access to a network by the client device.The non-transitory machine readable storage medium of claim 1, wherein the secure protocol comprises a secure shell (SSH) protocol and the instruction is associated with the SSH protocol.The non-transitory machine readable storage medium of claim 1, wherein the command is to control a feature of the server system and the command is protected by the secure protocol.The non-transitory machine readable storage medium of claim 1, wherein the command received at the intermediate device from the client device is in encrypted form, and wherein the instructions, when executed, cause the intermediate device to: decrypt the command to generate a decrypted command, wherein the authorization is performed with respect to the decrypted command; and based on the authorization of the decrypted command, re-encrypt the decrypted command to generate an encrypted command; and cause the transmission of the encrypted command from the intermediate device to the server system.The non-transitory machine readable storage medium of 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 is received in the encrypted form 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.The non-transitory machine readable storage medium of claim 1, wherein the instructions, when executed, cause the intermediate device to: authenticate, by the inline authentication and authorization service, the client device using a certificate of the client device.The non-transitory machine readable storage medium of claim 7, wherein the authentication of the client device and the authorization of the command are performed without any involvement of the server system.The non-transitory machine readable storage medium of claim 1, wherein the intermediate device is in a cloud computing environment.The non-transitory machine readable storage medium of claim 1, wherein the instructions, when executed, cause the intermediate device to: update a verification log by adding information related to the command to the verification log, the verification log comprising information about commands processed at the inline authentication and authorization service in the intermediate device.The non-transitory machine readable storage medium of claim 1, wherein the information about the passage of instructions indicates one or more conditions under which corresponding instructions are permitted.The non-transitory machine readable storage medium of claim 11, wherein the one or more conditions comprise a condition based on property information indicative of an owner or manager of the client device.The non-transitory machine readable storage medium of claim 11, wherein the one or more conditions comprise a condition based on information of a malware protection program of the client device.The non-transitory machine readable storage medium of claim 11, wherein the one or more conditions comprise a condition based on a rate of instructions received from the client device.The non-transitory machine readable storage medium of claim 11, wherein the one or more conditions comprise a condition based on a number of server systems to which the client device is connected.An intermediate device comprising: a hardware processor; and a non-transitory storage medium including instructions of an inline authentication and authorization service executable on the hardware processor to: receive, at the inline authentication and authorization service from a client device, a command to control a feature of a server system, wherein the inline authentication and authorization service is provided between the client device and the server system; determine, by the inline authentication and authorization service at the intermediate device, according to the command forcing policy information, whether to authorize the command received from the client device; and based on the determination that the command is authorized according to the information about the command force policy, causing the command to be sent from the intermediate device to the server system for execution in the server system.The intermediate device of claim 16, wherein the zwife device behaves as a server with respect to the client device and as a client with respect to the server system.The intermediary device of claim 16, wherein the instructions are executable on the hardware processor to: receive an authentication request from a client device at the inline authentication and authorization service; and perform an authentication procedure between the client device and the intermediary device based on the receipt of the authentication request to authenticate the client device, wherein the command is transmitted from the client device from the client device after authentication of the client device.A method comprising: performing an authentication method with a client device by an inline authentication and authorization service in an intermediate device, wherein the inline authentication and authorization service exists between the client device and a server system; receiving a command associated with a secure protocol from the client device after authentication of the client device in the authentication procedure; determining, by the inline authentication and authorization service according to the Befehlserzwingungsrichtlinieninformation whether to authorize the command received from the client device; and based on the determination that the command is authorized according to the information of the command force policy, sending the command from the intermediate device to the server system for execution in the server system.The method of claim 19, wherein the command is a management command for controlling a function of the server system.

Images