Selective policy driven interception of encrypted network traffic using domain name service and single sign-on services

Abstract

Techniques for enforcing policies with an enterprise traffic intercept service (TIS) that dictate how clients access software as a service (SaaS) provided by a service provider and selectively intercept enterprise network traffic based on each client each service with a domain name service (DNS) and single sign-on (SSO) service. The TIS can include a DNS server, an identity provider service, a TLS inspection proxy, and / or a policy server. The DNS server can handle requests to resolve service addresses and identify policies stored in the policy server to redirect clients based on their identity and the service. The identity provider service can then query the policy server during client authorization to the service to verify that the client request complies with the policy and allow or deny access to the service.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Application No. 17 / 166,921, filed February 3, 2021, which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure generally relates to selective policy-driven interception of encrypted network traffic that utilizes Domain Name Service (DNS) and Single Sign-On (SSO) services. Background Technology

[0004] Today, businesses are using Software as a Service (SaaS) offered by public service providers, which offer access via secure communication protocols that authenticate clients using SSO (Security Authentication System). These clients may work from home or otherwise reside outside the enterprise. If these clients are not on-site, they can directly access the SaaS, and the enterprise has no way of knowing the data exchanged between the client and the service provider. For auditing and security reasons, these enterprises could leverage Hypertext Transfer Protocol Security (HTTPS) proxies to intercept such data flows exchanged between clients and service providers. However, for scalability and privacy considerations, enterprises may only wish to selectively intercept such traffic, allowing certain flows to reach the SaaS directly without interception based on policies for each user and each service.

[0005] A traditional approach to implementing these policy decisions can be achieved using a Virtual Private Network (VPN), which can capture all traffic related to remote clients within a network controlled by the enterprise and allow for enforcement within that network. However, such methods require the installation of a VPN client on the client device, which can be cumbersome for enterprises to manage and can interfere with their clients. Attached Figure Description

[0006] The following is a detailed description with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals indicate the drawing in which the reference numeral first appears. The same reference numerals are used in different drawings to denote similar or identical items. The systems depicted in the drawings are not drawn to scale, and components in the drawings may be depicted as not to scale relative to each other.

[0007] Figure 1A and Figure 1BTogether, a system architecture diagram of an example environment for implementing at least some of the various techniques disclosed herein is shown. This environment includes an enterprise traffic interception service that selectively intercepts enterprise network traffic based on a per-client, per-service policy, utilizing Domain Name Service (DNS) and Single Sign-On (SSO) services.

[0008] Figure 2A A data flow diagram of an example process is shown, according to which an enterprise traffic interception service can implement a policy that allows client devices to access the service provider using a direct connection.

[0009] Figure 2B A data flow diagram of an example process is shown, according to which an enterprise traffic interception service can implement a policy that allows client devices to access service providers using proxy connections.

[0010] Figure 2C A data flow diagram of an example process is shown, according to which an enterprise traffic blocking service can implement a policy of denying client devices access to the service provider using connections that conflict with the policy.

[0011] Figure 3 A flowchart of an example method is shown, which is used to implement a policy that allows client devices to access service providers using direct connections by using an enterprise traffic interception service.

[0012] Figure 4 A flowchart of an example method is shown, which is used to implement a policy that allows client devices to access service providers using proxy connections by using an enterprise traffic interception service.

[0013] Figure 5 A flowchart of an example method is shown, which is used to implement a policy of denying client devices access to the service provider by using connections that conflict with the policy, using an enterprise traffic blocking service.

[0014] Figure 6 A computing system diagram of an example configuration of a data center is shown, which can be used to implement various aspects of the techniques disclosed herein.

[0015] Figure 7 A diagram of a computer architecture is shown, illustrating an example computer hardware architecture for implementing a network device that can be used to implement aspects of the various technologies presented herein. Detailed Implementation

[0016] Overview

[0017] Various aspects of the invention are set forth in the independent claims, and preferred features are set forth in the dependent claims. A feature of one aspect may be applied to each aspect alone or in combination with other aspects.

[0018] This disclosure describes a method for implementing policies using enterprise traffic interception services that allow clients to access Software as a Service (SaaS) provided by a service provider, and selectively intercept enterprise network traffic on a per-client-per-service basis using Domain Name Service (DNS) and Single Sign-On (SSO) services. The method includes: receiving first data from a user device at a DNS server associated with the enterprise network, the first data indicating the identity of a user associated with the user device. The method may further include: receiving a first request from the DNS server at the user device for resolving an address of a service associated with the service provider. The method may further include: identifying, by the DNS server at least in part based on the user's identity, a policy associated with the user accessing the service. This policy may instruct the user device to be configured for a direct access path to the service. The method may further include: providing the user device with an indication of the address of the service associated with the service provider from the DNS server. The method may further include: receiving a second request from the service provider at the user device for a direct access path from the user device to the service provider. The method may further include: receiving request data from the identity provider within the enterprise network and from the user equipment, the request data indicating a third request to authenticate the user's identity to access a direct access path. The method may further include: receiving a policy from the identity provider, at least in part based on the authenticated user's identity. The method may further include: the identity provider determining that the policy indicates a direct access path and that the request data indicates a direct access path. The method may further include: providing the user equipment with access to a direct access path from the user equipment to the service provider, at least in part based on the determination that the policy indicates a direct access path and that the request data indicates a direct access path.

[0019] Additionally or alternatively, the method includes: receiving first data from a user equipment at a DNS server associated with the enterprise network, the first data indicating the identity of a user associated with the user equipment. The method may further include: receiving a first request from the DNS server and the user equipment for resolving an address of a service associated with a service provider. The method may further include: identifying a policy associated with a user accessing the service by the DNS server, at least in part based on the user's identity. The policy indicates that the user equipment is configured for a proxy access path to the service. The method may further include: providing the user equipment with an indication from the DNS server of the address of an inspection agent associated with the enterprise network. The method may further include: receiving a second request from the inspection agent and the user equipment for a proxy access path from the user equipment to the service provider via the inspection agent. The method may further include: receiving request data from the user equipment at an identity provider within the enterprise network, the request data indicating a third request to authenticate the user's identity to access the proxy access path. The method may further include: receiving a policy at the identity provider, at least in part based on the authenticated user's identity. The method may further include: determining by the identity provider that the policy indicates a proxy access path and that the request data indicates a proxy access path. The method may further include: providing the user device with access to a proxy access path from the user device to the service provider via an inspection proxy, based at least in part on determining that the policy indicates a proxy access path and the request data indicates a proxy access path.

[0020] Additionally or alternatively, the method includes: receiving first data from a DNS server associated with the enterprise network and from a user equipment, the first data indicating the identity of a user associated with the user equipment. The method may further include: receiving a first request from the DNS server and from the user equipment for resolving an address of a service associated with a service provider. The method may further include: identifying a policy associated with a user accessing the service by the DNS server, at least in part based on the user's identity. The policy indicates that the user equipment is configured for a proxy access path to the service. The method may further include: providing the user equipment with an indication from the DNS server of the address of an inspection proxy associated with the enterprise network. The method may further include: receiving a second request from the service provider and from the user equipment for a direct access path from the user equipment to the service provider. The method may further include: receiving request data from the identity provider at the enterprise network and from the user equipment, the request data indicating a third request to authenticate the user's identity to access the direct access path. The method may further include: receiving a policy from the identity provider, at least in part based on the authenticated user's identity. The method may further include: determining by the identity provider that the policy indicates a proxy access path and the request data indicates a direct access path. The method may further include: at least in part, denying the user device access to a direct access path from the user device to the service provider based on determining that the policy indicates a proxy access path and the request data indicates a direct access path.

[0021] Additionally or alternatively, the method includes: receiving first data from a user equipment at a DNS server associated with the enterprise network, the first data indicating the identity of a user associated with the user equipment. The method may further include: receiving a first request from the DNS server and the user equipment for resolving an address of a service associated with a service provider. The method may further include: identifying a policy associated with a user accessing the service by the DNS server, at least in part based on the user's identity. The policy indicates that the user equipment is configured for a direct access path to the service. The method may further include: providing the user equipment with an indication of the address of the service associated with the service provider from the DNS server. The method may further include: receiving a second request from the user equipment at an inspection agent associated with the enterprise for a proxy access path from the user equipment to the service provider via the inspection agent. The method may further include: receiving request data from the user equipment at an identity provider within the enterprise network, the request data indicating a third request to authenticate the user's identity to access the proxy access path. The method may further include: receiving a policy at the identity provider, at least in part based on the authenticated user's identity. The method may further include: determining by the identity provider that the policy indicates a proxy access path and the request data indicates a direct access path. The method may further include: at least in part, denying the user device access to a direct access path from the user device to the service provider based on determining that the policy indicates a proxy access path and the request data indicates a direct access path.

[0022] The techniques described in this disclosure can be performed as a method and / or executed by a system having a non-transitory computer-readable medium storing computer-executable instructions, wherein the non-transitory computer-readable medium performs the above techniques when the computer-executable instructions are executed by one or more processors.

[0023] In addition, systems and apparatuses for implementing the methods described herein are also described, including network nodes, computer programs, computer program products, computer-readable media, and logic encoded on tangible media for implementing these methods.

[0024] The methods proposed above and in the independent claims represent alternative solutions to the problems described herein. These solutions are proposed separately to maximize the clarity of each solution.

[0025] Example Implementation

[0026] As mentioned above, policy decisions can be implemented using a Virtual Private Network (VPN), which can capture all traffic related to remote clients within a network controlled by the enterprise and allow for implementation within that network. However, such methods require the installation of VPN clients on client devices, which can be cumbersome for enterprises to manage and can interfere with their clients. Therefore, alternative methods have emerged for enterprises to implement policy decisions. These methods can be based on DNS servers or SSO servers controlled by the enterprise.

[0027] For example, a client can authenticate itself to a DNS server, enabling the DNS server to respond with an Internet Protocol (IP) address corresponding to the actual service provider's IP address or a proxy IP address, based on the user's policy, when it receives a resolution query from a client device attempting to access services from a certain service provider. However, the DNS server cannot guarantee that the client device will not ignore the DNS server's decisions. For example, the client device might cache older DNS server responses more often than it should, might ignore DNS responses, or might simply bypass the DNS server (e.g., using DNS over Transport Layer Security (TLS) or DNS over HTTPS). In such scenarios, even if the policy dictates that the client uses a proxy, the client device can still contact the actual service provider's IP address. Furthermore, some protocols negotiate IP addresses via dedicated channels and therefore never use a DNS server as a means of obtaining IP address information.

[0028] Additionally, clients can authenticate themselves using an SSO service, which can be configured to redirect the client to the actual service provider's service name (e.g., app.service.com) or a proxy name (e.g., app.service.proxy.com) after authentication, based on user policies. However, there is no guarantee that the client device will be correctly redirected during subsequent interactions with the service provider. For example, once the SSO service redirects the client device to the proxy name to access the service provider, there is no guarantee that the service will not redirect the client back to the actual name (app.service.com) either explicitly or by embedding a reference to the actual name in the content provided by the service. While this could be addressed by rewriting content at the proxy to ensure that such a redirection does not occur, such content rewriting can be error-prone and, in some cases, impossible with certain standards (e.g., WebAssembly). Furthermore, malicious clients might attempt to intentionally bypass the proxy after authentication.

[0029] This disclosure describes a technique for an Enterprise Traffic Interception Service (TIS) that combines an SSO server and an enterprise-controlled DNS server to allow selective Transport Layer Security (TLS) policy-driven interception of encrypted network traffic associated with remote enterprise clients. The enterprise TIS may include a DNS server, an Identity Provider (IdP) service, a TLS inspection broker, and / or a policy server. In some examples, a DNS client broker may be installed on enterprise client devices that can be configured to establish an authenticated channel with a DNS server controlled by the enterprise TIS. Additionally or alternatively, Security Assertion Markup Language (SAML) SSO provided by the IdP service may be used to control access to a SaaS service provider via enterprise client devices. Additionally or alternatively, the inspection broker may act as a man-in-the-middle (MitM) between the client broker (e.g., a browser running on the client device) and the service provider. This can be achieved by (1) installing a server certificate in the inspection broker or (2) installing a root certificate authority issued by the enterprise on the enterprise client device. Additionally or alternatively, a policy server may store one or more policies that specify how clients access various service providers on a per-client, per-service basis.

[0030] Enterprise TIS can offer various advantages to enterprises and their customers. For example, by employing the Enterprise TIS described herein, any and all policy violations caused by malicious clients or the use of opaque DNS services (e.g., DoH and DoT) can be detected and prevented. Additionally, there is no need to install a VPN client on enterprise client devices; instead, only an authenticated DNS client agent may be required, unless the enterprise uses a personalized DNS server. Furthermore, content rewriting is not required at the inspection agent, as both the inspection agent and the service provider can respond to the same name (e.g., app.enterprise.com) based on the policy-driven direction of the DNS server. Moreover, there is no need to change the methods used by the client agent and / or service provider to handle SAML-based SSO authorization, as will be described in more detail, thus allowing for a rapid login process for enterprise users and contractors.

[0031] Enterprises may wish to selectively intercept TLS traffic between enterprise clients and publicly accessible SSO services provided by various service providers. In some examples, enterprises may select which traffic to intercept based on a per-client, per-service, and / or a combination of both. Enterprises can define per-client and per-service policies to drive this desired traffic interception. These policies can be stored in a data store at an enterprise policy server associated with the enterprise's TIS, allowing the policies driving traffic interception to be accessed and / or queried by various servers and / or components of the enterprise's TIS on a per-client and / or per-service basis.

[0032] For example, a client belonging to an enterprise might want to access a publicly available service consumed by the enterprise and provided by a service provider. The client can access this service via a service name (e.g., "app.enterprise.com"). As mentioned earlier, the enterprise might want to selectively block traffic between its clients and the service providers offering various services. Therefore, the enterprise can utilize the services of the Enterprise TIS described herein to implement selective traffic blocking based on various enterprise-defined per-client and per-service policies.

[0033] Enterprises can define various policies that drive selective traffic blocking in their Enterprise TIS. As previously mentioned, policies can be defined on a per-client and / or per-service basis. For example, an enterprise might want to block all traffic between a specific client and a service provider. Additionally or alternatively, an enterprise might want to block all traffic between any client belonging to the enterprise and a specific service provider. Additionally or alternatively, an enterprise might want to block traffic between a combination of specific clients and specific service providers and / or traffic between specific services provided by a service provider. The Enterprise TIS can store these policies in the data storage of a policy server associated with the Enterprise TIS.

[0034] For example, the environment includes an enterprise TIS, enterprise clients operating enterprise client devices, and / or service providers. As previously described, the enterprise TIS may include a DNS server, an IdP service, an inspection agent, and / or a policy server. The DNS server may receive requests to resolve service provider names (e.g., app.enterprise.com) from a client agent (e.g., a browser) running on the enterprise client device. The enterprise DNS server can determine the identity of the client. For example, the client device may have an authenticated DNS client agent installed thereon. The authenticated DNS client agent may be configured to establish an authenticated channel with the DNS server controlled by the enterprise TIS, providing the enterprise DNS server with the client's authenticated identity. Additionally or alternatively, the enterprise DNS server may be configured such that all requests to resolve service provider names must include a client ID that can be used to identify the client.

[0035] Once the enterprise DNS server identifies the client, it can query the policy server based on the client name and service name. The DNS server can determine, based on the associated policy, that the client needs direct access to the service; therefore, the DNS server replies to the client proxy with the actual service provider's IP address (e.g., 5.6.7.8). Alternatively, the DNS server can determine, based on the associated policy, that the client needs to access the service through an inspection proxy; therefore, the DNS server replies to the client proxy with the inspection proxy's IP address (e.g., 1.2.3.4).

[0036] In an example where the DNS server responds to the client agent using the service provider's IP address (e.g., 5.6.7.8), for instance, if a policy dictates that the client accesses the service provider directly, the client agent can then use the IP address to directly contact the service provider and request a specific URL or path (e.g., app.enterprise.com / path). The service provider can then redirect the user agent (along with a service provider SAML request generated by the service provider) to the Enterprise IDP service. The Enterprise IDP service can then be used to authenticate the client. In some examples, the Enterprise IDP service can use any authentication technology (e.g., single-factor authentication, multi-factor authentication, biometric authentication, etc.) to challenge the client.

[0037] In an example where the DNS server responds to the client agent with the IP address of the inspection agent (e.g., 1.2.3.4), for instance, when a policy dictates that a client accesses a service provider via the inspection agent, the client agent can then use the IP address to contact the inspection agent and request a specific URL or path associated with the service provider (e.g., app.enterprise.com / path). The inspection agent can then redirect the user agent and the agent SAML request generated by the inspection agent to the enterprise IdP service. In some examples, the agent SAML request may be specific to the inspection agent and / or different from the service provider SAML request that the service provider can generate. For example, the agent SAML request may include the inspection agent's signature (e.g., a request digest encrypted with the agent's private key). The enterprise IdP service can then be used to authenticate the client. In some examples, the enterprise IdP service can use any authentication technology (e.g., single-factor authentication, multi-factor authentication, biometric authentication, etc.) to challenge the client.

[0038] Once the Enterprise IdP service has authenticated and / or identified the client, it can query the policy server based on the client name and service name. The Enterprise IdP service can then determine, based on the associated policy, that the client needs direct access to the service. Alternatively, the Enterprise IdP service can determine, based on the associated policy, that the client needs to access the service through an inspection proxy. The Enterprise IdP service can then perform policy validation to verify that the client conforms to the policy, for example, verifying that a SAML request received from a client proxy conforms to the policy.

[0039] In an example where the policy specifies direct client access to the service provider, the Enterprise IdP can perform policy validation to verify client compliance with the policy. In some examples, the Enterprise IdP service can verify that a previously received SAML request was issued by the service provider, indicating that the user agent is attempting to connect directly to the service provider. The Enterprise IdP service can determine that this conforms to the policy action received from the policy server, and can authorize the flow and generate a SAML assertion to send to the client device. In some examples, the SAML assertion can be configured as a service provider SAML assertion to confirm authorization to the service provider. Additionally or alternatively, the Enterprise IdP service can determine that a previously received SAML request was issued by an inspection broker, indicating that the user agent is attempting to connect to the service provider via the inspection broker. The Enterprise IdP service can determine that this does not conform to the policy action received from the policy server, and can reject the flow and / or notify the client that access is denied due to policy violation.

[0040] In an example where the policy specifies that a client accesses a service provider via an inspection proxy, the Enterprise IdP can perform policy validation to verify that the client conforms to the policy. In some examples, the Enterprise IdP can verify that a previously received SAML request was issued by the inspection proxy, indicating that the user agent is attempting to connect to the service provider via the inspection proxy. The Enterprise IdP service can determine that this conforms to the policy action received from the policy server, and the Enterprise IdP service can authorize the flow and generate two SAML assertions: for example, a proxy SAML assertion in response to the proxy SAML request, and a service provider SAML assertion confirming authorization to the service provider. In some examples, the proxy SAML assertion is sent to the client device, and the service provider SAML assertion is stored in a data storage associated with the Enterprise IdP service. Additionally or alternatively, the Enterprise IdP service can determine that a previously received SAML request was issued by the service provider, indicating that the user agent is attempting to connect directly to the service provider. The Enterprise IdP service can determine that this does not conform to the policy action received from the policy server, and the Enterprise IdP can reject the flow and / or notify the client that access is denied due to a policy violation.

[0041] In this example where an Enterprise IdP service sends a Service Provider SAML assertion to a client agent, the Enterprise IdP can redirect the client agent (along with the Service Provider SAML assertion) to a service name (e.g., app.enterprise.com with IP address 5.6.7.8). The Service Provider can use the Service Provider SAML assertion to authorize the client and can serve the requested content to the client device. Additionally or alternatively, the Service Provider can install a cookie to maintain authorization for a subsequent period. The Service Provider can then send the cookie to the client device, where the cookie can be used to authorize the client device with the Service Provider for a subsequent period.

[0042] In this example where the Enterprise IdP service sends a proxy SAML assertion to a client agent, the Enterprise IdP service can redirect the client agent (along with the proxy SAML assertion) to a service name (e.g., app.enterprise.com with IP address 1.2.3.4). The inspection agent can then query the Enterprise IdP service, providing the proxy SAML assertion to the Enterprise IdP service to receive a Service Provider SAML assertion stored in a data store associated with the Enterprise IdP service. The inspection agent can then send a request to the Service Provider, providing the Service Provider SAML assertion retrieved from the Enterprise IdP service. The Service Provider can then use the Service Provider SAML assertion to authorize the client and provide the requested content to the inspection agent, which can then forward the content to the client agent. Additionally or alternatively, the Service Provider can install a first cookie to maintain authorization for a subsequent period. The Service Provider can then send the first cookie to the inspection agent, which can be used to authorize the client via the inspection agent for a subsequent period. Additionally or alternatively, the inspection agent can store the first cookie in a local data store associated with the inspection agent. The proxy can then install a second cookie to maintain authorization for the proxy for a subsequent period. The proxy can then send the second cookie to the client device, which can be used to authorize the client device with the proxy for a subsequent period. This prevents the client device from directly accessing service providers that do not comply with the policy using the first cookie.

[0043] Additionally or alternatively, the process described herein can be performed on enterprise client devices without an authenticated DNS agent. As previously mentioned, an authenticated DNS client can be configured to establish an authenticated channel with a DNS server controlled by the enterprise TIS, thereby providing the enterprise DNS server with the client's authenticated identity. However, the DNS server can determine the client's identity in other ways. In some examples, personalized DNS servers can be implemented. For example, different DNS servers can be used for each client or group of clients under the same policy. Each DNS server can respond to queries based on the policy of its associated client (or group of clients). Therefore, the system and / or process does not need to have an authenticated DNS client; instead, the system and / or process may only require the client to configure its own device to use a specific (personalized) DNS server, such as an IPv6 DNS server and an IPv6 subnet configured to carry the user's identity in the last 64 bits.

[0044] While the described techniques utilize enterprise traffic interception services (including compute servers, data centers, and / or cloud computing networks), these techniques are generally applicable to any network of devices managed by an entity that can provide virtual resources. In some instances, various components can be used in a system to implement the techniques described herein. The devices and components that implement the techniques described herein are an implementation issue, and the techniques described are not limited to any particular architecture or implementation.

[0045] The techniques described in this paper offer various improvements and efficiencies in selective Transport Layer Security (TLS) policy-driven interception of encrypted network traffic associated with remote enterprise clients. For example, the techniques described herein can allow the detection and prevention of any and all enterprise-defined policy violations caused by malicious clients or the use of opaque DNS services (e.g., DoH and DoT). Furthermore, there is no need to install a VPN client on the enterprise client device; instead, only an authenticated DNS client proxy is required, unless the enterprise employs a personalized DNS server. Additionally, content rewriting is not required at the inspection proxy, as both the inspection proxy and the service provider can respond to the same name (e.g., app.enterprise.com) based on the policy-driven direction of the DNS server.

[0046] Certain embodiments and implementations of this disclosure will now be described more fully below with reference to the accompanying drawings, in which aspects are illustrated. However, these aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. As stated herein, this disclosure covers variations of the embodiments. Similar reference numerals always refer to similar elements.

[0047] Figure 1A and Figure 1B A system architecture diagram of an example environment 100 for implementing at least some of the various techniques disclosed herein is shown together. Environment 100 includes an enterprise traffic interception service (TIS) 102 that selectively intercepts enterprise network traffic, such as communication between various service providers (e.g., service provider 104) and one or more enterprise client devices (e.g., client device 106), via one or more networks 108, utilizing Domain Name Service (DNS) and a per-client, per-service policy-based Single Sign-On (SSO) service. Figure 1A An exemplary policy-based direct traffic flow associated with an enterprise TIS 102 between service provider 104 and client device 106 is shown, while Figure 1B An exemplary policy-based proxy traffic flow associated with an enterprise TIS102 between service provider 104 and client device 106 is shown.

[0048] Enterprise TIS 102 may include one or more components and / or configurations. For example, Enterprise TIS 102 may include DNS server 110, IdP service 112, TLS inspection agent 114, and / or policy server 116. DNS server 110 may be configured to establish an authenticated channel with DNS client agent 118 hosted on client device 106. SAML-based SSO provided by Enterprise IdP service 112 may be used to control access to services provided by service provider 104 via client device(s)106. Inspection agent 114 may act as a man-in-the-middle (MitM) between client agent 118 (e.g., a browser running on the client device) and service provider 104. This may be achieved by (1) installing a server certificate in inspection agent 114, or (2) installing a root certificate authority issued by the enterprise in enterprise client device 106. Additionally or alternatively, policy server 116 may store one or more policies that authorize clients to access various service providers 104 on a per-client per-service basis.

[0049] Client device 106 may include any type of device configured to communicate over network 108 using various communication protocols (e.g., VPN, SSL, TLS, DTLS, and / or any other protocols). For example, client device 104 may include personal client devices (e.g., desktop computers, laptops, telephones, tablets, wearable devices, entertainment devices (e.g., televisions), etc.), network devices (e.g., servers, routers, switches, access points, etc.), and / or any other type of computing device. Client device 106 may host client agent 118. Client agent 118 may include a VPN client, TLS client, web browser, or another application configured to communicate over network 108. In some examples, client agent 118 may be configured to establish an authenticated channel with DNS server 110 controlled by enterprise TIS 102.

[0050] Example service provider 104 may provide one or more services to various client devices via network 108. In some examples, service provider 104 may include application services, websites, or other cloud-based services. In some examples, service provider 104 may provide client device 106 with basic resources such as processors (CPUs), memory (RAM), storage devices (disks), and networking (bandwidth). Additionally, in some examples, service provider 104 may provide, host, or otherwise support one or more application services for client device 106 to connect to and use. In some instances, computing resources associated with and / or allocated to service provider 104 may be stored in various data centers located in different physical locations. For example, service provider 104's first computing resources may be stored in a first data center located in a first geographic location, while service provider 104's second computing resources may be stored in a second data center located in a second geographic location. A data center may be a physical facility or building located in a geographic area designated for storing networked devices. A data center may include various networked devices, as well as redundant or backup components and infrastructure for power supply, data communication connections, environmental control, and various security devices. In some examples, a data center may include one or more virtual data centers, which are pools or collections of cloud infrastructure resources specifically designed for enterprise needs and / or the needs of cloud-based service providers.

[0051] Enterprise TIS 102 (including enterprise DNS server 110, enterprise IdP service 112, enterprise inspection agent 114, and enterprise policy server 116), as well as client devices 106, client agents 118, and / or service providers 104, can communicate via one or more networks 108 (e.g., the Internet). Network 108 may include one or more networks implemented by any feasible communication technology (e.g., wired and / or wireless methods and / or technologies). Network 108 may include any combination of centralized and / or distributed 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.), virtual private networks (VPNs), wide area networks (WANs), and / or any combination, arrangement, and / or aggregation thereof.

[0052] An enterprise may wish to selectively block TLS communication between enterprise client 106 and publicly accessible SSO services provided by various service providers 104. In some examples, the enterprise may select which traffic to block based on a per-client, per-service, and / or combination of both. The enterprise may define policies for each client and each service to drive this desired traffic blocking. These policies may be stored in a data store at an enterprise policy server 116 associated with enterprise TIS 102, such that the policies driving the traffic blocking can be accessed and / or queried by various servers and / or components of enterprise TIS 102 on a per-client and / or per-service basis.

[0053] For example, client 106 belonging to an enterprise may wish to access a publicly available service consumed by the enterprise and provided by service provider 104. Client 106 can access this service via a service name (e.g., "app.enterprise.com"). As previously mentioned, the enterprise may wish to selectively block traffic between enterprise client 106 and service provider 104, which provides various services. Therefore, the enterprise can employ the services of enterprise TIS 102 described herein to implement selective traffic blocking based on various enterprise-defined per-client and per-service policies.

[0054] Enterprises can define various policies that drive selective traffic blocking by enterprise TIS102. As previously described, policies can be defined on a per-client and / or per-service basis. For example, an enterprise may want to block all traffic between a specific client device 106 and service provider 104. Additionally or alternatively, an enterprise may want to block all traffic between any client device 106 belonging to the enterprise and a specific service provider 104. Additionally or alternatively, an enterprise may want to block traffic between a combination of a specific client 106 and a specific service provider 104 and / or traffic between specific services provided by service provider 104. Enterprise TIS102 can store these policies in the data storage of the policy server 116 associated with enterprise TIS102.

[0055] As mentioned above, Figure 1A An example traffic flow associated with enterprise TIS102 is shown, which implements a policy that allows client device 106 to access service provider 104 using a direct connection.

[0056] At "1", DNS server 110 can receive requests to resolve service provider 104 names (e.g., app.enterprise.com) from a client agent 118 (e.g., a browser) running on enterprise client device 106. Enterprise DNS server 110 can determine the client's identity. For example, client device 106 may have an authenticated DNS client agent 118 installed thereon. The authenticated DNS client agent 118 can be configured to establish an authenticated channel with the enterprise TIS-controlled DNS server 110, providing the enterprise DNS server 110 with the client's authenticated identity. Additionally or alternatively, enterprise DNS server 110 can be configured such that all requests for resolving service provider 104 names must include a client ID that can be used to identify the client.

[0057] At point “2”, once the enterprise DNS server 110 recognizes the client, it can query the policy server 116 based on the client name and service name. The DNS server 110 can then determine, based on the associated policy, that the client needs direct access to the service. Therefore, the DNS server 110 replies to the client agent 118 with the IP address of the actual service provider 104 (e.g., 5.6.7.8).

[0058] At “3A”, the client agent 118 can then use the IP address to directly contact the service provider 104 and request a specific URL or path (e.g., app.enterprise.com / path).

[0059] At “3B”, service provider 104 can receive a request for a specific URL and then redirect the client proxy (along with the service provider SAML request generated by service provider 104) to enterprise IdP service 112 for authentication.

[0060] At point “4A”, the Enterprise IdP service 112 can then be used to authenticate the client. In some examples, the Enterprise IdP service 112 can use any authentication technology (e.g., single-factor authentication, multi-factor authentication, biometric authentication, etc.) to challenge the client. Once the Enterprise IdP service 112 has authenticated and / or identified the client, it can query the policy server 116 based on the client name and service name. The Enterprise IdP service 112 can then determine, based on the associated policy, that the client device 106 needs direct access to the service.

[0061] Enterprise IdP service 112 can then perform policy validation to verify that the client conforms to the policy, for example, verifying that a SAML request received from client agent 118 conforms to the policy. Enterprise IdP service 112 can verify that a previously received SAML request was issued by service provider 104, which may indicate that user agent 118 is attempting to connect directly to service provider 104. Enterprise IdP service 112 can determine that this conforms to the policy action received from policy server 116, and enterprise IdP service 112 can authorize the flow and generate a SAML assertion to send to client device 106. In some examples, the SAML assertion can be configured as a SAML assertion for service provider 104 to assert authorization to service provider 104.

[0062] Additionally or alternatively, Enterprise IdP service 112 may determine that a previously received SAML request was issued by inspection agent 114, which may indicate that user agent 118 is attempting to connect to service provider 104 through inspection agent 114. Enterprise IdP service 112 may determine that the action does not comply with the policy received from policy server 116, and Enterprise IdP 112 may reject the flow and / or notify the client that access is denied due to policy violation.

[0063] At “4B”, Enterprise IdP service 112 can redirect client agent 118 and service provider SAML assertions to the service name (e.g., app.enterprise.com with IP address 5.6.7.8).

[0064] At point “5”, service provider 104 may use its SAML assertion to authorize the client and may provide the requested content to client device 106. Alternatively or additionally, service provider 104 may install a cookie to maintain authorization for a subsequent period. Service provider 104 may then send the cookie to client device 106, which can be used to authorize client device 106 to service provider 104 for the subsequent period.

[0065] Additionally or alternatively, the example traffic flow described herein can be executed without an authenticated DNS client agent 118 on the enterprise client device 106. As previously mentioned, the authenticated DNS client agent 118 can be configured to establish an authenticated channel with the DNS server 110 controlled by the enterprise TIS 102, providing the enterprise DNS server 110 with the client's authenticated identity. However, the DNS server 110 can determine the client's identity in other ways. In some examples, personalized DNS servers can be implemented. For example, different DNS servers can be used for each client or group of clients under the same policy. Each DNS server can respond to queries based on the policy of its associated client (or group of clients). Therefore, the system and / or process does not need to have an authenticated DNS client agent 118; instead, the system and / or process may only require the client to configure their own device to use a specific (personalized) DNS server.

[0066] refer to Figure 1B The example traffic flow associated with enterprise TIS102 is further illustrated, which implements a policy that allows client device 106 to use a proxy connection to access service provider 104.

[0067] At "1", DNS server 110 can receive requests for the name of the service provider 104 (e.g., app.enterprise.com) from a client agent 118 (e.g., a browser) running on enterprise client device 106. Enterprise DNS server 110 can determine the client's identity. For example, client device 106 may have an authenticated DNS client agent 118 installed thereon. The authenticated DNS client agent 118 can be configured to establish an authenticated channel with the enterprise TIS-controlled DNS server 110, providing the enterprise DNS server 110 with the client's authenticated identity. Additionally or alternatively, enterprise DNS server 110 can be configured such that all requests for the name of the service provider 104 must include a client ID that can be used to identify the client.

[0068] At point “2”, once the enterprise DNS server 110 has identified the client, the DNS server 110 can query the policy server 116 based on the client name and service name. The DNS server 110 can determine based on the associated policy that the client needs to access the service through the inspection agent 114. Therefore, the DNS server 110 replies to the client agent 118 with the IP address of the inspection agent (e.g., 1.2.3.4).

[0069] At “3A”, the client agent 118 can then use the IP address to contact the inspection agent 114 and request a specific URL or path associated with the service provider (e.g., app.enterprise.com / path).

[0070] At "3B", the inspection agent 114 can then redirect the client agent 118 (along with the proxy SAML request generated by the inspection agent 114) to the enterprise IdP service 112. In some examples, the proxy SAML request may be specific to the inspection agent 114 and / or different from the service provider SAML request that the service provider 104 can generate. For example, the proxy SAML request may include the signature of the inspection agent 114 (e.g., a request digest encrypted with the agent's private key).

[0071] At point “4A”, the Enterprise IdP service 112 can then operate to authenticate the client. In some examples, the Enterprise IdP service 112 can use any authentication technology (e.g., single-factor authentication, multi-factor authentication, biometric authentication, etc.) to challenge the client. Once the Enterprise IdP service has authenticated and / or identified the client, it can query the policy server based on the client name and service name. The Enterprise IdP service can then determine, based on the associated policy, that the client needs to access the service through an inspection proxy.

[0072] Enterprise IdP service 112 can then perform policy validation to verify that the client conforms to the policy, for example, verifying that a SAML request received from client agent 118 conforms to the policy. Enterprise IdP service 112 can verify that a previously received SAML request was issued by inspection agent 114, which may indicate that client agent 118 is attempting to connect to service provider 104 through inspection agent 114. Enterprise IdP service 102 can determine that this conforms to the policy action received from policy server 116, and enterprise IdP service 102 can authorize the flow and generate two SAML assertions, for example, a proxy SAML assertion in response to the proxy SAML request, and a service provider SAML assertion to confirm authorization to service provider 104. In some examples, the proxy SAML assertion is sent to client device 106, and the service provider SAML assertion is stored in a data storage associated with enterprise IdP service 112.

[0073] Additionally or alternatively, Enterprise IdP service 112 may determine that a previously received SAML request was issued by service provider 104, which may indicate that user agent 118 is attempting to connect directly to service provider 104. Enterprise IdP service 112 may determine that this does not comply with policy handling received from policy server 116, and Enterprise IdP service 112 may reject the flow and / or notify the client that access is denied due to policy violation.

[0074] At “4B”, Enterprise IdP service 112 can redirect client agent 118 and agent SAML assertions to the service name (e.g., app.enterprise.com with IP address 1.2.3.4).

[0075] At “5”, client agent 118 can be redirected to inspection agent 114, and inspection agent 114 can then query enterprise IdP service 112, providing enterprise IdP service 112 with a proxy SAML assertion to receive a service provider SAML assertion stored in the data storage associated with enterprise IdP service 112. It should be understood that “5” can include “5A”, “5B”, and “5C”. Inspection agent 114 can then send a request to service provider 104, providing service provider SAML statements retrieved from enterprise IdP service 112. Service provider 104 can then use the service provider SAML assertion to authorize the client and provide the requested content to inspection agent 114 (see “5C”), where inspection agent 114 can forward the content to client agent (see “5B” and “5A”). Additionally or alternatively, service provider 104 can install a first cookie to maintain authorization for a subsequent period. Service provider 104 can then send a first cookie to inspection agent 114, which can be used to authorize the client via inspection agent 114 and service provider 104 for a subsequent period. Alternatively, inspection agent 114 can store the first cookie in local data storage associated with inspection agent 114. Inspection agent 114 can then install a second cookie to maintain authorization for agent 114 for a subsequent period. Inspection agent 114 can then send a second cookie to client device 106, which can be used to authorize client device 106 with inspection agent 114 for a subsequent period. This prevents client device 106 from directly accessing service provider 104 using the first cookie, which is against policy.

[0076] Additionally or alternatively, the example traffic flow described herein can be executed without an authenticated DNS client agent 118 on the enterprise client device 106. As previously mentioned, the authenticated DNS client agent 118 can be configured to establish an authenticated channel with the DNS server 110 controlled by the enterprise TIS 102, providing the enterprise DNS server 110 with the client's authenticated identity. However, the DNS server 110 can determine the client's identity in other ways. In some examples, personalized DNS servers can be implemented. For example, different DNS servers can be used for each client or group of clients under the same policy. Each DNS server can respond to queries based on the policy of its associated client (or group of clients). Therefore, the system and / or process does not need to have an authenticated DNS client agent 118; instead, the system and / or process may only require the client to configure their own device to use a specific (personalized) DNS server.

[0077] Figures 2A to 2C Various data flow diagrams are shown associated with example process 200, according to which enterprise traffic interception service 102 can implement a policy that governs how client devices 106 access service provider 104 in various ways. In some examples, Figures 2A to 2C This may include an authenticated DNS client 202 associated with client device 106. The authenticated DNS client 202 may include a reference... Figure 1A and Figure 1B The various components and / or technologies of the certified DNS client are described.

[0078] Additionally, it should be noted that the example traffic flow described herein can be executed even without an authenticated DNS client 202 on the enterprise client device 106. As previously mentioned, the authenticated DNS client agent 202 can be configured to establish an authenticated channel with the DNS server 110 controlled by the enterprise TIS 102, providing the enterprise DNS server 110 with the client's authenticated identity. However, the DNS server 110 can determine the client's identity in other ways. In some examples, personalized DNS servers can be implemented. For example, different DNS servers can be used for each client or client group under the same policy. Each DNS server can respond to queries based on the policy of its associated client (or client group). Therefore, the system and / or process does not need to have an authenticated DNS client agent 202; instead, the system and / or process may only require the customer to configure their own device to use a specific (personalized) DNS server.

[0079] Figure 2AA data flow diagram of an example process 200 is shown, which can be used by an enterprise traffic interception service 102 to implement a policy that allows a client device 106 to access a service provider 104 using a direct connection.

[0080] At position 204, the DNS server may receive requests for resolving the service provider name (e.g., app.enterprise.com) from a client agent 118 (e.g., a browser) running on enterprise client device 106. Enterprise DNS server 110 can determine the client's identity. For example, the client device may have an authenticated DNS client agent 202 installed thereon. Authenticated DNS client agent 202 may be configured to establish an authenticated channel with DNS server 110 controlled by enterprise TIS 102, providing the enterprise DNS server 110 with the client's authenticated identity. Additionally or alternatively, enterprise DNS server 110 may be configured such that all requests for resolving the service provider name must include a client ID that can be used to identify the client.

[0081] At position 206, once the enterprise DNS server 110 recognizes the client, the DNS server 110 can query the policy server 116 based on the client name and service name.

[0082] At position 208, policy server 116 can return the corresponding policy to DNS server 110. DNS server 110 can then determine, based on the associated policy, whether the client needs to directly access the service.

[0083] At 210, DNS server 110 can reply to client agent 118 with the IP address of the actual service provider 104 (e.g., 5.6.7.8).

[0084] At position 212, the client agent 118 can then directly contact the service provider 104 using the IP address and request a specific URL or path (e.g., app.enterprise.com / path).

[0085] At 214, service provider 104 can receive a request for a specific URL and then redirect the client proxy (along with the service provider SAML request generated by service provider 104) to enterprise IdP service 112 for authentication.

[0086] At 216, as previously stated, service provider 104 can redirect client agent 118 (along with the service provider SAML authentication request) to enterprise IdP service 112.

[0087] At 218, the Enterprise IdP service 112 can then be used to authenticate the client. In some examples, the Enterprise IdP service 112 can use any authentication technology (e.g., single-factor authentication, multi-factor authentication, biometric authentication, etc.) to challenge the client.

[0088] At 220, once the enterprise IdP service 112 has authenticated and / or identified the client, the enterprise IdP service 112 can query the policy server 116 based on the client name and service name.

[0089] At position 222, policy server 116 can return the corresponding policy to enterprise IdP service 112. Enterprise IdP service 112 can then determine, based on the associated policy, whether client device 106 needs to directly access the service.

[0090] At 224, Enterprise IdP service 112 can then perform policy validation to verify that the client conforms to the policy, for example, verifying that a SAML request received from client agent 118 conforms to the policy. Enterprise IdP service 112 can verify that a previously received SAML request was issued by service provider 104, which may indicate that user agent 118 is attempting to connect directly to service provider 104. Enterprise IdP service 112 can determine that this conforms to the policy disposition received from policy server 116, and enterprise IdP service 112 can authorize the flow and generate a SAML assertion to send to client device 106. In some examples, the SAML assertion can be configured as a SAML assertion of service provider 104 to assert authorization to service provider 104.

[0091] At 226, Enterprise IdP service 112 can redirect client agent 118 (along with service provider SAML assertions) to the service name (e.g., app.enterprise.com with IP address 5.6.7.8).

[0092] At 228, client agent 118 can send a service provider SAML assertion to service provider 104 to authorize the client and open a connection.

[0093] At point 230, service provider 104 can use a service provider SAML assertion to authorize the client and can provide requested content to client device 106. Additionally or alternatively, service provider 104 can install a cookie to maintain authorization for a subsequent period. Service provider 104 can then send the cookie to client device 106, whereby the cookie can be used to authorize client device 106 to service provider 104 for a subsequent period.

[0094] Figure 2BA data flow diagram of an example process 200 is shown, according to which an enterprise traffic interception service 102 can implement a policy that allows a client device 106 to use a proxy connection to access a service provider 104.

[0095] At position 204, the DNS server may receive requests for resolving the service provider name (e.g., app.enterprise.com) from a client agent 118 (e.g., a browser) running on enterprise client device 106. Enterprise DNS server 110 can determine the client's identity. For example, the client device may have an authenticated DNS client agent 202 installed thereon. Authenticated DNS client agent 202 may be configured to establish an authenticated channel with DNS server 110 controlled by enterprise TIS 102, providing the enterprise DNS server 110 with the client's authenticated identity. Additionally or alternatively, enterprise DNS server 110 may be configured such that all requests for resolving the service provider name must include a client ID that can be used to identify the client.

[0096] At position 206, once the enterprise DNS server 110 recognizes the client, the DNS server 110 can query the policy server 116 based on the client name and service name.

[0097] At position 208, policy server 116 can return the corresponding policy to DNS server 110. DNS server 110 can then determine, based on the associated policy, that the client needs to access service provider 104 through inspection proxy 114.

[0098] At 210, DNS server 110 can reply to client agent 118 with the IP address of check agent 114 (e.g., 1.2.3.4).

[0099] At 212, client agent 118 can then use the IP address to contact inspection agent 114 and request a specific URL or path associated with the service provider (e.g., app.enterprise.com / path).

[0100] At 214, the inspection agent 114 can receive a request for a specific URL and then redirect the client agent 118 (along with the agent SAML request generated by the inspection agent 114) to the enterprise IdP service 112 for authentication.

[0101] At 216, as previously stated, inspecting agent 114 can redirect client agent 118 (along with the agent SAML authentication request) to enterprise IdP service 112.

[0102] At 218, the Enterprise IdP service 112 can then be used to authenticate the client. In some examples, the Enterprise IdP service 112 can use any authentication technology (e.g., single-factor authentication, multi-factor authentication, biometric authentication, etc.) to challenge the client.

[0103] At 220, once the enterprise IdP service 112 has authenticated and / or identified the client, the enterprise IdP service 112 can query the policy server 116 based on the client name and service name.

[0104] At position 222, policy server 116 can return the corresponding policy to enterprise IdP service 112. Enterprise IdP service 112 can then determine, based on the associated policy, that client device 106 needs to access the service provider through an inspection proxy.

[0105] At 224, Enterprise IdP service 112 can then perform policy validation to verify that the client conforms to the policy, for example, verifying that a SAML request received from client agent 118 conforms to the policy. Enterprise IdP service 112 can verify that a previously received SAML request was issued by inspection agent 114, which may indicate that client agent 118 is attempting to connect to service provider 104 through inspection agent 114. Enterprise IdP service 102 can determine that this conforms to the policy action received from policy server 116, and Enterprise IdP service 102 can authorize the flow and generate two SAML assertions, for example, a proxy SAML assertion in response to the proxy SAML request, and a service provider SAML assertion to confirm authorization to service provider 104. In some examples, the proxy SAML assertion is sent to client device 106, and the service provider SAML assertion is stored in a data storage associated with enterprise IdP service 112.

[0106] At 232, Enterprise IdP service 112 can redirect client agent 118 (along with agent SAML assertions) to the service name (e.g., app.enterprise.com with IP address 1.2.3.4).

[0107] At 228, client agent 118 can send a proxy SAML assertion to the inspection agent to authorize the client and open a connection.

[0108] At 234, as previously described, client agent 118 can be redirected to inspection agent 114, and inspection agent 114 can then query enterprise IdP service 112 to provide agent SAML assertions to enterprise IdP service 112 to receive service provider SAML assertions stored in the data storage associated with enterprise IdP service 112.

[0109] At position 236, Enterprise IdP service 112 can return a Service Provider SAML assertion to Inspection Agent 114 for use in authenticating Inspection Agent 114 to Service Provider 104.

[0110] At 238, the inspection agent 114 can then send a request to the service provider 104 and provide the service provider SAML statement retrieved from the enterprise IdP service 112 to the service provider 104 to authenticate the inspection agent 114 and open a connection.

[0111] At point 230, service provider 104 can then use a service provider SAML assertion to authorize the client and provide the requested content to inspection agent 114. Alternatively or additionally, service provider 104 may install a first cookie to maintain authorization for a subsequent period. Service provider 104 can then send the first cookie to inspection agent 114, wherein the cookie can be used to authorize the client via inspection agent 114 to service provider 104 for a subsequent period.

[0112] At point 240, the inspection agent 114 may store a first cookie in the local data storage associated with the inspection agent 114. The inspection agent 114 may then install a second cookie to maintain authorization for the agent 114 for a subsequent period of time. This prevents the client device 106 from directly accessing the service provider 104 using the first cookie, which is against policy.

[0113] At 242, the inspection agent 114 can then forward the content provided from the service provider 104 to the client device 106. Additionally or alternatively, the inspection agent 114 can then send a second cookie to the client device 106, which can be used to authorize the client device 106 to the inspection agent 114 for a subsequent period of time.

[0114] Figure 2C A data flow diagram of an example process 200 is shown, under which an enterprise traffic blocking service 102 can implement a policy that denies a client device 106 access to the service provider 104 using a connection that conflicts with the policy.

[0115] At position 204, the DNS server may receive requests for resolving the service provider name (e.g., app.enterprise.com) from a client agent 118 (e.g., a browser) running on enterprise client device 106. Enterprise DNS server 110 may determine the client's identity. For example, the client device may have an authenticated DNS client agent 202 installed thereon. Authenticated DNS client agent 202 may be configured to establish an authenticated channel with DNS server 110 controlled by enterprise TIS 102, providing the enterprise DNS server 110 with the client's authenticated identity. Additionally or alternatively, enterprise DNS server 110 may be configured such that all requests for resolving the service provider name must include a client ID that can be used to identify the client.

[0116] At position 206, once the enterprise DNS server 110 recognizes the client, the DNS server 110 can query the policy server 116 based on the client name and service name.

[0117] At position 208, policy server 116 can return the corresponding policy to DNS server 110. DNS server 110 can then determine, based on the associated policy, that the client needs to access service provider 104 through inspection proxy 114.

[0118] At 210, DNS server 110 can reply to client agent 118 with the IP address of check agent 114 (e.g., 1.2.3.4).

[0119] At point 244, the client and / or client device 106 may perform improper behavior. For example, when DNS server 110 has already responded with the IP address of the inspection agent 114 (e.g., 1.2.3.4), the client may ignore the DNS response. Instead, the client may contact service provider 104 directly using the IP address of service provider 104 (e.g., 5.6.7.8) and request a specific URL or path associated with the service provider (e.g., app.enterprise.com / path).

[0120] At position 212, client agent 118 may be behaving improperly and using the IP address of service provider 104 to directly contact service provider 104 and request a specific URL or path (e.g., app.enterprise.com / path).

[0121] At 214, service provider 104 can receive a request for a specific URL and then redirect the client proxy (along with the service provider SAML request generated by service provider 104) to enterprise IdP service 112 for authentication.

[0122] At 216, as previously stated, service provider 104 can redirect client agent 118 (along with the service provider SAML authentication request) to enterprise IdP service 112.

[0123] At 218, the Enterprise IdP service 112 can then be used to authenticate the client. In some examples, the Enterprise IdP service 112 can use any authentication technology (e.g., single-factor authentication, multi-factor authentication, biometric authentication, etc.) to challenge the client.

[0124] At 220, once the enterprise IdP service 112 has authenticated and / or identified the client, the enterprise IdP service 112 can query the policy server 116 based on the client name and service name.

[0125] At position 222, policy server 116 can return the corresponding policy to enterprise IdP service 112. Enterprise IdP service 112 can then determine, based on the associated policy, whether client device 106 needs to directly access the service.

[0126] At 224, Enterprise IdP service 112 can then perform policy validation to verify that the client conforms to the policy, for example, verifying that a SAML request received from client agent 118 conforms to the policy. For example, Enterprise IdP service 112 may determine that a previously received SAML request was issued by service provider 104, which may indicate that user agent 118 is attempting to connect directly to service provider 104. Enterprise IdP service 112 may determine that this does not comply with policy handling received from policy server 116, and Enterprise IdP service 112 may reject the flow and / or notify the client that access is denied due to policy violation.

[0127] At 246, as previously described, Enterprise IdP service 112 may reject traffic and / or notify clients of access denial due to policy violations. In some examples, Enterprise IdP service 112 may cause client agent 118 to present a customized webpage including an instruction to such denial. In some examples, the customized webpage may include instructions for clients to access the service provider using inspection agent 114. Additionally or alternatively, the customized webpage may include instructions for clients to reconfigure their DNS server from a personalized DNS server to Enterprise DNS server 110.

[0128] Figures 3 to 5 Flowcharts for example methods 300, 400, and 500 are shown, illustrating methods that are at least partially derived from... Figure 1A This refers to various aspects of the functions performed by the enterprise traffic interception service 102 as described in Figure 2. (References provided in this document are not provided.) Figure 3 , Figure 4 ,as well as Figure 5The described logical operations can be implemented as (1) a sequence of computer-implemented actions or program modules running on a computing system and / or (2) interconnected machine logic circuits or circuit modules within a computing system.

[0129] The implementation of the various components described herein depends on the performance of the computing system and other requirements. Accordingly, the logical operations described herein are referred to as operations, structured devices, actions, or modules. These operations, structured devices, actions, and modules can be implemented in software, firmware, dedicated digital logic, and any combination thereof. It should also be understood that more advanced technologies can be implemented... Figure 3 , Figure 4 , Figure 5 The operations shown and described herein may be more or fewer. These operations may also be performed in parallel or in a different order than those described herein. Some or all of these operations may also be performed by components other than those specifically identified. While the techniques described in this disclosure refer to specific components, in other examples, these techniques may be implemented by fewer components, more components, different components, or any configuration of components.

[0130] Figure 3 A flowchart of example method 300 is shown, which is used to implement a policy that allows client device 106 to access service provider 104 using a direct connection by using enterprise traffic interception service 102.

[0131] At 302, method 300 may include: receiving first data indicating the identity of a user associated with user equipment 106 from a Domain Name Service (DNS) server 110 associated with the enterprise network. In some examples, the enterprise network may be configured as an enterprise traffic interception service 102.

[0132] At 304, method 300 may include: receiving, at DNS server 110 and from user equipment 106, a first request for resolving the address of a service associated with service provider 104.

[0133] At 306, method 300 may include: identifying, by DNS server 110 and at least in part, a policy associated with a user accessing the service, the policy instructing user equipment 106 to be configured for a direct access path to the service.

[0134] At 308, method 300 may include: providing the user equipment 106 with an indication of the address of a service associated with the service provider 104 from the DNS server 110.

[0135] At 310, method 300 may include: receiving a second request for a direct access path from user equipment 106 to service provider 104 at service provider 104 and from user equipment 106.

[0136] At 312, method 300 may include: receiving request data at the identity provider 112 of the enterprise network and from the user equipment 106, indicating that a third request is made to authenticate the user's identity to access a direct access path.

[0137] At 314, method 300 may include: receiving a policy at identity provider 112 based at least in part on the identity of the authenticated user.

[0138] At 316, method 300 may include: identity provider 112 determining that the policy indicates a direct access path and that the request data indicates a direct access path.

[0139] At 318, method 300 may include: providing the user equipment with access to a direct access path from user equipment 106 to service provider 104, based at least in part on determining that the policy indicates a direct access path and that the request data indicates a direct access path.

[0140] Alternatively or additionally, method 300 may include: generating an authorization assertion by the identity provider indicating that the user equipment can access a direct access path. Alternatively or additionally, method 300 may include: sending the authorization assertion from the identity provider to the user equipment. Alternatively or additionally, method 300 may include: sending the authorization assertion from the user equipment to the service provider, at least in part based on receiving the authorization assertion at the user equipment. Alternatively or additionally, providing the user equipment with access to a direct access path from the user equipment to the service provider may be at least in part based on sending the authorization assertion from the user equipment to the service provider.

[0141] Additionally or alternatively, method 300 may include: generating a cookie associated with a user device by a service provider, the cookie indicating authorization to access the service. In some examples, the cookie may be generated at least in part based on providing the user device with access to a direct access path. Additionally or alternatively, method 300 may include: storing the cookie in a data storage device associated with the service provider. Additionally or alternatively, method 300 may include: sending the cookie from the service provider to the user device.

[0142] Alternatively or additionally, a second request may be received at the first time. Alternatively or additionally, method 300 may include: receiving, at the service provider and at a second time after the first time, a fourth request from the user device for a direct access path from the user device to the service provider, the fourth request including a cookie. Alternatively or additionally, method 300 may include: identifying the cookie in a data storage associated with the service provider. Alternatively or additionally, method 300 may include: providing the user device with access to the direct access path. In some examples, access to the direct access path may be provided to the user device at least in part based on the service provider identifying the cookie.

[0143] Alternatively or additionally, the user equipment may include an authenticated DNS client associated with the user's identity. Alternatively or additionally, method 300 may include: establishing an authenticated channel by the authenticated DNS client connecting the authenticated DNS client to a DNS server, the authenticated channel indicating the identity of the user associated with the user equipment. Alternatively or additionally, policies associated with a user accessing the service may be identified, at least in part, based on the authenticated channel.

[0144] Alternatively or additionally, a direct access path can be configured to send service-related content from the service provider to the user device. Alternatively or additionally, a proxy access path can be configured to send content from the service provider to an inspection proxy. Alternatively or additionally, a proxy access path can be configured to have the content inspected by the inspection proxy. Alternatively or additionally, a proxy access path can be configured to send content from the inspection proxy to the user device.

[0145] Figure 4 A flowchart of example method 400 is shown, which is used to implement a policy that allows client device 106 to access service provider 104 using a proxy connection by using enterprise traffic interception service 102.

[0146] At 402, method 400 may include: receiving first data from user equipment 106 at a Domain Name Service (DNS) server 110 associated with enterprise network 102, the first data indicating the identity of a user associated with user equipment 106. In some examples, the enterprise network may be configured as enterprise traffic interception service 102.

[0147] At 404, method 400 may include: receiving, at DNS server 110 and from user equipment 106, a first request for resolving the address of a service associated with service provider 104.

[0148] At 406, method 400 may include: identifying, by DNS server 110 and at least in part, a policy associated with a user accessing the service, the policy instructing user equipment 106 to be configured for a proxy access path to the service.

[0149] At 408, method 400 may include providing an indication from DNS server 110 and to user equipment 106 of the address of inspection agent 114 associated with corporate network 102.

[0150] At 410, method 400 may include: receiving, at inspection agent 114 and from user equipment 106, a second request for a proxy access path from user equipment 106 to service provider 104 via inspection agent 114.

[0151] At 412, method 400 may include: method 400 may include: receiving request data at identity provider 112 of enterprise network 102 and from user equipment 106, the request data indicating a third request for the identity of a user to authenticate access proxy access path.

[0152] At 414, method 400 may include: receiving a policy at identity provider 112 based at least in part on the identity of the authenticated user.

[0153] At 416, method 400 may include: identity provider 112 determining that the policy indicates a proxy access path and that the request data indicates a proxy access path.

[0154] At 418, method 400 may include: providing user equipment 106 with access to a proxy access path from user equipment 106 to service provider 104 via inspection proxy 114, based at least in part on determining that the policy indicates a proxy access path and the request data indicates a proxy access path.

[0155] Additionally or alternatively, method 400 may include: generating a first authorization assertion by the identity provider indicating that the user equipment can access the proxy access path. Additionally or alternatively, method 400 may include: sending the first authorization assertion from the identity provider to the user equipment. Additionally or alternatively, method 400 may include: sending the first authorization assertion from the user equipment to the inspection agent, at least in part based on receiving the first authorization assertion at the user equipment. In some examples, the user equipment may be granted access to the proxy access path from the user equipment to the service provider via the inspection agent, at least in part based on sending the first authorization assertion from the user equipment to the inspection agent.

[0156] Additionally or alternatively, method 400 may include: sending a query for a second authorization assertion from the inspection agent and to the identity provider, the query including the first authorization assertion. Additionally or alternatively, method 400 may include: generating a second authorization assertion by the identity provider indicating that the inspection agent can access the service. Additionally or alternatively, method 400 may include: sending the second authorization assertion from the identity provider to the inspection agent. Additionally or alternatively, method 400 may include: sending the second authorization assertion from the inspection agent to the service provider based at least in part on receiving the second authorization assertion at the inspection agent. In some examples, access to a proxy access path from the user device to the service provider via the inspection agent may be provided to the user device based at least in part on sending the second authorization assertion from the inspection agent to the service provider.

[0157] In some examples, a second request may be received at a first time. Additionally or alternatively, method 400 may include: receiving, at the inspection agent and at a second time after the first time, a fourth request for a proxy access path from the user device to the service provider, the fourth request including a second cookie. Additionally or alternatively, method 400 may include: identifying the second cookie in data storage associated with the inspection agent. Additionally or alternatively, method 400 may include: receiving the fourth request and the first cookie at the service provider and from the inspection agent. Additionally or alternatively, method 400 may include: identifying the first cookie in data storage associated with the service provider. Additionally or alternatively, method 400 may include: providing the user device with access to the proxy access path based at least in part on the inspection agent that identified the second cookie and the service provider that identified the first cookie.

[0158] Additionally or alternatively, method 400 may include: generating a first cookie associated with the user device by the service provider, at least in part based on providing access to a proxy access path to the user device, the first cookie indicating authorization to access the service. Additionally or alternatively, method 400 may include: storing the first cookie in a first data storage associated with the service provider. Additionally or alternatively, method 400 may include: sending the first cookie from the service provider to the inspection proxy. Additionally or alternatively, method 400 may include: generating a second cookie associated with the user device by the inspection proxy, the second cookie indicating authorization to access the service via the proxy access path. Additionally or alternatively, method 400 may include: storing the first cookie and the second cookie in a second data storage associated with the inspection proxy. Additionally or alternatively, method 400 may include: sending the second cookie from the inspection proxy to the user device.

[0159] In some examples, the user equipment may include an authenticated DNS client associated with the user's identity. Additionally or alternatively, method 400 may include: establishing an authenticated channel by the authenticated DNS client connecting the authenticated DNS client to a DNS server, the authenticated channel indicating the identity of the user associated with the user equipment. In some examples, policies associated with a user accessing the service may be identified at least in part based on the authenticated channel.

[0160] Figure 5 A flowchart of example method 400 is shown, which is used to implement a policy of denying client device 106 access to service provider 104 by using enterprise traffic blocking service 102 to use a connection that conflicts with the policy.

[0161] At 502, method 500 may include: receiving first data from user equipment 106 at a Domain Name Service (DNS) server 110 associated with enterprise network 102, the first data indicating the identity of a user associated with user equipment 106. In some examples, the enterprise network may be configured as enterprise traffic interception service 102.

[0162] At 504, method 500 may include: receiving, at DNS server 110 and from user equipment 106, a first request for resolving the address of a service associated with service provider 104.

[0163] At 506, method 500 may include: identifying, by DNS server 110 and at least in part, a policy associated with a user accessing the service, the policy instructing user equipment 106 to be configured for a proxy access path to the service.

[0164] At 508, method 500 may include: providing user equipment 106 with an indication from DNS server 110 of the address of inspection agent 114 associated with corporate network 102.

[0165] At 510, method 500 may include: receiving a second request for a direct access path from user equipment 106 to service provider 104 at service provider 104 and from user equipment 106.

[0166] At 512, method 500 may include: receiving request data at identity provider 112 of enterprise network 102 and from user equipment 106, indicating that a third request is made to authenticate the user's identity to access a direct access path.

[0167] At 514, method 500 may include: receiving a policy at identity provider 112 based at least in part on the identity of the authenticated user.

[0168] At 516, method 500 may include: identity provider 112 determining that the policy indicates a proxy access path and the request data indicates a direct access path.

[0169] At 518, method 500 may include: denying user equipment 106 access to a direct access path from user equipment 106 to service provider 104, at least in part based on determining that the policy indicates a proxy access path and the request data indicates a direct access path.

[0170] Additionally or alternatively, method 500 may include: sending second data from the identity provider to the user device, configured to redirect the user device to a custom webpage.

[0171] In some examples, the customized webpage includes instructions for users to install the required DNS client. Additionally or alternatively, the DNS server may be configured as a personalized DNS server. In some examples, the customized webpage includes instructions for users to reconfigure the DNS server from a personalized DNS server to an enterprise DNS server. Additionally or alternatively, the policy may indicate a direct access path and / or the request data may indicate a proxy access path. In some examples, the customized webpage includes instructions for users to access a direct access path.

[0172] Additionally or alternatively, method 500 may include: the identity provider determining that the policy indicates a direct access path and the request data indicates a proxy access path. Additionally or alternatively, method 500 may include: providing the user equipment with access to a proxy access path from the user equipment to the service provider, at least in part based on determining that the policy indicates a direct access path and the request data indicates a proxy access path.

[0173] In some examples, a direct access path can be configured to send service-related content from the service provider to the user's device. Alternatively, a proxy access path can be configured to send content from the service provider to an inspection agent. Alternatively, a proxy access path can be configured to have the content inspected by the inspection agent. Alternatively, a proxy access path can be configured to send content from the inspection agent to the user's device.

[0174] Figure 6 A computing system diagram of an example configuration of a data center 600 is shown, which can be used to implement various aspects of the techniques disclosed herein. Figure 6The example data center 600 shown includes several server computers 602A to 602F (which may be referred to herein as "one server computer 602" in the singular or "a plurality of server computers 602") for providing computing resources. In some examples, the resources and / or server computers 602 may include or correspond to any type of computing device described herein. Although described as a server, server computer 602 may include any type of networking device, such as a server, switch, router, hub, bridge, gateway, modem, repeater, access point, etc.

[0175] Server computer 602 may be a standard tower, rack, or blade server computer appropriately configured to provide computing resources. In some examples, server computer 602 may provide computing resources 604, including data processing resources such as VM instances or hardware computing systems, database clusters, compute clusters, storage clusters, data storage resources, database resources, networking resources, VPNs, etc. Some servers 602 may also be configured to execute resource manager 606, which is capable of instantiating and / or managing computing resources. For example, in the case of VM instances, resource manager 606 may be a hypervisor or another type of program configured to run multiple VM instances on a single server computer 602. Server computer 602 in data center 600 may also be configured to provide network services and other types of services.

[0176] exist Figure 6 In the example data center 600 shown, server computers 602A to 602F are also interconnected using appropriate LANs 608. It should be understood that the configurations and network topologies described herein have been greatly simplified, and more computing systems, software components, networks, and networking devices can be used to interconnect the various computing systems disclosed herein and provide the aforementioned functionality. Appropriate load balancing devices or other types of network infrastructure components can also be used to balance the load between data centers 600, between each server computer 602A to 602F in each data center 600, and potentially among the computing resources in each server computer 602. It should be understood that references... Figure 6 The configuration of the data center 600 described is merely illustrative and other implementations may be used.

[0177] In some cases, data center 600 can provide computing resources, such as applications, VM instances, and storage, on a permanent or on-demand basis. In other types of functions, computing resources provided by the cloud computing network can be used to implement the various services and technologies mentioned above. Computing resources 604 provided by the cloud computing network can include various types of computing resources, such as data processing resources (e.g., tenant containers and VM instances), data storage resources, networking resources, data communication resources, network services, VPN instances, etc.

[0178] Each type of computing resource 604 provided by the cloud computing network can be general-purpose or available in several specific configurations. For example, data processing resources can be used as physical computers or VM instances in a variety of different configurations. VM instances can be configured to run applications, including web servers, application servers, media servers, database servers, some or all of the aforementioned network services, and / or other types of programs. Data storage resources can include file storage devices, block storage devices, etc. The cloud computing network can also be configured to provide other types of computing resources 604 not specifically mentioned herein.

[0179] In one embodiment, computing resources 604 provided by a cloud computing network can be enabled by one or more data centers 600 (which may be referred to herein as "one data center 600" in the singular or "multiple data centers 600" in the plural). A data center 600 is a facility for housing and operating computer systems and related components. A data center 600 typically includes redundant and backup power, communication, cooling, and security systems. Data centers 600 may also be located in geographically distinct locations. The following will combine... Figure 7 An illustrative implementation of a data center 600 that can be used to implement the technology disclosed herein is described.

[0180] Figure 7 A diagram of a computer architecture is shown, illustrating an example computer hardware architecture for implementing a network device that can be used to implement aspects of the various technologies presented herein. Figure 7 The illustrated computer architecture depicts conventional server computers, workstations, desktop computers, laptops, tablets, web applications, e-readers, smartphones, and / or other computing devices, and can be used to execute any of the software components presented herein. In some examples, computer 700 may correspond to the SSO service 102 described herein and may include networked devices such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, etc.

[0181] Computer 700 includes a baseboard 702, or "motherboard," which is a printed circuit board to which many components or devices can be connected via a system bus or other electrical communication paths. In an illustrative configuration, one or more central processing units (CPUs) 704 operate in conjunction with a chipset 706. The CPU 704 may be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of computer 700.

[0182] The CPU 704 performs operations by transitioning from one discrete physical state to the next, where state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements typically include electronic circuitry, such as flip-flops, that maintains one of two binary states, and electronic circuitry, such as logic gates, that provides an output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adders / subtractors, arithmetic logic units, floating-point units, and so on.

[0183] Chipset 706 provides an interface between CPU 704 and the remaining components and devices on substrate 702. Chipset 706 may provide an interface with RAM 708, which is used as main memory in computer 700. Chipset 706 may further provide an interface with a computer-readable storage medium, such as read-only memory (ROM) 710 or non-volatile RAM (NVRAM), for storing basic routines that facilitate the startup of computer 700 and the transfer of information between various components and devices. ROM 710 or NVRAM may also store other software components necessary for the operation of computer 700 according to the configuration described herein.

[0184] Computer 700 can operate in a networked environment, using logical connections to remote computing devices and computer systems via a network (e.g., network 116). Chipset 706 may include functionality for providing network connectivity via NIC 712 (e.g., a Gigabit Ethernet adapter). NIC 712 enables computer 700 to connect to other computing devices via network 116. It should be understood that multiple NICs 712 may be present in computer 700 to connect the computer to other types of networks and remote computer systems.

[0185] Computer 700 can be connected to storage device 718, which provides non-volatile storage for the computer. Storage device 718 can store operating system 720, programs 722, and data, which have been described in more detail herein. Storage device 718 can be connected to computer 700 via storage controller 714, which is connected to chipset 706. Storage device 718 can consist of one or more physical storage units. Storage controller 714 can be connected to physical storage units via a serial attached SCSI (SAS) interface, a serial advanced technology attachment (SATA) interface, a fiber channel (FC) interface, or other types of interfaces used for physical connection and data transfer between the computer and physical storage units.

[0186] Computer 700 can store data on storage device 718 by changing the physical state of physical storage units to reflect the stored information. In different embodiments of this specification, the specific changes in physical state can depend on various factors. Examples of such factors include, but are not limited to, the technology used to implement the physical storage units, whether storage device 718 is characterized as primary or secondary storage, etc.

[0187] For example, computer 700 can store information in storage device 718 by issuing instructions through storage controller 714 to change the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of this specification; the foregoing examples are provided merely for convenience. Computer 700 can further read information from storage device 718 by detecting the physical state or characteristics of one or more specific locations within the physical storage unit.

[0188] In addition to the aforementioned high-capacity storage device 718, computer 700 can also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will understand that computer-readable storage media are any available medium that provides non-transitory storage of data and can be accessed by computer 700. In some examples, operations performed by various components in environment 100 can be supported by one or more devices similar to computer 700. In other words, some or all of the operations performed by various components in environment 100 can be performed by one or more computer devices 700 operating in a cloud-based configuration.

[0189] By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM (EPROM), electrically-erasable programmable ROM (EEPROM), flash memory or other solid-state storage technologies, compact disc ROM (CD-ROM), digital versatile disc (DVD), high-definition DVD (HD-DVD), Blu-ray or other optical storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information in a non-transitory manner.

[0190] As briefly mentioned above, storage device 718 may store operating system 720 used to control the operation of computer 700. According to one embodiment, the operating system includes a LINUX operating system. According to another embodiment, the operating system includes a MICROSOFT operating system from Redmond, Washington. The server operating system. According to another embodiment, the operating system may include a UNIX operating system or a variant thereof. It should be understood that other operating systems may also be used. Storage device 718 may store other systems, applications, and data used by computer 700.

[0191] In one embodiment, storage device 718 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computer 700, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform computer 700 by specifying how CPU 704 transitions between states. According to one embodiment, computer 700 has access to a computer-readable storage medium storing computer-executable instructions that, when executed by computer 700, perform the above-described... Figures 1A to 5 The various processes described herein. The computer 700 may also include a computer-readable storage medium storing instructions for performing any other computer-implemented operations described herein.

[0192] Computer 700 may also include one or more input / output controllers 716 for receiving and processing input from a number of input devices, such as a keyboard, mouse, touchpad, touchscreen, stylus, or other types of input devices. Similarly, input / output controllers 716 may provide output to a display, such as a computer monitor, flat panel display, digital projector, printer, or other types of output devices. It will be understood that computer 700 may not include... Figure 7 All components shown may include Figure 7 Other components not explicitly shown, or those that may utilize [the technology / method] Figure 7 The architecture shown is completely different.

[0193] As described herein, computer 700 may include one or more of enterprise traffic interception service 102, client device 106, or service provider 104. Computer 700 may include one or more hardware processors 704 (processors) configured to execute one or more stored instructions. The processors 704 may include one or more cores. Furthermore, computer 700 may include one or more network interfaces configured to provide communication between computer 700 and other devices (e.g., the communication performed by enterprise traffic interception service 102, service provider, and / or client device 106 as described herein). The network interface may include a device configured to couple to a personal area network (PAN), wired and wireless local area network (LAN), wired and wireless wide area network (WAN), etc. For example, the network interface may include a device compatible with Ethernet, Wi-Fi™, etc.

[0194] Program 722 may include any type of program or process for performing the techniques described in this disclosure. Program 722 may enable client device 106 to perform various operations.

[0195] In summary, this paper describes techniques for enforcing policies using Enterprise Traffic Interception Services (TIS) that authorize how clients access Software as a Service (SaaS) provided by a service provider, and selectively intercept enterprise network traffic based on each client and each service using Domain Name Service (DNS) and Single Sign-On (SSO) services. A TIS may include a DNS server, an identity provider service, a TLS inspection broker, and / or a policy server. The DNS server can handle requests to resolve service addresses and identify policies stored in the policy server to redirect clients based on their identity and service. The identity provider service can then query the policy server during client authorization to verify that the client request conforms to the policy and allow or deny access to the service.

[0196] Although the invention has been described with reference to specific examples, it should be understood that the scope of the invention is not limited to these specific examples. Since other modifications and variations made to adapt to specific operational requirements and environments will be apparent to those skilled in the art, the invention is not to be considered limited to the examples chosen for disclosure purposes, and covers all changes and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0197] While this application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions merely illustrate some embodiments that fall within the scope of the claims of this application.

Claims

1. A communication method, comprising: At the Domain Name Service (DNS) server associated with the enterprise network and from the user equipment, the first data indicates the identity of the user associated with the user equipment; At the DNS server and from the user equipment, a first request is received for resolving the address of a service associated with the service provider; The DNS server identifies a policy associated with the user accessing the service, based at least in part on the user's identity, and the policy instructs the user equipment to be configured for a direct access path to the service; The DNS server provides the user equipment with an indication of the address of the service associated with the service provider; At the service provider and from the user equipment, a second request is received for the direct access path from the user equipment to the service provider; At the identity provider of the enterprise network and from the user equipment, request data is received indicating a third request to authenticate the user's identity to access the direct access path; The policy is received from the identity provider, at least in part, based on authenticating the user's identity. The identity provider determines that the policy indicates the direct access path, and the request data indicates the direct access path; as well as At least in part, based on determining that the policy indicates the direct access path and the request data indicates the direct access path, the user equipment is provided with access to the direct access path from the user equipment to the service provider.

2. The communication method according to claim 1 further includes: The identity provider generates an authorization assertion indicating that the user equipment can access the direct access path; The authorization assertion is sent from the identity provider to the user device; The authorization assertion is sent from the user equipment to the service provider, at least in part based on the receipt of the authorization assertion at the user equipment. and Providing the user equipment with access to the direct access path from the user equipment to the service provider is based at least in part on sending the authorization assertion from the user equipment to the service provider.

3. The communication method according to claim 1 further includes: At least in part, based on providing the user device with access to the direct access path, the service provider generates a cookie associated with the user device, the cookie indicating authorization to access the service; The cookie is stored in a data storage device associated with the service provider; as well as The cookie is sent from the service provider to the user's device.

4. The communication method according to claim 3, wherein, The second request is received immediately, and the method further includes: At a second time following the first time, a fourth request for the direct access path from the user equipment to the service provider is received at the service provider and from the user equipment, the fourth request including the cookie; Identify the cookie in the data storage device associated with the service provider; and Access to the direct access path is provided to the user device, at least in part, based on the service provider's identification of the cookie.

5. The communication method according to any one of claims 1 to 4, wherein, The user equipment includes an authenticated DNS client associated with the user's identity, and the method further includes: An authenticated channel is established by the authenticated DNS client connecting the authenticated DNS client and the DNS server, the authenticated channel indicating the identity of the user associated with the user equipment; and The strategy for identifying users associated with accessing the service is at least in part based on the authenticated channel.

6. The communication method according to any one of claims 1 to 4, wherein: The direct access path is configured to send content associated with the service from the service provider to the user device; and The proxy access path is configured as follows: The content is sent from the service provider to the inspection agent associated with the enterprise network; The content is inspected by the inspection agent; and The content is sent from the inspection agent to the user device.

7. A communication method, comprising: At the Domain Name Service (DNS) server associated with the enterprise network and from the user equipment, the first data indicates the identity of the user associated with the user equipment; At the DNS server and from the user equipment, a first request is received for resolving the address of a service associated with the service provider; The DNS server identifies a policy associated with the user accessing the service, based at least in part on the user's identity, and the policy instructs the user equipment to be configured for a proxy access path to the service; The DNS server provides the user equipment with an indication of the address of the inspection agent associated with the enterprise network; At the inspection agent and from the user equipment, a second request is received for the proxy access path from the user equipment to the service provider via the inspection agent; The system receives request data from the identity provider of the enterprise network and from the user equipment, the request data indicating a third request to authenticate the user's identity to access the proxy access path; The policy is received from the identity provider, at least in part, based on authenticating the user's identity. The identity provider determines the policy that indicates the proxy access path, and the request data indicates the proxy access path; as well as At least in part, based on determining that the policy indicates the proxy access path and the request data indicates the proxy access path, the user equipment is provided with access to the proxy access path from the user equipment to the service provider via the inspection proxy.

8. The communication method according to claim 7, further comprising: The identity provider generates a first authorization assertion indicating that the user equipment can access the proxy access path; Send the first authorization assertion from the identity provider to the user device; The first authorization assertion is sent from the user equipment to the inspection agent, at least in part based on the receipt of the first authorization assertion at the user equipment. and Providing the user equipment with access to the proxy access path from the user equipment to the service provider via the inspection agent is based at least in part on sending the first authorization assertion from the user equipment to the inspection agent.

9. The communication method according to claim 8, further comprising: The inspection agent sends a query to the identity provider regarding a second authorization assertion, the query including the first authorization assertion; The identity provider generates a second authorization assertion indicating that the inspection agent can access the service; Send the second authorization assertion from the identity provider to the inspection agent; The second authorization assertion is sent from the inspection agent to the service provider, at least in part based on the receipt of the second authorization assertion at the inspection agent; and Providing the user equipment with access to the proxy access path from the user equipment to the service provider via the inspection agent is based at least in part on sending the second authorization assertion from the inspection agent to the service provider.

10. The communication method according to any one of claims 7 to 9, further comprising: Based at least in part on providing the user device with access to the proxy access path, the service provider generates a first cookie associated with the user device, the first cookie indicating authorization to access the service; The first cookie is stored in a first data storage device associated with the service provider; as well as Send the first cookie from the service provider to the inspection agent; The inspection proxy generates a second cookie associated with the user device, the second cookie indicating authorization to access the service via the proxy access path; The first cookie and the second cookie are stored in a second data storage device associated with the inspection agent; as well as The second cookie is sent from the inspection agent to the user device.

11. The communication method according to claim 10, wherein, The second request is received immediately, and the method further includes: At a second time following the first time, at the inspection proxy and from the user equipment, a fourth request for the proxy access path from the user equipment to the service provider is received, the fourth request including the second cookie; The second cookie is identified in a second data storage device associated with the inspection agent; The fourth request and the first cookie are received at the service provider and from the inspection agent. Identify the first cookie in the first data storage device associated with the service provider; and Access to the proxy access path is provided to the user device, at least in part, based on the inspection proxy that identifies the second cookie and the service provider that identifies the first cookie.

12. The communication method according to any one of claims 7 to 9, wherein, The user equipment includes an authenticated DNS client associated with the user's identity, and the method further includes: An authenticated channel is established by the authenticated DNS client connecting the authenticated DNS client and the DNS server, the authenticated channel indicating the identity of the user associated with the user equipment; and The strategy for identifying the user associated with accessing the service is at least in part based on the authenticated channel.

13. The communication method according to any one of claims 7 to 9, wherein: The direct access path is configured to send content associated with the service from the service provider to the user device; and The proxy access path is configured as follows: The content is sent from the service provider to the inspection agent; The content is inspected by the inspection agent; and The content is sent from the inspection agent to the user device.

14. A communication method, comprising: At the Domain Name Service (DNS) server associated with the enterprise network and from the user equipment, the first data indicates the identity of the user associated with the user equipment; At the DNS server and from the user equipment, a first request is received for resolving the address of a service associated with the service provider; The DNS server identifies a policy associated with the user accessing the service, based at least in part on the user's identity, and the policy instructs the user equipment to be configured for a proxy access path to the service; The DNS server provides the user equipment with an indication of the address of the inspection agent associated with the enterprise network; At the service provider and from the user equipment, a second request is received for a direct access path from the user equipment to the service provider; At the identity provider of the enterprise network and from the user equipment, request data is received, the request data indicating a third request to authenticate the user's identity to access the direct access path; The policy is received from the identity provider, at least in part, based on authenticating the user's identity. The identity provider determines that the policy indicates the proxy access path and the request data indicates the direct access path; as well as At least in part, based on the determination that the policy indicates the proxy access path and the request data indicates the direct access path, the user equipment is denied access to the direct access path from the user equipment to the service provider.

15. The communication method according to claim 14, wherein, It also includes sending second data from the identity provider to the user device, configured to redirect the user device to a customized webpage.

16. The communication method according to claim 15, wherein, The customized webpage includes instructions for the user to install the required DNS client.

17. The communication method according to claim 15, wherein: The DNS server is configured as a personalized DNS server; as well as The customized webpage includes instructions for the user to reconfigure the DNS server from the personalized DNS server to the enterprise DNS server.

18. The communication method according to any one of claims 15 to 17, wherein The strategy indicates the direct access path; The request data indicates the proxy access path; and The customized webpage includes instructions for users to access direct access paths.

19. The communication method according to claim 18, further comprising: The identity provider determines that the policy indicates the direct access path and the request data indicates the proxy access path; as well as At least in part, based on determining that the policy indicates the direct access path and the request data indicates the proxy access path, access to the proxy access path from the user equipment to the service provider is provided to the user equipment.

20. The communication method according to any one of claims 14 to 17, wherein: The direct access path is configured to send content associated with the service from the service provider to the user device; and The proxy access path is configured as follows: The content is sent from the service provider to the inspection agent; The content is inspected by the inspection agent; and The content is sent from the inspection agent to the user device.

21. A communication apparatus comprising a module for implementing the steps of the communication method according to any one of claims 1 to 20.

22. A computer program, computer program product, or computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the communication method according to any one of claims 1 to 20.

Images