Steering traffic on a flow-by-flow basis by a single sign-on service

Techniques for using a single sign-on (SSO) service as a software defined networking (SDN) controller for a virtual private network environment. The techniques disclosed herein may include receiving, at a first authentication service, first data including a first request to authenticate a user of a client device to access an application. The techniques may also include sending, to the client device, second data representing a second request configured to prompt a second authentication service to authenticate the user of the client device. Additionally, the first authentication service may receive an indication that the user was authenticated by the second authentication service and determine, based at least in part on an attribute associated with at least one of the client device or the application, whether the client device is to access the application using an unsecured connection or, alternatively, access the application using a secured connection.

TECHNICAL FIELD

The present disclosure relates generally to using a single sign-on (SSO) service as a software defined networking (SDN) controller for steering traffic on a flow-by-flow basis in a network environment.

BACKGROUND

Today, using virtual private networks (VPNs) on enterprise devices can be clunky, cumbersome, and error prone. For instance, all VPN traffic originating at an enterprise device is generally tunneled over some form of an IP-in-IP tunnel indiscriminately. Additionally, implementing VPNs on a per-application basis only considers the source application and requires Mobile Device Management (MDM) to participate. Further, split-tunnel routing procedures are often not allowed by enterprises that consider split-tunnel routing a security risk, and thereby render local devices, such as printers, or Wi-Fi splash pages unreachable. As another example, configuration issues and uptime of head-ends often frustrate the use of VPN services, and if split-tunnel routing is enabled on VPN clients, such routing is more or less static—VPN flow dispositions are established statically, or, at best, the VPN client is sent a flow disposition periodically.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

This disclosure describes various technologies for using a single sign-on (SSO) service as a software defined networking (SDN) controller to determine whether client devices need to connect to remote service providers using a connection that is secured or unsecured. Some of the techniques described in this disclosure may include receiving, at a first SSO service and from a client device, first data including a first request to authenticate a user of the client device to access a service provider. In response, the first SSO service may generate second data representing a second request configured to prompt a second SSO service to authenticate the user of the client device, and then send the second data to the client device. The techniques may also include receiving an indication from the client device that an identity of the user was authenticated by the second SSO service. In this way, based at least in part on the identity of the user, the first SSO service may determine whether the client device is to (i) access the service provider using an unsecured connection or (ii) access the service provider using a secured connection. Traditionally, determining how enterprise, client devices were to access service providers (e.g., using a secured or unsecured connection) was performed on a per device basis, on a per-application basis (using MDM, for instance), or on a destination domain basis. However, by performing these operations at an SSO service that is remote to the enterprise network, various improvements in computer related technology are achieved such as: combined authentication and authorization for cloud-based server applications and IP-in-IP tunnels from end devices; eliminating the need to install client certificates on end devices with techniques such as Mobile Device Management (MDM); eliminating the need to provision per-application virtual private networks (VPNs) with techniques such as MDM.

The techniques described in this disclosure may be performed as a method and/or by a system having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the techniques described above.

Example Embodiments

As discussed above, using virtual private networks (VPNs) on enterprise devices can be clunky, cumbersome, and error prone. For instance, all VPN traffic originating at an enterprise device is generally tunneled over some form of an IP-in-IP tunnel indiscriminately. Additionally, per-application VPN-ing only considers the source application and requires Mobile Device Management (MDM) to participate. Further, split-tunnel routing procedures are often not allowed by enterprises that consider split-tunnel routing a security risk, and thereby render local devices, such as printers, or Wi-Fi splash pages unreachable. As another example, configuration issues and uptime of head-ends often frustrate the use of VPN services, and if split-tunnel routing is enabled on VPN clients, such routing is more or less static—VPN flow dispositions are established statically, or, at best, the VPN client is sent a flow disposition periodically.

Accordingly, described herein are improvements in technologies that, among other things, allow for an SSO service, such as an identity provider (IdP) service or an OpenID Connect service, to select flow dispositions dynamically. In various examples, the SSO service may make a determination of how a flow is delivered to a cloud-based service based on one or more of: its destination application; a posture of a device (e.g., whether the device is properly maintained), user (e.g., whether the enterprise user is a regular or partner employee), and/or network (e.g., whether flows are sent over private SD-WAN or open Internet networks); and/or a threat matrix of client and cloud applications (e.g., whether the applications have previously been hacked into), users (e.g., whether the user is a suspect user), and/or enterprises (e.g., whether there is a known attack presently ongoing). The SSO service may be capable of deciding whether flows are allowed to be routed across the Internet to a cloud-based service, or if flows need to be captured by way of an IP-in-IP tunnel and delivered to a cloud service by way of a software defined wide area network (SD-WAN), private network (e.g., VPN), and/or a security cloud. As such, these features may enable an enterprise to mix zero trust network access (ZTNA) and traditional VPN networking, as well as enable easy use of guest Wi-Fi networks, home printers, etc., while still being able to capture selected traffic.

Traditionally, in Security Assertion Markup Language (SAML) based authentication, the IdP of an SSO service may be called upon for web-transactions configured to use the IdP for authentication and authorization on a web-based service provider (e.g., web-based application). The IdP may assert the identity of an enterprise user and provide a statement to this effect, and then send the statement to the service provider by way of the enterprise user's web-browser. However, in at least one example of the various technologies disclosed herein, an enterprise IdP may be extended with a separate IdP configured as an SDN controller, and the separate IdP may field web-server requests for the enterprise, reach out to existing enterprise IdPs, combine enterprise user information with information stored by the web-based service provider, including its usage, device, and/or network posture, and create a traffic flow disposition that is specific for the web-call at issue. This traffic flow disposition may, in some examples, either enable direct access to the web-based service provider across the Internet, or tunnel data from the client device in an IP-in-IP tunnel to an SD-WAN, private network, and/or security cloud. Additionally, in some examples the lifetime of SAML statements and associated cookies may be limited, thus creating a dynamic and supervised method for flow routing.

By way of example and not limitation, a method according to the various technologies described herein may include receiving, at a first SSO service and from a client device, first data including a first request to authenticate a user of the client device to access a service provider (e.g., web-based application). The first request may comprise a first SAML request for a SAML statement identifying the user of the client device. In some examples, the service provider may have redirected the client device to send the request to the first SSO service for authentication before granting the client device access to the service provider's service. The first SSO service may comprise a first IdP service that is, among other things, configured to determine whether traffic flows between client devices and service providers are to be established using secured connections (e.g., VPN, SD-WAN, security cloud, etc.) or unsecured connections (e.g., direct to service provider via the internet).

The method may also include, in some examples, generating, at the first SSO service, second data representing a second request configured to prompt a second SSO service to authenticate the user of the client device, and sending the second data to the client device. The second request may comprise a second SAML request for a SAML statement identifying the user of the client device. In some examples, the first SSO service may send the second data directly to the second SSO service. Additionally, or alternatively, the first SSO service may send the second data to the client device and direct the client device to obtain a SAML statement from the second SSO service. The second SSO service may comprise a second IdP service that is configured to at least one of authenticate or authorize users of various client devices.

The method may further include receiving an indication from the client device that an identity of the user was authenticated by the second SSO service. In some examples, receiving the indication may include receiving a security assertion (e.g., SAML statement) from the client device that indicates the identity of the user. Additionally, or alternatively, the security assertion may be sent by reference to the first SSO service from the second SSO service and/or the client device. In such instances, the method may include obtaining the security assertion (e.g., SAML statement) from the second SSO service based at least in part on receiving the indication. In some examples, the indication and/or the security assertion may contain additional data that is used by the first SSO service to determine how to dispose of a traffic flow between the client device and the service provider. For instance, additional detail may include an identity of the service provider; a posture of the client device (e.g., whether the device is properly maintained), user (e.g., whether the enterprise user is a regular or partner employee), and/or network (e.g., whether flows are sent over private SD-WAN or open Internet networks); and/or a threat matrix of client and cloud applications (e.g., whether the applications have previously been hacked into), users (e.g., whether the user is a suspect user), and/or enterprises (e.g., whether there is a known attack presently ongoing).

In some examples, based at least in part on the identity of the user, the first SSO service may determine whether the client device is to access the service provider using an unsecured connection or, instead, access the service provider using a secured connection. As used herein, accessing the service provider using an unsecured connection may include accessing the service provider directly over the internet via a web browser running on the client device. Additionally, accessing the service provider using the secured connection may comprise accessing the service provider using a VPN connection, an SD-WAN connection, via a security cloud, or another secured/tunneled connection. In some examples, determining whether the client device is to access the service provider using the secured connection or the unsecured connection may be further based at least in part on other attributes associated with the user and/or the service provider, such as: an identity of the service provider; a posture of the client device, user, and/or network; and/or a threat matrix of client and cloud applications, users, and/or enterprises.

In at least one example, the first SSO service may determine that the client device is to access the service provider using an unsecured connection. When the client device is to use an unsecured connection, the first SSO service may generate third data including a security assertion (e.g., SAML statement) that is to be sent to the service provider to authenticate the identity of the user. The third data may also include an instruction that the client device access the service provider using the unsecured connection. The first SSO service may, in various examples, send the third data to the client device such that the client device may present the security assertion to the service provider when establishing a connection.

In contrast, in at least one other example, the first SSO service may determine that the client device is to access the service provider using a secured connection. When the client device is to use a secured connection, the first SSO service may generate fourth data that includes a first security assertion for the service provider and a second security assertion for an agent (e.g., web browser, VPN client, etc.) of the client device. The fourth data may also include an instruction that the client device access the service provider using the secured connection. The first SSO service may send the fourth data to the client device or the agent of the client device in order to facilitate establishment of the secured connection. The secured connection may comprise, for example, an encrypted traffic flow between at least one of the client or client agent and a cloud-based security service.

Although several of the examples described in this disclosure are made with respect to SAML based SSO services, including IdP, it is contemplated that the technologies of this disclosure are equally applicable to other forms of SSO services, such as OAuth 2.0-based OpenID Connect, as well as other forms of authentication and/or authorization services. Certain implementations and embodiments of the disclosure will now be described more fully below with reference to the accompanying figures, in which various aspects are shown. However, the various aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. The disclosure encompasses variations of the embodiments, as described herein. Like numbers refer to like elements throughout.

FIGS. 1A and 1Bcollectively illustrate a system-architecture diagram of an example environment100for implementing at least some of the various technologies disclosed herein. The environment100includes a single sign-on (SSO) service102that determines how client devices, such as client device104, should connect to various service providers, such as service provider106. Additionally,FIG. 1Aillustrates an example traffic flow associated with the SSO service102determining that the client device104should access the service provider106using an unsecured connection, whileFIG. 1Billustrates an example traffic flow associated with the SSO service102determining that the client device104should access the service provider106using a secured (e.g., encrypted) connection.

The SSO service102may include one or more configurations. For instance, the SSO service102may comprise a SAML or XML-based SSO service, a kerberos-based SSO service, a smart-card-based SSO service, and/or an Integrated Windows Authentication based SSO service. The SSO service102may additionally or alternatively comprise an OAuth 2.0 based SSO service that, for instance, utilizes OpenID Connect for its identity layer to provide user authentication and/or authorization.

As shown, the SSO service102may be extended to include two IdPs, such as an enterprise IdP108and a security IdP110. Although the enterprise IdP108and the security IdP110are depicted as IdP services for illustration purposes, it should be understood that these services may instead comprise authentication servers that are configured to operate using an OAuth 2.0 based protocol or another authentication standard. In some examples, the security IdP110may be configured as an SDN controller in that the security IdP110may field web-server requests for an enterprise, reach out to enterprise IdP108, combine enterprise user information with information from the service provider106, its usage, device and/or network posture, and create a disposition policy tailored to specific web-calls. Additionally, the security IdP110may be configured to authorize service providers, such as service provider106, while the enterprise IdP108may be configured to authenticate users of client device104.

The client device104may comprise any type of device configured to communicate using various communication protocols (e.g., VPN, SSL, TLS, DTLS, and/or any other protocol) over the networks116. For instance, the client device104may comprise a personal user device (e.g., desktop computers, laptop computers, phones, tablets, wearable devices, entertainment devices such as televisions, etc.), network devices (e.g., servers, routers, switches, access points, etc.), and/or any other type of computing device. The client device104may host a client agent112. The client agent112may comprise a VPN client, TLS client, web browser, or another application configured to enable communications over the networks116. In some examples, the client agent112may be capable of hosting a web-proxy service and/or capable of setting up a DTLS/TLS VPN tunnel to a cloud-based head-end that, in some examples, may be co-located with a cloud-based security service114.

The example service provider106may provide one or more services to various client devices via the networks116. The service provider106may include, in some examples, an application service, a website, or another cloud-based service. In some examples, the service provider106may provide basic resources such as processor (CPU), memory (RAM), storage (disk), and networking (bandwidth) to the client device104. Additionally, in some examples, the service provider106may provide, host, or otherwise support one or more application services for the client devices104to connect to and use. In some instances, computing resources associated with and/or allocated to the service provider106may be stored in various data centers located at different physical locations. For instance, first computing resources of the service provider106may be stored in a first data center located in a first geographic location while second computing resources of the service provider106may be stored in a second data center located in a second geographic location. The data centers may be physical facilities or buildings located across geographic areas that are designated to store networked devices. The data centers may include various networking devices, as well as redundant or backup components and infrastructure for power supply, data communications connections, environmental controls, and various security devices. In some examples, the data centers may include one or more virtual data centers which are a pool or collection of cloud infrastructure resources specifically designed for enterprise needs, and/or for cloud-based service provider needs.

The environment100may, in some examples, include one or more security services, such as security service114. The security service114may comprise a cloud-based security service for in-line security services. In some examples, the security service114may inspect HTTP sessions, provide for traffic flow telemetry, and/or detect malware depending on its configuration. In some examples, the security IdP110may be hosted jointly with the cloud-based security service114. In other examples, as that shown in exemplaryFIGS. 1A and 1B, the security IdP110may comprise a separately hosted entity from the cloud-based security service114.

The SSO service102, including enterprise IdP108and security IdP110, as well as the client device104, service provider106, client agent112, and security service114may communicate with one another via one or more networks116, such as the internet. The networks116may include one or more networks implemented by any viable communication technology, such as wired and/or wireless modalities and/or technologies. The networks116may include any combination of Personal Area Networks (PANs), Local Area Networks (LANs), Campus Area Networks (CANs), Metropolitan Area Networks (MANs), extranets, intranets, the Internet, short-range wireless communication networks (e.g., ZigBee, Bluetooth, etc.) Wide Area Networks (WANs)—both centralized and/or distributed—and/or any combination, permutation, and/or aggregation thereof.

As noted above,FIG. 1Aillustrates an example traffic flow associated with the SSO service102determining that the client device104should access the service provider106using an unsecured connection. At step “1” with respect toFIG. 1A, the client device104sends an authentication request118to the SSO service102. In some examples, the authentication request118is sent to the security IdP110. The authentication request118may comprise a SAML request for the SSO service102and/or the security IdP110to provide a security assertion (e.g., SAML statement). In some examples, the authentication request118may have been initiated by the service provider106in response to receiving a connection request from the client device104, and the service provider106may have redirected the client device104to the SSO service102for authentication.

In some examples, after receiving the authentication request118, the security IdP110may generate a new authentication request and redirect the client device104to send the new authentication request to the enterprise IdP108so that the enterprise IdP108may authenticate a user of the client device104. In this way, the enterprise IdP108may authenticate the user and/or provide a security assertion associated with the client device104and/or a user of the client device104in order for the client device104to be granted access to the service provider106. The enterprise IdP108may then provide the security assertion to the security IdP110, and the security IdP110may determine, based at least in part on one or more attributes (e.g., identity of the user, posture of device, network, and/or service provider, etc.) included in the security assertion, whether the client device104is to access the service provider106using a secured connection or an unsecured connection.

At step “2” with respect toFIG. 1A, the SSO service102determines that the client device104is to use an unsecured connection to access the service provider106, and accordingly sends data containing a security assertion and access instructions120to the client device104via the networks116. The security assertion and access instruction120may be used by the client device104to determine how to access the service provider106, as well as to authenticate the user of the client device104to the service provider106in order to be granted access. For instance, when establishing the client-service provider traffic flow122, the client device104may provide the service provider106with the security assertion.

At step “3” with respect toFIG. 1A, the client device104and the service provider106establish the client-service provider traffic flow122. As shown, this traffic flow comprises a direct, unsecured traffic flow between the client device104and the service provider106via the networks116(e.g., the internet).

With respect toFIG. 1B, further illustrated is an example traffic flow associated with the SSO service102determining that the client device104should access the service provider106using a secured (e.g., encrypted) connection. At step “1” with respect toFIG. 1B, the client device104sends an authentication request118to the SSO service102. In some examples, the authentication request118is sent to the security IdP110. The authentication request118may comprise a SAML request for the SSO service102and/or the security IdP110to provide a security assertion (e.g., SAML statement). In some examples, the authentication request118may have been initiated by the service provider106in response to receiving a connection request from the client device104, and the service provider106may have redirected the client device104to the SSO service102for authentication.

In some examples, after receiving the authentication request118, the security IdP110may generate a new authentication request and redirect the client device104to send the new authentication request to the enterprise IdP108so that the enterprise IdP108may authenticate a user of the client device104. In this way, the enterprise IdP108may authenticate the user and/or provide a security assertion associated with the client device104and/or a user of the client device104in order for the client device104to be granted access to the service provider106. The enterprise IdP108may then provide the security assertion to the security IdP110, and the security IdP110may determine, based at least in part on one or more attributes (e.g., identity of the user, posture of device, network, and/or service provider, etc.) included in the security assertion, whether the client device104is to access the service provider106using a secured connection or an unsecured connection.

At step “2” with respect toFIG. 1B, the SSO service102determines that the client device104is to use a secured connection to access the service provider106, and accordingly sends data124containing one or more security assertions and access instructions to the client device104via the networks116. The one or more security assertions included in the data124may include a first security assertion that is for the service provider106and a second security assertion that is for the client agent112.

With respect to the second security assertion (e.g., SAML statement) included in the data124, the second security assertion may include a series of parameters (e.g., access instructions) directing the client agent112to capture the client device's flow. The second security assertion may additionally contain a set of fully qualified domain names (FQDNs) for flows that need to be captured and tunneled to a cloud-based head-end and/or the security service114. Tunneling of these flows may, in some examples, be based on IP-in-DTLS/TLS tunneling; however, it is contemplated that other tunneling methods may be used. Additionally, or alternatively, the second security assertion may include a public key that is associated with the service provider106in case encrypted server name indication (ESNI) is used, and a lifetime indicating a threshold amount of time that the security assertion(s) are valid for the client device104to access the service provider106.

In some examples, for the security IdP110to reach the client agent112by way of the client device104(e.g., by way of an application executing on the client device, such as a web browser), the security IdP110may redirect the call to “localhost” carrying the data124. The client agent112may listen for incoming web-requests on various ports, for example, ports80and443, such that messages similar to data124find their way to the client agent112. In some examples, the security IdP110may decide to transmit the first security assertion and the second security assertion by reference, and it may be necessary for the client agent112to obtain both security assertions directly from the security IdP110.

At step “3” with respect toFIG. 1B, the client device104, the client agent112, the security service114, and the service provider106establish the encrypted client-service provider traffic flow126. As shown, this traffic flow comprises a secured traffic flow in which data is tunneled between at least the client agent112and the security service114while the client device104is accessing the service provider106.

To establish the client-service provider traffic flow126, in some examples, once the client agent112holds both security assertions, it may first program a DNS cache with new entries for the FQDNs indicated by the second security assertion, addressing the local client agent112. This means that when the client device104is redirected to the service provider106, the name resolves to, for example, localhost, and arrives in the client agent112. In some instances, the reason for updating the DNS cache is because when the client device104is using a web browser, the browser may show a URL corresponding with the service provider106instead of the localhost. Additionally, the server name indicator (SNI) of an outgoing TLS session for the service provider106should list the URL corresponding with the service provider106or else final HTTP flows may not be stitched together in the client agent112.

In some examples, carrying a lifetime in the second security assertion may be important to instruct the client agent112when to forward and stop forwarding flows to the service provider106across the IP-in-DTLS/TLS tunnel between the client agent112and the security service114. This lifetime may, in some examples, be directly associated with the lifetime of at least one of the first security assertion or the second security assertion, and when the lifetime of at least one of the first security assertion or the second security assertion expires, the client agent112may not receive further web-traffic from the client device104. When the lifetime expires, the DNS cache entry for the service provider106may need to be cleared to enable the client device104to resolve new flows directly to the service provider106again.

It is contemplated that if and when ESNI is supported, DNS may be used to share a public key with the client device104to enable it to cipher ESNI for the service provider106with that key. In various examples, the associated private key may be held by the client agent112and distributed from the security IdP110in the second security assertion (i.e., the security assertion associated with the client agent112).

By including the first security assertion from the security IdP110in the data124, the user may be authenticated and authorized on the service provider106. This first security assertion is carried in various messages in an initial session with the service provider106. Thus, when the client device104receives the final redirect message of the data124, the client device104sets up anew session with the service provider106and resolves the URL associated with the service provider106to localhost. Additionally, the client device104may connect a TCP session to the client-agent112.

In some examples, the client agent112may be used to tunnel web-sessions in a DTLS/TLS tunnel to the security service114. When the client device104establishes its TCP session meant for the service provider106, on receipt of a TLS Client-Hello message, the client agent112combines the ESNI with the second security assertion and/or the access instruction it received in the data124from the security IdP110, and establishes the IP-in-DTLS/TLS tunnel of the client-service provider traffic flow126with the security service114. The second security assertion carries both the authentication for the client agent112and the authorization for using the service provider106. Once the DTLS/TLS tunnel has been established, the client agent112may set up a TCP session with the service provider106, and simply forwards TLS records between the two TCP sessions. In some instances, if and when the security service114wishes to intercept and open up the web-session, it may do so when it receives the TLS records.

FIGS. 2A, 2B, and 2Ccollectively illustrate a data flow diagram of an example process200according to which an identity provider (IdP) SSO service (e.g., SSO service102) determines whether a client device104may access a service provider106using a connection that is secured or unsecured. The process200may include various devices/actors that perform one or more tasks of the process200, including the client device104, the service provider106, the enterprise IdP108, the security IdP110, the client agent112, and the security service114.

The process200begins with the client device104sending an initial connection request message202to the service provider106. In some examples, the client device104may resolve a URL name corresponding with the service provider106through the client device's DNS services, and then initiate a communication session (e.g., HTTP session, TLS session, TCP session, etc.) to the service provider106with message202. At this stage, the client device104may not maintain a security assertion (e.g., SAML statement) of its user and/or may not host a cookie for the service provider106pointing at that non-existent security assertion.

In examples, the service provider106, on receiving the connection request message202, may find that the message202lacks a security assertion or cookie and, in response, generate an authentication request message204(e.g., SAML request) and redirect the client device104with message204to the SSO service which is implemented by the security IdP110. In some examples, the SSO service may be configured by an enterprise at the service provider106. The client device104may follow the redirects and send the authentication request to the SSO service security IdP110with message206.

The security IdP110, on receipt of the authentication request for the service provider106through message206, stashes the request and formulates a new authentication request for the enterprise IdP108to learn of the identity of the user of the client device104. This new authentication request is sent through messages208and210to the enterprise IdP108. In some examples, the enterprise IdP108may have been pre-configured to accept authentication requests from the security IdP110on behalf of the service provider106. In some examples, the enterprise IdP108may be used to authenticate the user while the security IdP110may authorize the service provider106. Once the user of the client device104authenticates to the enterprise IdP110, the enterprise IdP110sends message212containing a security assertion to the client device104, which then relays the security assertion to the security IdP110through message214.

With respect toFIGS. 2B and 2C, once the security IdP110has received message214containing the security assertion from the enterprise IdP108reflecting the user's identity, the security IdP110may decide how to dispose of the flow. InFIGS. 2B and 2C, the security IdP110uses the user's identity to make this decision, but it should be understood that the security IdP110may use multiple sources to determine how to dispose of a flow. For instance, the security IdP110may use the device, network, or user posture to make this decision, as well as other attributes and/or sources described in this disclosure.

At216, the security IdP110determines that the client device104is to access the service provider106directly and, in response, the security IdP generates a new security assertion to be provided to the service provider106. The security assertion may assert the identity of the user. The security assertion may be sent to the service provider106via messages218and220. Additionally, messages218and220may include additional data instructing the client device104to consume the service provider106directly (e.g., using an unsecured connection over the internet). At222, the direct traffic flow between the client device104and the service provider106is established such that data may flow between the client device104and the service provider106.

Alternatively, at224, the security IdP110determines that the client device104is to access the service provider106using a secured connection. In response, the security IdP110may generate a first security assertion akin to the security assertion mentioned above that is used for direct communication with the service provider106but, in addition, also generate a second security assertion that includes a series of parameters directing the client agent112to capture the client device104flow. The second security assertion may contain a set of FQDNs for flows that need to be captured and tunneled to the security services114. Tunneling of these flows may be based on IP-in-DTLS/TLS tunneling, but it is contemplated that other tunneling methods equally apply. Additionally, or alternatively, the second security assertion may carry a public key for the service provider106and/or a lifetime of the security assertion for the service provider106. Both security assertions, the first and the second, may be sent with messages226and228to the client agent112.

Once the client agent112receives message228, the client agent112may program a DNS cache with new entries for the FQDNs indicated by the second security assertion. By including the first security assertion from the security IdP110in message228, the user may be authenticated and authorized on the service provider106. This first security assertion is carried in messages232A and232B in an initial session with the service provider106. Additionally, the client device104may connect a TCP session to the client-agent112.

In some examples, the client agent112and/or the security service114may establish an IP-in-DTLS/TLS tunnel234that is used to tunnel web-sessions between the client agent112and the security service114. For instance, when the client device104establishes its TCP session meant for the service provider106, on receipt of a TLS Client-Hello message, the client agent112combines the ESNI with the second security assertion and/or the access instruction it received from the security IdP110, and establishes the IP-in-DTLS/TLS tunnel234of the client-service provider traffic flow with the security service114. The second security assertion carries both the authentication for the client agent112and the authorization for using the service provider106. Once the IP-in-DTLS/TLS tunnel234has been established, the client agent112may set up a TCP session with the service provider106, and simply forward TLS records between the two TCP sessions. In some instances, if and when the security service114wishes to intercept and open up the web-session, it may do so when it receives the TLS records. In this way, data including the example TLS response message236A and236B may be communicated between the service provider106and the client device104via the IP-in-DTLS/TLS tunnel234.

FIGS. 3 and 4illustrate flow diagrams of example methods300and400that illustrate aspects of the functions performed at least partly by the SSO service102and/or the security IdP110as described inFIGS. 1A-2C. The logical operations described herein with respect toFIGS. 3 and 4may be implemented (1) as a sequence of computer-implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system.

FIG. 3illustrates a flow diagram of an example method300for using an SSO service to determine whether a client device may access a service provider using a connection that is secured or unsecured. The method300begins at302, during which first data is received at a first SSO service and from a client device, the first data including a first request to authenticate a user of the client device to access a service provider. In various examples, the first request may comprise a first SAML request for a SAML statement identifying the user of the client device. The service provider may have redirected the client device to send the request to the first SSO service for authentication before granting the client device access to the service provider's service. The first SSO service may comprise a first IdP service or a first OpenID Connect service that is, among other things, configured to determine whether traffic flows between client devices and service providers are to be established using secured connections (e.g., VPN, SD-WAN, security cloud, etc.) or unsecured connections (e.g., direct to service provider via the internet).

At304, the method300includes generating, at the first SSO service, second data representing a second request configured to prompt a second SSO service to authenticate the user of the client device, and at306, the method300includes sending the second data to the client device. The second request may comprise a second SAML request for a security assertion (e.g., SAML statement) identifying the user of the client device. In some examples, the first SSO service may send the second data directly to the second SSO service. Additionally, or alternatively, the first SSO service may send the second data to the client device and direct the client device to obtain a SAML statement from the second SSO service. The second SSO service may comprise a second IdP service or a second OpenID Connect service. The second SSO service may be configured to at least one of authenticate or authorize users of various client devices.

At308, the method300includes receiving an indication from the client device that an identity of the user was authenticated by the second SSO service. In some examples, receiving the indication may include receiving a security assertion (e.g., SAML statement) from the client device that indicates the identity of the user. Additionally, or alternatively, the security assertion may be sent by reference to the first SSO service from the second SSO service and/or the client device. In such instances, the first SSO service may obtain the security assertion (e.g., SAML statement) from the second SSO service based at least in part on receiving the indication.

In some examples, the indication and/or the security assertion may contain additional data that is used by the first SSO service to determine how to dispose of a traffic flow between the client device and the service provider. For instance, additional detail may include an identity of the service provider; a posture of the client device (e.g., whether the device is properly maintained), user (e.g., whether the enterprise user is a regular or partner employee), and/or network (e.g., whether flows are sent over private SD-WAN or open Internet networks); and/or a threat matrix of client and cloud applications (e.g., whether the applications have previously been hacked into), users (e.g., whether the user is a suspect user), and/or enterprises (e.g., whether there is a known attack presently ongoing).

At310, the method300includes determining, based at least in part on the identity of the user, whether the client device is to (i) access the service provider using an unsecured connection or (ii) access the service provider using a secured connection. As used herein, accessing the service provider using an unsecured connection may include accessing the service provider directly over the internet via a web browser running on the client device. Additionally, accessing the service provider using the secured connection may comprise accessing the service provider using a VPN connection, an SD-WAN connection, via a security cloud, a combination thereof, or another secured and/or encrypted connection. In some examples, determining whether the client device is to access the service provider using the secured connection or the unsecured connection may be further based at least in part on other attributes associated with the user and/or the service provider, such as: an identity of the service provider; a posture of the client device, user, and/or network; and/or a threat matrix of client and cloud applications, users, and/or enterprises.

If the first SSO service determines that the client device is to access the service provider using the unsecured connection, the first SSO service may generate third data including a security assertion (e.g., SAML statement) that is to be sent to the service provider to authenticate the identity of the user. The third data may also include an instruction that the client device access the service provider using the unsecured connection. The first SSO service may, in various examples, send the third data to the client device such that the client device may present the security assertion to the service provider when establishing a connection.

In contrast, if the first SSO service determines that the client device is to access the service provider using the secured connection, the first SSO service may generate fourth data that includes a first security assertion for the service provider and a second security assertion for an agent (e.g., web browser, VPN client, etc.) of the client device. The fourth data may also include an instruction that the client device access the service provider using the secured connection. The first SSO service may send the fourth data to the client device or the agent of the client device in order to facilitate establishment of the secured connection. The secured connection may comprise, for example, an encrypted traffic flow between at least one of the client or client agent and a cloud-based security service.

FIG. 4illustrates a flow diagram of another example method400for using an authentication service to determine whether a client device may access an application using a connection that is secured or unsecured. At402, the method400begins with receiving, at a first authentication service, first data including a first request to authenticate a user of a client device to access an application. The first authentication service may comprise a first SSO service, a first OpenID Connect service, and the like. Additionally, the application may comprise a cloud-based service provider, application service, etc. In various examples, the first request may comprise a first SAML request for a SAML statement identifying the user of the client device. The application may have redirected the client device to send the request to the first authentication service for authentication before granting the client device access to the application's service. The first authentication service may comprise a first SSO service, such as a first IdP service or a first OpenID Connect service that is, among other things, configured to determine whether traffic flows between client devices and cloud-based applications are to be established using secured connections (e.g., VPN, SD-WAN, security cloud, etc.) or unsecured connections (e.g., direct to the application via the internet).

At404, the method400includes sending, to at least one of the client device or a second authentication service, second data representing a second request configured to prompt the second authentication service to authenticate the user of the client device. The second request may comprise a second SAML request for a security assertion (e.g., SAML statement) identifying the user of the client device. In some examples, the first authentication service may send the second data directly to the second authentication service. Additionally, or alternatively, the first authentication service may send the second data to the client device and direct the client device to obtain a SAML statement from the second authentication service. The second authentication service may comprise a second SSO service, such as a second IdP service or a second OpenID Connect service. The second authentication service may be configured to at least one of authenticate or authorize users of various client devices.

At406, the method400includes receiving an indication that the user was authenticated by the second authentication service. In some examples, receiving the indication may include receiving a security assertion (e.g., SAML statement) from the client device that indicates the identity of the user. Additionally, or alternatively, the security assertion may be sent by reference to the first authentication service from the second authentication service and/or the client device. In such instances, the first authentication service may obtain the security assertion (e.g., SAML statement) from the second authentication service based at least in part on receiving the indication.

At408, the method400includes determining, based at least in part on an attribute associated with at least one of the client device or the application, whether the client device is to (i) access the application using an unsecured connection or (ii) access the application using a secured connection. In some examples, the attributes associated with the client device and/or the application may include: an identity of the application; a posture of the client device, user, and/or network; and/or a threat matrix of client and cloud applications, users, and/or enterprises.

If the first authentication service determines that the client device is to access the application using the unsecured connection, the first authentication service may generate third data including a security assertion (e.g., SAML statement) that is to be sent to the application to authenticate the identity of the user. The third data may also include an instruction that the client device access the application using the unsecured connection. The first authentication service may, in various examples, send the third data to the client device such that the client device may present the security assertion to the application when establishing a connection.

In contrast, if the first authentication service determines that the client device is to access the application using the secured connection, the first authentication service may generate fourth data that includes a first security assertion for the application and a second security assertion for an agent (e.g., web browser, VPN client, etc.) of the client device. The fourth data may also include an instruction that the client device access the application using the secured connection. The first authentication service may send the fourth data to the client device or the agent of the client device in order to facilitate establishment of the secured connection. The secured connection may comprise, for example, an encrypted traffic flow between at least one of the client or client agent and a cloud-based security service.

FIG. 5illustrates a computing system diagram of an example configuration for a data center500that can be utilized to implement aspects of the technologies disclosed herein. The example data center500shown inFIG. 5includes several server computers502A-502F (which might be referred to herein singularly as “a server computer502” or in the plural as “the server computers502”) for providing computing resources. In some examples, the resources and/or server computers502may include, or correspond to, the any type of computing device described herein. Although described as servers, the server computers502may comprise any type of networked device, such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, etc.

The server computers502can be standard tower, rack-mount, or blade server computers configured appropriately for providing computing resources. In some examples, the server computers502may provide computing resources504including data processing resources such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, VPNs, and others. Some of the servers502can also be configured to execute a resource manager506capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager506can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single server computer502. Server computers502in the data center500can also be configured to provide network services and other types of services.

In the example data center500shown inFIG. 5, an appropriate LAN508is also utilized to interconnect the server computers502A-502F. It should be appreciated that the configuration and network topology described herein has been greatly simplified and that many more computing systems, software components, networks, and networking devices can be utilized to interconnect the various computing systems disclosed herein and to provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components can also be utilized for balancing a load between data centers500, between each of the server computers502A-502F in each data center500, and, potentially, between computing resources in each of the server computers502. It should be appreciated that the configuration of the data center500described with reference toFIG. 5is merely illustrative and that other implementations can be utilized.

In some instances, the data center500may provide computing resources, like applications, VM instances, VPN instances, and storage, on a permanent or an as-needed basis. Among other types of functionality, the computing resources provided by a cloud computing network may be utilized to implement the various services and techniques described above. The computing resources504provided by the cloud computing network can include various types of computing resources, such as data processing resources like tenant containers and VM instances, data storage resources, networking resources, data communication resources, network services, VPN instances, and the like.

The computing resources504provided by a cloud computing network may be enabled in one embodiment by one or more data centers500(which might be referred to herein singularly as “a data center500” or in the plural as “the data centers500”). The data centers500are facilities utilized to house and operate computer systems and associated components. The data centers500typically include redundant and backup power, communications, cooling, and security systems. The data centers500can also be located in geographically disparate locations. One illustrative embodiment for a data center500that can be utilized to implement the technologies disclosed herein will be described below with regard toFIG. 6.

FIG. 6illustrates a computer architecture diagram showing an example computer hardware architecture for implementing a network device that can be utilized to implement aspects of the various technologies presented herein. The computer architecture shown inFIG. 6illustrates a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. The computer600may, in some examples, correspond to an SSO service102described herein, and may comprise networked devices such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, etc.

The chipset606provides an interface between the CPUs604and the remainder of the components and devices on the baseboard602. The chipset606can provide an interface to a RAM608, used as the main memory in the computer600. The chipset606can further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”)610or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the computer600and to transfer information between the various components and devices. The ROM610or NVRAM can also store other software components necessary for the operation of the computer600in accordance with the configurations described herein.

The computer600can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the networks116. The chipset606can include functionality for providing network connectivity through a NIC612, such as a gigabit Ethernet adapter. The NIC612is capable of connecting the computer600to other computing devices over the networks116. It should be appreciated that multiple NICs612can be present in the computer600, connecting the computer to other types of networks and remote computer systems.

The computer600can be connected to a storage device618that provides non-volatile storage for the computer. The storage device618can store an operating system620, programs622, and data, which have been described in greater detail herein. The storage device618can be connected to the computer600through a storage controller614connected to the chipset606. The storage device618can consist of one or more physical storage units. The storage controller614can interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

In addition to the mass storage device618described above, the computer600can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer600. In some examples, the operations performed by the various components in the environment100may be supported by one or more devices similar to computer600. Stated otherwise, some or all of the operations performed by the various components in the environment100may be performed by one or more computer devices600operating in a cloud-based arrangement.

As mentioned briefly above, the storage device618can store an operating system620utilized to control the operation of the computer600. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system comprises the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Wash. According to further embodiments, the operating system can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized. The storage device618can store other system or application programs and data utilized by the computer600.

In one embodiment, the storage device618or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer600, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer600by specifying how the CPUs604transition between states, as described above. According to one embodiment, the computer600has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer600, perform the various processes described above with regard toFIGS. 1A-5. The computer600can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.

As described herein, the computer600may comprise one or more of an SSO service102, client device104, or service provider106. The computer600may include one or more hardware processors604(processors) configured to execute one or more stored instructions. The processor(s)604may comprise one or more cores. Further, the computer600may include one or more network interfaces configured to provide communications between the computer600and other devices, such as the communications described herein as being performed by the SSO service102and client device104. The network interfaces may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), and so forth. For example, the network interfaces may include devices compatible with Ethernet, Wi-Fi™, and so forth.

The programs622may comprise any type of programs or processes to perform the techniques described in this disclosure for determining connectivity in multi-hop paths using BFD Echo packet(s). The programs622may enable the client device104to perform various operations.