U.S. patent application number 17/589149 was filed with the patent office on 2022-05-19 for authenticating to a hybrid cloud using intranet connectivity as silent authentication factor.
The applicant listed for this patent is Citrix Systems, Inc.. Invention is credited to Andrew David Cooper, Feng Huang.
Application Number | 20220158977 17/589149 |
Document ID | / |
Family ID | 1000006110378 |
Filed Date | 2022-05-19 |
United States Patent
Application |
20220158977 |
Kind Code |
A1 |
Huang; Feng ; et
al. |
May 19, 2022 |
AUTHENTICATING TO A HYBRID CLOUD USING INTRANET CONNECTIVITY AS
SILENT AUTHENTICATION FACTOR
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.
Inventors: |
Huang; Feng; (Girton,
GB) ; Cooper; Andrew David; (Litlington, GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Citrix Systems, Inc. |
Fort Lauderdale |
FL |
US |
|
|
Family ID: |
1000006110378 |
Appl. No.: |
17/589149 |
Filed: |
January 31, 2022 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16190954 |
Nov 14, 2018 |
11258756 |
|
|
17589149 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 63/0236 20130101;
H04L 63/0838 20130101 |
International
Class: |
H04L 9/40 20060101
H04L009/40 |
Claims
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: 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.
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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] 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.
[0003] 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.
[0004] 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
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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
[0011] 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.
[0012] FIG. 1 is a block diagram of an example environment in which
embodiments of the improved technique can be practiced.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] FIG. 5 is a flowchart showing an example method of
authenticating users to a hybrid-cloud service.
DETAILED DESCRIPTION OF THE INVENTION
[0017] 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.
[0018] 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.
[0019] 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 120a, 120b, 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 122a, 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.
[0020] Also shown in FIG. 1 are client devices 110 (e.g., 110a,
110b, 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] For example, assume that client device 110a is connected to
the private intranet 102 but that client device 110b is not. For
instance, client device 110a 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 110b is a laptop
computer or smart phone located off-premises, at a user's home and
connected to the public network 140.
[0026] If a user of client device 110a wishes to access the
hybrid-cloud service, the user may enter a command on the client
device 110a. The command directs the client device 110a to issue an
inbound connection request 170a to a local agent 120. For example,
the client device 110a previously obtained an agent list of local
agents 120a from the cloud-based server 150, and the client device
110a attempts to contact one or more of the local agents on the
agent list. As the client device 110a has a connection to the
private intranet 102, the client device 110a is able to contact the
local agent 120a (and possibly other local agents) without being
blocked by the firewall 132. In response to receiving the inbound
connection request 170a, 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 110a via the local agent 120. The client device 110a 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 190a. The client device 110a then sends this
first set of authentication factors 190a to the cloud-based server
150 in an authentication request 192a. The authentication service
164 performs an authentication operation which, if successful,
allows the user of the client machine 110a to access the cloud
resource 166. The user of client device 110a thus has a relatively
easy time authenticating to the hybrid-cloud service, on account of
the client device 110a having been able to contact a local agent
120.
[0027] Consider now a case in which a user of client device 110b
wishes to access the hybrid-cloud service. The user enters a
command on the client device 110b, which directs the client device
110b to issue an inbound connection request 170b to a local agent
120. However, the request 170b never arrives at any local agent
120, because the firewall 132 blocks incoming connection requests
directed to any local agent 120. The client device 110b thus
receives no response from any local agent 120, and no silent
authentication factor (such as OTT 180) is issued. Rather, the
client device 110b, 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
110b 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 192b. The
authentication service 164 then performs an authentication
operation which, if successful, allows the user of the client
machine 110b to access the cloud resource 166. The user of client
device 110b thus has a relatively hard time authenticating to the
hybrid-cloud service, on account of the client device 110b having
been unable to contact any local agent 120.
[0028] 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 (120a, 120b, etc.) sends a registration
request (210a, 210b, 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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 320a, 320b, etc., the client device 110
attempts to contact respective agents 120a, 120b, 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 330a,
330b, 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 330a, 330b, etc., and
their respective network addresses (e.g., IP addresses, URLs, DNS
names, etc.).
[0033] 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.
[0034] 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.
[0035] 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 190a, which includes the OTT 180, and
the second set of authentication factors 190b, which includes no
OTT 180 but instead requires an additional factor 194, such as a
passcode.
[0036] 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.
[0037] 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 120a, 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 120a.
[0038] 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 120a, which, at 444, sends the OTT 180 back to the
client device 110.
[0039] At 450, the client device 110, having received the OTT 180,
discovers that using the first set of authentication factors 190a
is an option, and proceeds to collect the first set of
authentication factors 190a, 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 190a. Rather,
inclusion of the OTT 180 is typically automatic and transparent to
the user.
[0040] At 460, the client device 110 issues an authentication
request (like request 192a of FIG. 1), which specifies the first
set of authentication factors 190a. 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.
[0041] At 470, the authentication service 164 validates the first
set of authentication factors 190a as well as the device
information. Assuming successful validation, the authentication
service 164 generates an authentication token 470a, 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
470a. 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 470a is valid.
[0042] 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 190a is not an
option. The sequence proceeds to 450, whereupon the client device
110 collects the second set of authentication factors 190b, 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 190b.
[0043] Activity proceeds as before, but without using the OTT 180.
At 470, the authentication service 164 validates the second set of
authentication factors 190b and, assuming they are sufficient,
generates an authentication token 470a, which is returned to the
client device 110 at 472 and is used thereafter to establish an
authenticated session with the cloud resource 166.
[0044] FIG. 4 thus demonstrates that authentication may proceed
using either the first set of authentication factors 190a or the
second set of authentication factors 190b, the primary difference
being that it is easier for the user to log on using the first set
of authentication factors 190a, as it includes the silent
authentication factor (OTT 180) and does not require an additional
manual action for entering the additional authentication factor
194.
[0045] 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).
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] At 520, multiple activities are performed in response to (i)
receipt from a first client device 110a 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., 120a) of the set of
agents 120 then receiving an incoming connection request 170a from
the first client device 110a.
[0051] For example, at 520a, a silent authentication factor (e.g.,
OTT 180) is transmitted to the first client device 110a. The silent
authentication factor 180 provides an indication that that first
client device 110a is connected to the private intranet 102.
[0052] At 520b, a first authentication request 192a is received
from the first client device 110a. The first authentication request
192a specifies a first set of authentication factors 190a which
includes the silent authentication factor 180.
[0053] At 520c, a first authentication operation (e.g., 470) is
performed on the first authentication request 192a.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
* * * * *