US20220158977A1

US20220158977A1 - Authenticating to a hybrid cloud using intranet connectivity as silent authentication factor

Info

Publication number: US20220158977A1
Application number: US17/589,149
Authority: US
Inventors: Feng Huang; Andrew David Cooper
Original assignee: Citrix Systems Inc
Current assignee: Citrix Systems Inc
Priority date: 2018-11-14
Filing date: 2022-01-31
Publication date: 2022-05-19
Also published as: WO2020102497A1; EP3881203A1; US11258756B2; US20200153792A1

Abstract

A technique for performing authentication to a hybrid-cloud service includes selectively applying varying authentication requirements based on whether a client device can be confirmed to be connected to a private intranet. The technique includes operating a set of local agents on one or more computing machines on the intranet. When a client device requests access to the hybrid-cloud service, the client device attempts to contact one or more of the local agents. If the client device succeeds in contacting a local agent, then the client device is confirmed to be connected to the private intranet and receives relatively trusting treatment during authentication. However, if the client device fails to contact at least one local agent, the client device is not confirmed to be connected to the private intranet and receives relatively less trusting treatment.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of copending U.S. application Ser. No. 16/190,954, filed Nov. 14, 2018, the contents and teachings of which are incorporated herein by reference in their entirety.

BACKGROUND

Companies and other organizations increasingly turn to hybrid-cloud solutions for their computer processing and storage needs. As is known, the term “hybrid cloud” refers to a computing model that involves a mixture of private cloud services, which run on-premises on a local intranet, and public cloud services, which run off-premises on the public Internet. Many applications and other computing services can benefit from hybrid-cloud deployments, such as desktop virtualization, application virtualization, and file storage, for example.
Some hybrid-cloud deployments aim to make a computing service simpler to access for users who are running their computers on a tenant's premises, where the “tenant” is the organization that owns, leases, and/or subscribes to the computing service. For example, a user working on a laptop in the tenant's office might be able to log on to a hybrid cloud service with just a username and a password, whereas the same user logging on from home might have to enter additional information, such as a security token, a biometric scan, or the like. The difference in access requirements arises from the greater security risks that typically accompany access over the public Internet.
Some tenants use source IP (Internet Protocol) addresses to distinguish between access requests originating on-premises from those arriving over the public Internet. For example, a tenant might maintain a whitelist of IP address ranges that correspond to computers located on-premises. If an access request arrives from a computer whose IP address is on the whitelist, then that computer might be prompted for relatively trusting authentication, such as just a username and password. But if an access request arrives from a computer whose IP address is not on the whitelist, then the computer might be prompted for relatively strong authentication, such as a pre-issued token, a fingerprint scan, or some other authentication factor, in addition to a username and password.

SUMMARY

Unfortunately, distinguishing between on-premises and off-premises login requests based on source IP address can be unreliable and difficult to administer. For example, malicious users can spoof source IP addresses. This may be done trivially with UDP (User Datagram Protocol) by modifying a source IP address field in a request. TCP (Transmission Control Protocol) requests are more difficult to spoof than are UDP requests, but instances of source IP address spoofing over TCP have been reported. Thus, basing authentication strength requirements on IP address ranges can be a risky endeavor. It can also place burdens on administrators. For example, an administrator needs to maintain careful records of which IP address ranges are on the whitelist and which are not. Keeping the whitelist current can be a challenge, however, as network configurations change, new sites come online, others go offline, and so forth. What is needed is a more reliable and administrable way of providing on-premises login requests with easier login requirements than those provided for off-premises login requests.
In contrast with the prior approach, an improved technique for performing authentication to a hybrid-cloud service includes selectively applying varying authentication requirements based on whether a client device can be confirmed to be connected to a private intranet. The technique includes operating a set of local agents on one or more computing machines on the intranet. When a client device requests access to the hybrid-cloud service, the client device attempts to contact one or more of the local agents. If the client device succeeds in contacting a local agent, then the client device is confirmed to be connected to the private intranet and receives relatively trusting treatment during authentication. However, if the client device fails to contact at least one local agent, the client device is not confirmed to be connected to the private intranet and receives relatively less trusting treatment. For example, a user of an unconfirmed machine may be required to supply an additional authentication factor.
Advantageously, the improved technique provides a more reliable way of determining whether a client device is inside or outside a private intranet than the use of source IP addresses. The improved technique is thus more secure and resistant to hacking than is the prior approach. It is also easier to administer, as there is no need to provide or maintain whitelists of trusted IP addresses.
Certain embodiments are directed to a method of authenticating users to a hybrid-cloud service. The method includes operating a set of local agents on respective computing machines connected to a private intranet, the private intranet connected to a public network via a gateway, the gateway configured to block incoming connection requests arriving over the public network and directed to any of the set of local agents. In response to (i) receipt from a first client device of a first resource request for accessing a cloud resource of the hybrid-cloud service and (ii) a reachable agent of the set of agents then receiving an incoming connection request from the first client device, the method further comprises (a) transmitting a silent authentication factor to the first client device, the silent authentication factor providing an indication that that first client device is connected to the private intranet, (b) receiving a first authentication request from the first client device, the first authentication request specifying a first set of authentication factors which includes the silent authentication factor, and (c) performing a first authentication operation on the first authentication request.
Other embodiments are directed to an electronic system constructed and arranged to perform a method of authenticating users to a hybrid-cloud service, such as the method described above. Still other embodiments are directed to a computer program product. The computer program product stores instructions which, when executed on control circuitry of an electronic system, cause the electronic system to perform a method of authenticating users to a hybrid-cloud service, such as the method described above.
The foregoing summary is presented for illustrative purposes to assist the reader in readily grasping example features presented herein; however, the foregoing summary is not intended to set forth required elements or to limit embodiments hereof in any way. One should appreciate that the above-described features can be combined in any manner that makes technological sense, and that all such combinations are intended to be disclosed herein, regardless of whether such combinations are identified explicitly or not.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The foregoing and other features and advantages will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings, in which like reference characters refer to the same or similar parts throughout the different views.

FIG. 1 is a block diagram of an example environment in which embodiments of the improved technique can be practiced.

FIG. 2 is a sequence diagram that shows an example method whereby local agents running on a private intranet register with a configuration service, which is part of a cloud-based server.

FIG. 3 is a sequence diagram that shows a method whereby a client device obtains an agent list of local agents that are registered with the configuration service and attempts to determine which registered local agents are currently reachable.

FIG. 4 is a sequence diagram that shows a method whereby the cloud-based server responds to a request to access a cloud resource by presenting different authentication requirements based on whether the client device can connect to one of the local agents.

FIG. 5 is a flowchart showing an example method of authenticating users to a hybrid-cloud service.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention will now be described. It should be appreciated that such embodiments are provided by way of example to illustrate certain features and principles of the invention but that the invention hereof is not limited to the particular embodiments described.
An improved technique for performing authentication to a hybrid-cloud service includes selectively applying varying authentication requirements based on whether a client device can be confirmed to be connected to a private intranet. The technique promises to be more reliable and easily administrable than previous approaches, which rely upon IP address lists to distinguish between on-site and off-site login requests.
FIG. 1 shows an example environment 100 in which embodiments of the improved technique can be practiced. Here, a private intranet 102 operatively connects to a public network 140 via a gateway 130. Each of a set of local agents 120 (e.g., one or more local agents 120 a, 120 b, etc.) runs on a respective computing machine and connects to the private intranet 102 and to a respective local resource 122 (e.g., one of 122 a, 122mb, etc.). A cloud-based server 150 connects to the public network 140 and hosts a cloud resource 166. In an example, the cloud resource 166 is a public-cloud component of a hybrid-cloud service, which includes both the cloud resource 166 and one or more of the local resources 122.
Also shown in FIG. 1 are client devices 110 (e.g., 110 a, 110 b, etc.). Any number of client devices 110 may be used. By way of non-limiting example, each client device 110 includes a receiver 112, a browser 114, and a user interface (UI) 116, such as a keyboard, pointer, mouse, touchscreen, display, etc. Suitable examples of client devices 110 include desktop computers, laptop computers, tablet computers, smart phones, personal data assistants, set top boxes, gaming consoles, Internet-of-Things devices, and the like—essentially, any device capable of running software and connecting to a network. The receiver 112 is a software component installed on a client device 110 to facilitate operation with the hybrid-cloud service. One should appreciate that the functionality described herein for the receiver 112 may alternatively be realized by other software components, or combinations of software components, such that a specific receiver component 112 is not required.
The private intranet 102 may be realized as a LAN (local area network), as multiple LANs connected together, as a WAN (wide area network), or as any combination of LANs and/or WANs, for example. In an example, the private intranet 102 is owned, leased, or operated by an organization that is a tenant of the hybrid-cloud service. The gateway 130 may be realized as a computer, as a dedicated hardware device, or as multiple such computers and/or devices. The gateway 130 is configured to isolate the private intranet 102 from the public network 140 but to permit certain allowed traffic to pass therebetween based on rules. For example, the gateway 130 may include a firewall 132 configured to block incoming connection requests from the public network 140 but to allow outgoing connection requests from the private intranet 102 to the public network 140. Thus, devices on the private intranet 102 may call out to any servers or devices on the public network 140, but devices that are not on the private intranet 102 may not call in from the public network 140, as such calls are blocked by the firewall 132. Although the firewall 132 may allow certain exceptions (cases where incoming requests are allowed), exceptions are not generally made for the local agents 120, which are thus not allowed to receive incoming connection requests from the public network 140. The public network 140 may itself be the Internet or some other public network.
In an example, the cloud-based server 150 includes one or more communication interfaces 152, a set of processors 154, and memory 160. The communication interfaces 152 include, for example, network interface adapters for converting electronic and/or optical signals received over the public network 140 to electronic form for use by the cloud-based server 150. The set of processors 154 includes one or more processing chips and/or assemblies. The memory 150 includes both volatile memory, e.g., Random Access Memory (RAM), and non-volatile memory, such as one or more ROMs (Read-Only Memories), disk drives, solid state drives, and the like. The set of processors 154 and the memory 160 together form control circuitry, which is constructed and arranged to carry out various methods and functions as described herein. Also, the memory 160 includes a variety of software constructs realized in the form of executable instructions. When the executable instructions are run by the set of processors 154, the set of processors 154 carry out the operations of the software constructs. Although certain software constructs are specifically shown and described, it is understood that the memory 160 typically includes many other software components, which are not shown, such as an operating system, various applications, processes, and daemons. Although the cloud-based server 150 is shown as a single computer server, it may be implemented using any number of physical computers, such as a single server or a server cluster.
In an example, the memory 160 “includes,” i.e., realizes by execution of software instructions, a configuration service 162, an authentication service 164, the above-mentioned cloud resource 166, and a ticketing service 168. Not all examples and embodiments require all of the components 162, 164, 166, and 168, however. When provided, the components 162, 164, 166, and 168 may run on a single computer server (as shown), on respective computer servers, on virtual machines, or in any suitable manner.
In example operation, client devices 110 access a hybrid-cloud service both from inside the private intranet 102 and from outside the private intranet 102, but authentication requirements differ in the two cases based on whether the client machines 110 can be confirmed to be connected to the private intranet 102. For example, on-premises client devices 110 may be presented with authentication requirements that are relatively easy for users to perform, such as just a username and password, whereas off-premises client devices 110 are less trusted and may be presented with authentication requirements that are relatively hard for users to perform, such as a username, a password, and a passcode. In accordance with improvements hereof, client machines 110 confirmed to be on-premises use a silent authentication factor, which strengthens authentication without requiring users to enter a separate passcode or other factor.
For example, assume that client device 110 a is connected to the private intranet 102 but that client device 110 b is not. For instance, client device 110 a is a desktop computer located on the premises of the tenant, with a wired or wireless connection to the private intranet 102, whereas client device 110 b is a laptop computer or smart phone located off-premises, at a user's home and connected to the public network 140.
If a user of client device 110 a wishes to access the hybrid-cloud service, the user may enter a command on the client device 110 a. The command directs the client device 110 a to issue an inbound connection request 170 a to a local agent 120. For example, the client device 110 a previously obtained an agent list of local agents 120 a from the cloud-based server 150, and the client device 110 a attempts to contact one or more of the local agents on the agent list. As the client device 110 a has a connection to the private intranet 102, the client device 110 a is able to contact the local agent 120 a (and possibly other local agents) without being blocked by the firewall 132. In response to receiving the inbound connection request 170 a, the local agent 120 makes an outgoing call to the cloud-based server 150, directing the cloud-based server 150 to issue a silent authentication factor, such as a one-time token (OTT) 180, which the cloud-based server 150 returns to the client device 110 a via the local agent 120. The client device 110 a then gathers authentication factors from the user, such as just a username and password, and adds to those factors the silent authentication factor (e.g., OTT 180) to make up a first set of authentication factors 190 a. The client device 110 a then sends this first set of authentication factors 190 a to the cloud-based server 150 in an authentication request 192 a. The authentication service 164 performs an authentication operation which, if successful, allows the user of the client machine 110 a to access the cloud resource 166. The user of client device 110 a thus has a relatively easy time authenticating to the hybrid-cloud service, on account of the client device 110 a having been able to contact a local agent 120.
Consider now a case in which a user of client device 110 b wishes to access the hybrid-cloud service. The user enters a command on the client device 110 b, which directs the client device 110 b to issue an inbound connection request 170 b to a local agent 120. However, the request 170 b never arrives at any local agent 120, because the firewall 132 blocks incoming connection requests directed to any local agent 120. The client device 110 b thus receives no response from any local agent 120, and no silent authentication factor (such as OTT 180) is issued. Rather, the client device 110 b, having received no silent authentication factor, instead requires an additional authentication factor 194, such as a passcode, biometric scan, or the like. The client device 110 b gathers a second set of authentication factors, e.g., a username, password, and passcode, and sends these factors to the cloud-based server 150 in an authentication request 192 b. The authentication service 164 then performs an authentication operation which, if successful, allows the user of the client machine 110 b to access the cloud resource 166. The user of client device 110 b thus has a relatively hard time authenticating to the hybrid-cloud service, on account of the client device 110 b having been unable to contact any local agent 120.
FIG. 2 shows an example sequence whereby agents 120 on the private intranet 102 register with the cloud-based server 150. Here, each agent 120 (120 a, 120 b, etc.) sends a registration request (210 a, 210 b, etc.) to the configuration service 162. Each agent 120 may provide, for example, a unique identifier of that agent, an IP address at which the agent can be reached, a DNS (directory name system) name of the agent, a URL (uniform resource locator) or any other information that enables the respective agent 120 to be reached on the private intranet 102. At 220, the configuration service 162 assembles the received information into an agent list 230, which the configuration service 162 stores for future reference.
FIG. 3 shows an example sequence whereby a client device 110 obtains an agent list 230 of local agents that are registered with the configuration service 162 and attempts to determine which registered agents 120 are currently reachable. Although FIG. 3 shows particular interactions among components of the cloud-based server 150, one should appreciate that such interactions merely provide a useful example, and that any activity shown between components of the cloud-based server 150 may be alternatively regarded as internal activities, some of which can be simplified in ways that will be apparent to those skilled in the art.
At 310, the client device 110 sends a discovery request to the cloud-resource 166. The discovery request is a request to obtain the agent list 230, and in some cases additional account information. At 312, the cloud resource 166 forwards the discovery request to the configuration service 162, which responds at 314 by providing the agent list 230, which the cloud resource 166 returns to the client device 110 at 316.
As the cloud-based server 150 is connected to the public network 140 (FIG. 1), the client device 110 can send the discovery request to the cloud-based server 150 and receive a response, even if the client device 110 is not connected to the private intranet 102. Thus, discovery can proceed regardless of client location, provided the client device 110 has a connection to the public network 140.
With the agent list 230 received, the client device 110 may next attempt to discover which if any agents 110 are currently reachable. For example, at 320 a, 320 b, etc., the client device 110 attempts to contact respective agents 120 a, 120 b, etc., by sending incoming connection requests to all such agents, e.g., all agents appearing on the agent list 230. In this example, the client machine 110 is requesting the unique identifier of the agent, but any request would suffice. As the firewall 132 (FIG. 1) blocks incoming connection requests to agents 120 from the public network 140, agents 120 will be reachable only if the client device 110 is connected to the private intranet 102. If the client device 110 is connected to the private intranet 102, then any agents 120 currently running on the private intranet 102 respond (at 330 a, 330 b, etc.). The client device 110 keeps track of received responses, and at 340 creates a reachable agent list 350, which identifies all agents that issued responses 330 a, 330 b, etc., and their respective network addresses (e.g., IP addresses, URLs, DNS names, etc.).
FIG. 4 shows an example sequence whereby the cloud-based server 150 responds to a resource request 402 to access the cloud resource 166 by presenting different authentication requirements or options based on whether the client device 110 can connect to one of the local agents 120. As also shown in FIG. 1, the cloud resource 166, authentication service 164, and ticketing service 168 are all components of the cloud-based server 150. Thus, any interaction with any of these components is an interaction with the cloud-based server 150.
At 410, the client device 110 issues a resource request 402 to access the cloud resource 166. For example, a user of client device 110 may click a link or launch a program, which requires accessing the cloud resource 166. In response to the resource request 402, the cloud resource 166 replies at 412 by issuing an authentication challenge, such as an HTTP 401 error response code. In an example, the authentication challenge specifies a network location of the authentication service 164.
At 420, the client device contacts the authentication service 164, e.g., at the specified location, and provides a request to obtain available authentication methods. At 422, the authentication service 164 responds by listing the available authentication methods. These may include, for example, the first set of authentication factors 190 a, which includes the OTT 180, and the second set of authentication factors 190 b, which includes no OTT 180 but instead requires an additional factor 194, such as a passcode.
At 430, the client device 110, upon detecting that authentication is possible using the first set of authentication factors (including the silent factor), attempts to contact an agent 120, by sending an incoming connection request to the agent 120. The arrow for act 430 is dashed because the client device 110 may not succeed in contacting any agent 120. For example, the client machine 110 will fail to contact any agent 120 if the client device 110 is not connected to the private network 102.
Although contacting a single agent 120 would suffice, the client device 110 may nevertheless attempt to contact multiple agents 120, such as all agents appearing on the reachable agent list 350 (FIG. 3). If a response from any of the reachable agents is received (e.g., because the client device 110 is connected to the private network 102), then the reachable agent, shown here as agent 120 a, responds at 432 by requesting a new OTT 180 from the ticketing service 168. The request at 432 may include device information regarding the client device 110 and credentials for accessing the ticketing service 120 a.
At 440, the ticketing service 168 validates the credentials. Assuming the credentials are confirmed, the ticketing service 168 stores the device information and generates the new OTT 180. At 442, the ticketing service 168 returns the new OTT 180 to the reachable agent 120 a, which, at 444, sends the OTT 180 back to the client device 110.
At 450, the client device 110, having received the OTT 180, discovers that using the first set of authentication factors 190 a is an option, and proceeds to collect the first set of authentication factors 190 a, e.g., by prompting the user of client device 110 for a user name and password and by adding the newly received OTT 180 as a silent authentication factor. The OTT 180 is “silent” because the user of client device 110 is not directly aware of it and does not have to perform any action to include it among the first set of authentication factors 190 a. Rather, inclusion of the OTT 180 is typically automatic and transparent to the user.
At 460, the client device 110 issues an authentication request (like request 192 a of FIG. 1), which specifies the first set of authentication factors 190 a. At 462, upon receiving the authentication request, the authentication service 164 presents the OTT 180 to the ticketing service 168 and requests the stored device information. The ticketing service 168 validates the OTT 180, retrieves the device information at 464, and at 466 returns the device information to the authentication service 164. The ticketing service 168 also deletes the OTT 180, and/or any way of validating the OTT 180, and deletes the device information, thereby ensuring that the OTT 168 can only be used once.
At 470, the authentication service 164 validates the first set of authentication factors 190 a as well as the device information. Assuming successful validation, the authentication service 164 generates an authentication token 470 a, which it returns to the client device 110 at 472. At 480, the client machine 110 accesses the cloud resource 166 using the authentication token 470 a. For example, the client machine 110 establishes an authenticated session with the cloud resource 166a, allowing the client machine 110 to access the cloud resource 166 as long as the token 470 a is valid.
Returning back to 470, if the client device 110 receives no response from any agent 120, or receives a denial response, then no OTT 180 is issued. Instead, the client device 110 determines that using the first set of authentication factors 190 a is not an option. The sequence proceeds to 450, whereupon the client device 110 collects the second set of authentication factors 190 b, such as username, password, and additional factor 194, which may require the user of client device 110 to perform an additional manual action, such as entering a passcode. At 460, the client device sends an authentication request to the authentication service 164, providing the second set of authentication factors 190 b.
Activity proceeds as before, but without using the OTT 180. At 470, the authentication service 164 validates the second set of authentication factors 190 b and, assuming they are sufficient, generates an authentication token 470 a, which is returned to the client device 110 at 472 and is used thereafter to establish an authenticated session with the cloud resource 166.
FIG. 4 thus demonstrates that authentication may proceed using either the first set of authentication factors 190 a or the second set of authentication factors 190 b, the primary difference being that it is easier for the user to log on using the first set of authentication factors 190 a, as it includes the silent authentication factor (OTT 180) and does not require an additional manual action for entering the additional authentication factor 194.
The activities shown in FIG. 4 may be adapted to prevent a malicious user of one tenant from using an OTT 180 to qualify for easy access to resources of other tenants. For instance, a malicious user might properly obtain an OTT 180 on the intranet of Tenant A and then try to redeem that OTT 180 for accessing a resource of Tenant B. If the OTT 180 were accorded full credit in an authentication request to the resource to Tenant B, them the malicious user would be able to access those resources with a simple brute-force attack (e.g., by guessing user name and password).
To prevent this type of malicious attack, a tenant administrator may provide each agent 120 (FIG. 1) with a long-term private key that is associated with a specific tenant ID. When the agent 120 makes a request for the OTT 180 (e.g., at 432 of FIG. 4), the ticketing service 168 uses the long-term key to authenticate the tenant, i.e., to prove that the tenant sending the request is the same one that has been associated with the long-term key. The ticketing service 168 stores the verified tenant ID in connection with the newly-generated OTT 180. When this OTT 180 is later redeemed during authentication (e.g., at 460 and 462), the ticketing service 168 returns the stored tenant ID associated with the OTT 180 to the authentication service 164 (e.g., at 466). The authentication service 164 can then check that the requesting user belongs to the tenant specified by the tenant ID. For instance, the authentication service 164 checks that the tenant associated with the user's username and password matches the stored tenant ID. Only if there is a match will the user be successfully authenticated, thus preventing rogue OTT attacks.
In some examples, the ticketing service 168 may associate additional data besides Tenant ID with an OTT 180, e.g., for promoting authorization to particular resources. The additional data may include a geographic location of the agent 120 to which a client device 110 has authenticated and may be used as part of an authorization decision. For instance, a client authenticating from a head office might be more trusted than a client authenticating from a subsidiary at a remote location. The additional information might also be used to make smart policy decisions. For instance, a user coming from a more trusted location may be given a more trusted set of access policies (such as access to certain sensitive data files) than one from a less trusted location. A tenant administrator may enter geographic location information as additional metadata during an initial agent installation and associate that information with the long-term private key mentioned above. When the agent 120 later requests an OTT by authenticating to the ticketing service 168 using its long-term private key (e.g., at 432), the ticketing service 168 can retrieve the geographic location from the metadata associated with that agent 120 and include that information in the OTT 180. When the authentication service 164 redeems the OTT 180, when it is provided as part of user authentication, this metadata is returned to the authentication service 164. The authentication service 164 can then accept or reject the user authentication request based on the geographic location of the user, or apply smart access policies (such as giving access to a more sensitive set of data files based on the user location). Other metadata could also be provided along with the OTT 180 to help make authorization decisions or to enforce smart policies. Geographic location is just one example. The information could also include client device integrity and mobile device management trust state, as determined via other local services within the on-premises network, which are in close proximity to the client device 110. This information may be relayed by the agent 120 to the ticketing service 168 when the OTT 180 is requested, and may be inserted as additional metadata associated with the OTT 180.
FIG. 5 shows an example method 500 that may be carried out in connection with the environment 100. The method 500 is typically performed, for example, by the software constructs described in connection with FIG. 1, which reside in the memory 160 of the cloud-based server 150 and are run by the set of processors 154. Although it is shown as a single computer server, the cloud-based server 150 may be implemented using any number of computers and/or virtual machines. The various acts of method 500 may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in orders different from that illustrated, which may include performing some acts simultaneously.
At 510, a set of local agents 120 are operated on respective computing machines connected to a private intranet 102, the private intranet 102 connected to a public network 140 via a gateway 130, the gateway 130 configured to block incoming connection requests (e.g., via firewall 132) arriving over the public network 140 and directed to any of the set of local agents 120.
At 520, multiple activities are performed in response to (i) receipt from a first client device 110 a of a first resource request (e.g., 402) for accessing a cloud resource 166 of a hybrid-cloud service and (ii) a reachable agent (e.g., 120 a) of the set of agents 120 then receiving an incoming connection request 170 a from the first client device 110 a.
For example, at 520 a, a silent authentication factor (e.g., OTT 180) is transmitted to the first client device 110 a. The silent authentication factor 180 provides an indication that that first client device 110 a is connected to the private intranet 102.
At 520 b, a first authentication request 192 a is received from the first client device 110 a. The first authentication request 192 a specifies a first set of authentication factors 190 a which includes the silent authentication factor 180.
At 520 c, a first authentication operation (e.g., 470) is performed on the first authentication request 192 a.
An improved technique has been described for performing authentication to a hybrid-cloud service. The technique includes selectively applying varying authentication requirements or options based on whether a client device 110 can be confirmed to be connected to a private intranet 102. The technique includes operating a set of local agents 120 on one or more computing machines on the intranet 102. When a client device 110 requests access to the hybrid-cloud service, the client device 110 attempts to contact one or more of the local agents 120. If the client device 110 succeeds in contacting a local agent 120, then the client device 110 is confirmed to be connected to the private intranet 102 and receives relatively trusting treatment during authentication. However, if the client device 110 fails to contact at least one local agent 120, the client device 110 is not confirmed to be connected to the private intranet 102 and receives relatively less trusting treatment. The improved technique thus provides a reliable way of determining whether a client device is inside or outside a private intranet, is more secure and resistant to hacking than the prior approach, and is easier to administer.
Having described certain embodiments, numerous alternative embodiments or variations can be made. For example, although embodiments have been described for use with a hybrid-cloud service, they may alternatively be applied for accessing any cloud-based service, or any server on a public network, where it is desired to provide different authentication requirements and options depending on whether a client device is connected to a private intranet.
Further, although features are shown and described with reference to particular embodiments hereof, such features may be included and hereby are included in any of the disclosed embodiments and their variants. Thus, it is understood that features disclosed in connection with any embodiment are included as variants of any other embodiment.
Further still, the improvement or portions thereof may be embodied as a computer program product including one or more non-transient, computer-readable storage media, such as a magnetic disk, magnetic tape, compact disk, DVD, optical disk, flash drive, solid state drive, SD (Secure Digital) chip or device, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and/or the like (shown by way of example as medium 550 in FIG. 5). Any number of computer-readable media may be used. The media may be encoded with instructions which, when executed on one or more computers or other processors, perform the process or processes described herein. Such media may be considered articles of manufacture or machines, and may be transportable from one machine to another.
As used throughout this document, the words “comprising,” “including,” “containing,” and “having” are intended to set forth certain items, steps, elements, or aspects of something in an open-ended fashion. Also, as used herein and unless a specific statement is made to the contrary, the word “set” means one or more of something. This is the case regardless of whether the phrase “set of” is followed by a singular or plural object and regardless of whether it is conjugated with a singular or plural verb. Further, although ordinal expressions, such as “first,” “second,” “third,” and so on, may be used as adjectives herein, such ordinal expressions are used for identification purposes and, unless specifically indicated, are not intended to imply any ordering or sequence. Thus, for example, a “second” event may take place before or after a “first event,” or even if no first event ever occurs. In addition, an identification herein of a particular element, feature, or act as being a “first” such element, feature, or act should not be construed as requiring that there must also be a “second” or other such element, feature or act. Rather, the “first” item may be the only one. Although certain embodiments are disclosed herein, it is understood that these are provided by way of example only and that the invention is not limited to these particular embodiments.
Those skilled in the art will therefore understand that various changes in form and detail may be made to the embodiments disclosed herein without departing from the scope of the invention.

Claims

Wat is claimed is:

1. A method of authenticating to a hybrid-cloud service, the hybrid-cloud service including a cloud resource on a public network and a set of local resources on a private intranet coupled to the public network, the method comprising:

receiving a plurality of requests to access the cloud resource of the hybrid-cloud service, the plurality of requests including a first set of requests originating from inside the private intranet and a second set of requests originating from outside the private intranet on the public network;

authenticating the first set of requests using a first set of authentication factors; and

authenticating the second set of requests using a second set of authentication factors, the second set of authentication factors including a greater number of user-entered factors than the first set of authentication factors.

2. The method of claim 1 wherein, in response to receipt of a first request of the first set of requests, the method further comprises generating a silent authentication factor that does not require manual user entry, wherein authenticating the first request of the first set of requests is based at least in part on the silent authentication factor.

3. The method of claim 2, wherein receipt of the first request is via a local agent running on a device connected to the private intranet, and wherein the method further comprises receiving a request from the local agent to obtain the silent authentication factor.

4. The method of claim 3 wherein receiving a second request of the second set of requests includes receiving a connection request by a gateway that connects the local intranet to the public network, and wherein the method further comprises, responsive to the gateway rejecting the connection request, authenticating the second request without the silent authentication factor.

5. The method of claim 2, wherein generating the silent authentication factor includes creating a one-time-token (OTT), the OTT expiring after being used in a single authentication request.

6. The method of claim 2, wherein the second set of authentication factors includes an additional authentication factor that is not one of the first set of authentication factors.

7. The method of claim 6, wherein the additional authentication factor requires a user of a client device to perform a manual operation.

8. An electronic system configured as part of a hybrid-cloud service that includes a cloud resource on a public network and a set of local resources on a private intranet coupled to the public network, the electronic system comprising control circuitry constructed and arranged to:

receive a plurality of requests to access the cloud resource of the hybrid-cloud service, the plurality of requests including a first set of requests originating from inside the private intranet and a second set of requests originating from outside the private intranet on the public network;

authenticate the first set of requests using a first set of authentication factors; and

authenticate the second set of requests using a second set of authentication factors, the second set of authentication factors including a greater number of user-entered factors than the first set of authentication factors.

9. The electronic system of claim 8 wherein, in response to receipt of a first request of the first set of requests, the control circuitry is further constructed and arranged to generate a silent authentication factor that does not require manual user entry, wherein authentication of the first request of the first set of requests is based at least in part on the silent authentication factor.

10. The electronic system of claim 9, wherein receipt of the first request is via a local agent running on a device connected to the private intranet, and wherein the control circuitry is further constructed and arranged to receive a request from the local agent to obtain the silent authentication factor.

11. The electronic system of claim 9, wherein generation of the silent authentication factor includes creation of a one-time-token (OTT), the OTT expiring after being used in a single authentication request.

12. The electronic system of claim 9, wherein the second set of authentication factors includes an additional authentication factor that is not one of the first set of authentication factors.

13. The electronic system of claim 12, wherein the additional authentication factor requires a user of a client device to perform a manual operation.

14. A computer program product including a set of non-transitory, computer-readable media having instructions which, when executed by control circuitry of an electronic system, cause the electronic system to perform a method of authenticating to a hybrid-cloud service that includes a cloud resource on a public network and a set of local resources on a private intranet coupled to the public network, the method comprising:

15. The computer program product of claim 14 wherein, in response to receipt of a first request of the first set of requests, the method further comprises generating a silent authentication factor that does not require manual user entry, wherein authenticating the first request of the first set of requests is based at least in part on the silent authentication factor.

16. The computer program product of claim 15, wherein the first request is received via a local agent running on a device connected to the private intranet, and wherein authenticating the first request includes receiving a request by the local agent to obtain the silent authentication factor.

17. The computer program product of claim 16 wherein receiving a second request of the second set of requests includes receiving a connection request by a gateway that connects the local intranet to the public network, and wherein the method further comprises, responsive to the gateway rejecting the connection request, authenticating the second request without the silent authentication factor.

18. The computer program product of claim 15, wherein generating the silent authentication factor includes creating a one-time-token (OTT), the OTT expiring after being used in a single authentication request.

19. The computer program product of claim 15, wherein the second set of authentication factors includes an additional authentication factor that is not one of the first set of authentication factors.

20. The computer program product of claim 19, wherein the additional authentication factor requires a user of a client device to perform a manual operation.