Patent Description:
Accordingly, there are provided methods and computer devices as defined in the claims.

Often times the identity of a computing device used in an authentication procedure is either not available to an identity provider or not reliable. The identity provider, during authentication of a user, typically evaluates location data derived from the IP address associated with the incoming request. However, location data derived from the IP address does not necessarily represent the actual location of the user. This allows an attacker to use a virtual private network (VPN), for example, to disguise their location. Furthermore, the identity provider may evaluate the user agent string of a HTTP header sent in a HTTPS session, but the user agent can also be spoofed by a malicious actor. Moreover, if a software package (e.g., a browser extension) is used to provide device data to the identity provider during authentication, a user is required to install the software package on potentially every browser of his/her computing device, and the device data that is sent to the identity provider using such a software package is limited.

This disclosure describes, in part, techniques and systems for enabling an identity provider to identify a computing device during authentication of a user of the computing device, and to do so in a manner that is independent of a browser and/or a client application and/or an operating system (OS) on the computing device. The techniques and systems described herein leverage a security agent executing on the computing device in combination with the capability of certain authentication protocols to redirect the authentication request to a second identity provider in order to retrieve and provide data about the computing device to a first identity provider during an authentication process (e.g., a web authentication process). Because the data about the computing device from which an authentication request originated can have a profound impact on the authentication of a user of the computing device, this data about the computing device enables the first identity provider to evaluate a security risk of the requested access with improved accuracy, as compared to existing technologies, and/or to apply one or more policies to the authentication request based on the security risk. Such policies may include, for example, triggering a multifactor authentication (MFA) procedure.

In an illustrative example, a user of a computing device may attempt to access a resource by opening a browser and entering a uniform resource locator (URL) of a service provider, or by opening a client application (e.g., an electronic mail (email) client) on the computing device. The resource can be a local resource that is stored on the computing device, or the resource can be a remote resource stored on an external system (e.g., a cloud application stored on a remote server). The act of the user requesting access to the resource may trigger an authentication process, which may involve the browser or the client application causing the computing device to send an authentication request (e.g., a web request) to a first identity provider.

In response to the computing device sending the authentication request to the first identity provider, the computing device may receive, from the first identity provider, redirection data to redirect the authentication request to a second identity provider. Upon receiving the redirection data, a security agent executing on the computing device may intercept the authentication request, retrieve data about the computing device (e.g., an identifier of the computing device), and send the authentication request with the device data (e.g., the identifier of the computing device) to the second identity provider. In this example, the computing device may receive, from the second identity provider, a signed response to the authentication request, wherein the signed response is signed with a private key accessible (e.g., exclusively accessible) to the second identity provider, and wherein the signed response includes the device data (e.g., the identifier of the computing device). The computing device may send the signed response to the first identity provider to receive a result of the authentication request from the first identity provider (e.g., receiving an indication that the access to the resource has been granted, denied, etc.).

An example process implemented by the second identity provider in the above example may include receiving an authentication request from a computing device to access a resource, wherein the authentication request was redirected to the second identity provider by a first identity provider, signing a response to the authentication request with a private key accessible (e.g., exclusively accessible) to the second identity provider, and sending the signed response to the computing device.

The techniques and systems described herein - for providing data about a computing device (e.g., an identifier of the computing device) to an identity provider during authentication of a user of the computing device - provide various technical benefits, such as by effecting an improvement upon a particular technology and/or allowing one or more devices to conserve resources with respect to processing resources, memory resources, networking resources, power resources, etc., in the various ways described herein.

For example, the techniques and systems described herein are independent of a browser and/or a client application and/or an OS of the computing device, whereas existing techniques for providing device data to an identity provider require a user to install a software package (e.g., a browser extension) on potentially every browser of his/her computing device. This means that, using the techniques and systems described herein, a user does not have to install a browser extension on potentially multiple separate browsers. Instead, the techniques and systems described herein leverage a security agent that is already installed, and running, on a computing device, making the techniques and systems described herein agnostic of the browser and/or the client application and/or the OS that may be exchanging data with the first identity provider.

As another example, the techniques and systems described herein strengthen the authentication process. This is, in part, due to enabling the first identity provider to easily obtain the data about the computing device (e.g., an identifier of the computing device), and to take this device data into account as an additional factor before granting the user access to a requested resource.

As another example, the techniques and systems described herein are more secure than existing solutions through tamper-resistance. For example, data about the computing device (e.g., an identifier of the computing device) is signed by the second identity provider using a private key accessible (e.g., exclusively accessible) to the second identity provider, which means that, if an attacker were to compromise the computing device, the attacker still cannot inject data into the signed response that is provided to the first identity provider without tampering with the computing device's security agent, which can have sophisticated anti-tampering mechanisms. These mechanisms are otherwise protected because the attacker cannot fake the signature of the second identity provider or modify claims added by the second identity provider. If an attacker were to compromise the browser and/or the client application of the computing device, the attacker still cannot fake the existence, or otherwise spoof an identifier, of a security agent installed on the computing device; the attacker would need the "secrets" used to create a secure tunneling mechanism between the security agent and the second identity provider to accomplish this type of attack, and the attacker is unable to obtain such "secrets. " Even if an attacker had a copy of a signed response from a previous, authenticated session, the attacker could not effectively use such a copy of the signed response with the techniques and systems described herein, which, in some examples, includes adding a timestamp to the signed response from the second identity provider.

As another example, the techniques and systems described herein enable the first identity provider to use the direct trust relationship with the second identity provider in order to obtain information about the computing device's identity. In existing solutions that use browser extensions on user computing devices to provide an identity provider with device data, there is a greater risk of an attacker compromising the computing device by stealing the device data. By contrast, using the techniques and systems described herein, data about the computing device (e.g., an identifier of the computing device) is provided to the first identity provider in a signed response that was signed with a private key, wherein the private key is part of the trust relationship between the second identity provider and the first identity provider.

<FIG> illustrates an example environment <NUM> showing an example computing device <NUM>, an example service provider <NUM>, an example first identity provider <NUM>, and an example second identity provider <NUM>. As illustrated in <FIG>, the computing device <NUM> may interact with the service provider <NUM>, the first identity provider <NUM>, and/or the second identity provider <NUM> over a network(s) <NUM>. In some examples, the network(s) <NUM> may include any one or more networks, such as wired networks, wireless networks, and combinations of wired and wireless networks. Further, the network(s) <NUM> may include any one or combination of multiple different types of public or private networks (e.g., cable networks, the Internet, cellular networks, etc.). In some instances, at least the computing device <NUM>, the first identity provider <NUM>, and/or the second identity provider <NUM> are configured to communicate over the network <NUM> using a secure protocol or networking technology including, without limitation, Security Assertion Markup Language (SAML), OAuth, OpenID Connect, Web Services Federation (WS-Federation, or WS-Fed), PingFederate, Active Directory Federation Services (ADFS), HTTPS, and/or any other protocol or set of protocols or network technology, such as transmission control protocol/Internet protocol (TCP/IP). As will be described in further detail below, the security agent <NUM> and the second identity provider <NUM>, in some examples, may establish a secure tunneling mechanism <NUM> to communicate with each other.

In various examples, the computing device <NUM> and one or more devices of the service provider <NUM>, the first identity provider <NUM>, and/or the second identity provider <NUM> may each be or include a server or server farm, multiple, distributed server farms, a mainframe, a work station, a personal computer (PC), a laptop computer, a tablet computer, a personal digital assistant (PDA), a cellular phone, a media center, an embedded system, or any other sort of device or devices. In one implementation, the device(s) of the second identity provider <NUM> represent a plurality of computing devices working in communication with each other, such as a cloud computing network of nodes. When implemented on multiple computing devices, the second identity provider <NUM> may distribute its modules, components, and/or data among the multiple computing devices of the second identity provider <NUM>. In some implementations, one or more of the computing device <NUM>, the service provider <NUM>, the first identity provider <NUM>, and/or the second identity provider <NUM> represents one or more virtual machines implemented on one or more computing devices.

The second identity provider <NUM> is sometimes referred to herein as an "external identity provider" <NUM> with respect to the first identity provider <NUM>. In some examples, the second identity provider <NUM> is implemented as a cloud of security service devices, and may be referred to herein as a "remote security service" <NUM> or a "security service cloud" <NUM>. It is to be appreciated that the second identity provider <NUM> may be configured to provide a security service to a large number of computing devices, such as the computing device <NUM>. <FIG> shows a single computing device <NUM> merely for illustrative purposes, when in fact, the environment <NUM> can include many more computing devices like the computing device <NUM>, each being configured to interact with the second identity provider <NUM>. By way of example and not limitation, the second identity provider <NUM> may interact with many thousands of computing devices <NUM>.

Each computing device, such as the computing device <NUM> (sometimes referred to herein as a "device" <NUM>, "workstation" <NUM>, "machine" <NUM>, "host machine" <NUM>, or "user device" <NUM>), may implement a security agent <NUM>, which is a security software program that executes on the computing device <NUM>. The security agent <NUM> (sometimes referred to herein as an "agent" <NUM>, "security software" <NUM>, "sensor" <NUM>, or "endpoint" <NUM>) may execute in the kernel mode of the computing device <NUM>, in some examples. During execution, the security agent <NUM> observes events, determines actions to take based on those events, and/or sends the events to the second identity provider <NUM> for further processing and analysis. In some examples, the security agent <NUM> of the computing device <NUM> may be configured with security features and functionality for detecting malware on the computing device <NUM>. Accordingly, the second identity provider <NUM> may manage a fleet of security agents, such as the security agent <NUM>, on a fleet of computing devices, such as the computing device <NUM>, and the second identity provider <NUM> may assign a unique identifier to each installed security agent <NUM>.

As shown in <FIG>, the computing device <NUM> may include, among other components, one or more processors <NUM>, memory <NUM>, and one or more network interfaces <NUM>. The memory <NUM> may store, among other things, one or more browsers <NUM> (e.g., Google Chrome®, Microsoft Edge®, Mozilla Firefox®, Safari®, etc.), one or more client applications <NUM> (e.g., an email client, such as Microsoft Outlook®, Gmail®, etc.), an operating system (OS) <NUM>, as well as the aforementioned security agent <NUM>. The memory <NUM> may also store various types of data <NUM>, at least some of which may be usable by the security agent <NUM>, the browser(s) <NUM>, the client application(s) <NUM>, and/or the OS <NUM>.

<FIG> also shows that the second identity provider <NUM> may include, among other components, one or more processors <NUM>, memory <NUM>, and one or more network interfaces <NUM>. The memory <NUM> may store, among other things, an authentication component <NUM> to implement the techniques described herein, as well as various types of data <NUM>, at least some of which may be usable by the authentication component <NUM>.

The processors <NUM>, <NUM> may be or include any sort of processing unit, such as a central processing unit (CPU) or a graphic processing unit (GPU). The network interfaces <NUM>, <NUM> configure the associated computing device to communicate with other computing devices in the environment <NUM> over the network(s) <NUM>. The network interfaces <NUM>, <NUM> may send and receive communications and/or data through one or both of the network <NUM> or other networks using any suitable protocol. The network interfaces <NUM>, <NUM> may also support both wired and wireless connection to various networks.

The memories <NUM>, <NUM> may store an array of modules and data, and may include volatile and/or nonvolatile memory, removable and/or non-removable media, and the like, which may be implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Such memory includes, but is not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disc ROM (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, redundant array of independent disks (RAID) storage systems, or any other non-transitory computer-readable medium which can be used to store the desired information and which can be accessed by a computing device.

In some instances, the computing device <NUM> and/or the second identity provider <NUM> may have components, features, and/or functionality in addition to those illustrated in <FIG>. Moreover, although not shown in <FIG>, the first identity provider <NUM> and/or the service provider <NUM> may have similar components, features, and/or functionality to those of the second identity provider <NUM> illustrated in <FIG>. In addition, some or all of the components, features, and/or functionality described as residing within any single device may reside remotely from that device, in some implementations.

The service provider <NUM> may represent any suitable type of service provider, such as an email service provider, an enterprise application service provider, or the like. Examples of service providers <NUM> include, without limitation, Office <NUM>®, Salesforce®, or any other type of service provider <NUM> that maintains resources <NUM> (e.g., applications, virtual machines (VMs), etc.). A user of the computing device <NUM> may desire to access a resource(s) <NUM> of the service provider <NUM>, and the service provider <NUM> may rely on the first identity provider <NUM> to manage identity information of requesting users and offer user authentication as a service.

The first identity providers <NUM> may be any suitable entity (e.g., a company, organization, etc.) and/or service providing entity thereof, including enterprise solutions, such as Okta, OneLogin, Azure Active Directory (Azure AD), etc. Accordingly, when a user of the computing device <NUM> logs into the service provider <NUM>, the service provider <NUM> may redirect the incoming request to the first identity provider <NUM>. In an illustrative example, a user of the computing device <NUM> may open the browser <NUM> and enter a URL associated with the service provider <NUM>, which causes a request to access a resource(s) <NUM> of the service provider <NUM> to be sent from the computing device <NUM> to the service provider <NUM> along path <NUM>. Alternatively, the user of the computing device <NUM> may open the client application <NUM> associated with the service provider <NUM>, which causes a request to access a resource(s) <NUM> of the service provider <NUM> to be sent from the computing device <NUM> to the service provider <NUM> along path <NUM>. The request transmitted along path <NUM> to the service provider <NUM> may trigger an authentication process, whereby the request is redirected to the first identity provider <NUM> as an authentication request sent from the computing device <NUM>, via the browser <NUM> or the client application <NUM>, to the first identity provider <NUM> along path <NUM>. In some examples, the user may enter credentials (e.g., a username, a password, etc.) and/or the computing device <NUM> may provide a token to the first identity provider <NUM>. In some examples, the authentication request sent to the first identity provider <NUM> along path <NUM> may include a user identity associated with the user of the computing device <NUM>, an IP address associated with the computing device <NUM>, a user agent, or the like.

In response to receiving the authentication request along path <NUM>, the first identity provider <NUM> may redirect the authentication request to the second authentication provider <NUM>. An example reason for redirecting the authentication request to the second authentication provider <NUM> is to allow the first identity provider <NUM> to obtain data about the computing device <NUM> (e.g., an identifier of the computing device <NUM>) from which the authentication request originated. In some examples, the first identity provider <NUM> may send, to the computing device <NUM> along path <NUM>, redirection data to redirect the authentication request to the second identity provider <NUM>. In some examples, the redirection data sent to the computing device <NUM> along path <NUM> may include a URL managed by the second identity provider <NUM>. In other words, the redirection of the authentication request to the second identity provider <NUM> can be in the form of a URL, such as "endpointID. externalidentityprovider. com," which is a fictitious example of a URL that might be managed by the second identity provider <NUM>.

Consider an example where the computing device <NUM> does not have a security agent <NUM> installed thereon. In such an example, the browser <NUM> or the client application <NUM> is configured to navigate directly to the second identity provider <NUM> based at least in part on the redirection data (e.g., URL) received from the first identity provider <NUM> via path <NUM>. It is worth noting that, in this example - where the computing device <NUM> does not have a security agent <NUM> installed thereon, the secure tunneling mechanism <NUM> between the computing device <NUM> and the second identity provider <NUM> is not established (e.g., does not exist). Nevertheless, the second identity provider <NUM> can still receive the redirected authentication request from the computing device <NUM>, and, upon receiving the authentication request from the computing device <NUM>, the second identity provider <NUM> may determine that the computing device <NUM> does not have a security agent <NUM> installed thereon. This determination can be made based on the second identity provider <NUM> receiving the authentication request without an identifier of a security agent <NUM>, in one example. The second identity provider <NUM> may return a signed response to the computing device <NUM> indicating that a security agent <NUM> is not installed on the computing device <NUM>. This indication may be in the form of a message specifying that the second identity provider <NUM> "does not know this machine," or any similar message indicating that a security agent <NUM> is not installed on the computing device <NUM>. The computing device <NUM>, upon receiving such a signed response from the second identity provider <NUM>, may forward the signed response, via the browser <NUM> or the client application <NUM>, to the first identity provider <NUM> along path <NUM>. In this example, the first identity provider <NUM>, upon receiving the signed response from the computing device <NUM> along path <NUM>, determines that there is no security agent <NUM> installed on the computing device <NUM>, and the first identity provider <NUM> can take this absence of a security agent <NUM> into account for determining a result of the authentication request. For example, the first identity provider <NUM> may deny access to the requested resource(s) <NUM> in part because the computing device <NUM> does not have a security agent <NUM> installed, and, in this scenario, the first identity provider <NUM> may provide an indication of the same to the computing device <NUM> along path <NUM>. Alternatively, the lack of a security agent <NUM> on the computing device <NUM> may trigger a MFA procedure, in which case the user of the computing device <NUM> may be prompted for an additional factor (e.g., the user may be prompted to enter a code sent to the user out-of-band via Short Message Service (SMS) text).

In contrast to the above-described example, the example of <FIG> shows the computing device <NUM> as having a security agent <NUM> installed thereon. In this example, the computing device <NUM> may still receive redirection data from the first identity provider <NUM> along path <NUM>, such as a URL (e.g., "endpointID. externalidentityprovider. com") managed by the second identity provider <NUM>. However, in response to the browser <NUM> or the client application <NUM> receiving the redirection data from the first identity provider <NUM>, the browser <NUM> or the client application <NUM> may be served locally on the computing device <NUM>. For example, if a URL is received from the first identity provider <NUM> along path <NUM>, the URL may, due to the presence of the security agent <NUM> on the computing device <NUM>, resolve to a localhost associated with the computing device <NUM> such that the URL is served locally on the computing device <NUM>. For example, the redirection may, in some cases, be made by using generic mechanisms, such as host file or domain name system (DNS) traffic redirection. This allows the security agent <NUM> to intercept the authentication request. Accordingly, the security agent <NUM> may intercept the authentication request, and may retrieve data about the computing device <NUM> after intercepting the authentication request. In some examples, the data about the computing device <NUM> retrieved by the security agent <NUM> includes an identifier of the computing device <NUM>. In some examples, the identifier of the computing device <NUM> is an identifier of the security agent <NUM>. In other words, the second identity provider <NUM> may use the unique identifier assigned to the security agent <NUM> installed on the computing device <NUM> as an identifier of the computing device <NUM> for purposes of implementing the techniques described herein. In some examples, the data about the computing device <NUM> retrieved by the security agent <NUM> includes additional data about the computing device <NUM> (e.g., data about the hardware, software, and/or firmware of the computing device <NUM>), including data indicating, without limitation, a version of an OS <NUM> of the computing device <NUM>, a compatibility of the computing device <NUM>, a policy level of the security agent <NUM>, user information about a user of the computing device <NUM>, a strength of a password associated with the user, a location associated with the authentication request, proxy information associated with the authentication request, whether a security feature is enabled on the computing device <NUM>, and/or whether the computing device <NUM> has been involved in a security incident.

A version of the OS <NUM> may be indicative of whether the computing device <NUM> is up-to-date or outdated. Linux, for example, is a member of the family of UNIX OS's, and may be run on a variety of computer platforms, including personal computers with an x86 processor. Linux is a free, open-ended implementation of UNIX, and source code for a Linux kernel is available to the public, and is continuously being improved and otherwise modified. As improvements and/or other alterations to the Linux kernel are made and generally adopted by the public, new Linux versions are released. Regardless of the type of OS <NUM>, two OS versions (e.g., kernel versions) may be different in various ways. For example, one version of an OS <NUM> may have additional modules that are not in another version. As another example, modules of respective OS versions may perform the same task(s) but in different ways. These and/or other differences may cause the existence of multiple OS versions.

A compatibility of the computing device <NUM> may indicate the computing device's <NUM> ability to accept input from a newer version of itself (e.g., by ignoring unknown tags and references that the newer version will have). In some examples, a compatibility of the computing device <NUM> may include the hardware compatibility (e.g., the compatibility of the computer hardware components with a particular CPU architecture, bus, motherboard, or OS <NUM>). In some examples, a compatibility of the computing device <NUM> may include software compatibility (e.g., the ability of certain software that runs on other models of a family of computer models to be run on the particular model of the computing device <NUM>).

A policy level of the security agent <NUM> may be indicative of the security agent's <NUM> approach to malware. In some examples, the policy level can represent the security configuration and/or security settings of the computing device <NUM>. In an illustrative example, a first policy level of the security agent <NUM> may be to strictly detect malware without taking any action. A second policy level of the security agent <NUM> may be to detect and report malware to the second identity provider <NUM>. A third policy level of the security agent <NUM> may be to detect, report, and/or automatically block the detected malware.

User information about a user of the computing device <NUM> may include an Active Directory group membership, for example.

A strength of a password associated with the user of the computing device may be measured by any suitable metric, such as a number of different types of characters (e.g., letters of the alphabet, symbols, numbers, etc.), a length of the password, a randomness of the password, or the like.

A location associated with the authentication request may represent a location from which the authentication request originated. In some examples, the location can be any suitable type of location information, such as Global Positioning System (GPS) coordinates, a civic address, or any other suitable type of location information.

Proxy information associated with the authentication request may include any suitable proxy information, such as an IP address used as a proxy for a location.

A security feature of the computing device <NUM> that may be enabled or disabled may include features such as secure boot, or other features to "harden" the computing device <NUM> against malware attacks. Security incidents may include detections of malware on the computing device <NUM>, detections of attempts of attackers to compromise the computing device <NUM>, or the like.

It is worth noting that, in the example of <FIG>, the security agent <NUM> may be granted permissions that are sufficient for retrieving the data about the computing device <NUM> from the computing device <NUM>, yet the security agent <NUM> may be unable to serve the authentication request by itself (e.g., without the assistance of the second identity provider <NUM>). This is at least because the authentication request may be encrypted and protected, such as by Transport Layer Security (TLS), and the security agent <NUM> is not configured to decrypt the authentication request, and having the private key used to by the second identity provider <NUM> accessible to the computing device <NUM> (e.g., stored on the computing device <NUM>) may provide an opportunity for an attacker to steal the private key and impersonate the second identity provider <NUM>, potentially allowing the attacker to gain access to the requested resource(s) illicitly. Thus, making the private key used by the second identity provider <NUM> inaccessible to the security agent <NUM>, and to the computing device <NUM> generally, may provide improved security. In other words, the second identity provider <NUM> may have exclusive access to the private key that is used to sign a response to the first identity provider <NUM>, which may be due to the second identity provider <NUM> being a trusted entity who can sign response (or the data contained in the response).

After intercepting the authentication request and retrieving the data about the computing device <NUM> (e.g., from the data <NUM>), the security agent <NUM> may act as a proxy between the browser <NUM> or the client application <NUM> and the second identity provider <NUM>. Based on the preexisting trust relationship between the security agent <NUM> and the second identity provider <NUM>, the secure tunneling mechanism <NUM> depicted in <FIG> may be established (or created) to exchange data between the security agent <NUM> and the second identity provider <NUM>, in some examples. In these examples, the security agent <NUM> may send the authentication request with the retrieved data about the computing device <NUM> (e.g., the identifier of the computing device <NUM>) to the second identity provider <NUM> using (e.g., inside) the secure tunneling mechanism <NUM>. Alternatively, the computing device <NUM> may send the authentication request with the retrieved data about the computing device <NUM> (e.g., the identifier of the computing device <NUM>) to the second identity provider <NUM> using an unencrypted part of a TCP session, or by opening an independent channel. These example techniques allow for sending the authentication request (with the retrieved data about the computing device <NUM>) to the second identity provider <NUM> without having to decrypt and encrypt the authentication request.

The second identity provider <NUM>, upon receiving, from the computing device <NUM>, the authentication request with the data about the computing device <NUM> may, in some examples, validate the data about the computing device <NUM>. For example, the second identity provider <NUM> may confirm that the identifier of the computing device <NUM> received via the secure tunneling mechanism <NUM> is one of a plurality of identifiers associated with security agents that have been installed on computing devices <NUM>. The second identity provider <NUM> may sign a response to the authentication request with a private key accessible (e.g., exclusively accessible) to the second identity provider <NUM>. Signing the response, as used herein may include signing the response and/or the data contained in the response. For example, the response signed by the second identity provider <NUM> may include the data about the computing device <NUM> (e.g., the identifier of the computing device <NUM>) that was retrieved by the security agent <NUM>, and the second identity provider <NUM> may sign the response (e.g., by signing the identifier of the computing device <NUM> contained in the response). In some examples, the second identity provider <NUM> may retrieve additional data about the computing device <NUM> (e.g., data about the hardware, software, and/or firmware of the computing device <NUM>) that was not retrieved by the security agent <NUM> and include the additional data in the signed response. Such additional data retrieved by the second identity provider <NUM> may indicate, without limitation, a version of an OS <NUM> of the computing device <NUM>, a compatibility of the computing device <NUM>, a policy level of the security agent <NUM>, user information about a user of the computing device <NUM>, a strength of a password associated with the user, a location associated with the authentication request, proxy information associated with the authentication request, whether a security feature is enabled on the computing device <NUM>, and/or whether the computing device <NUM> has been involved in a security incident. The second identity provider <NUM> may have such data <NUM> available in the memory <NUM> due to past interactions between the second identity provider <NUM> and the security agent <NUM> of the computing device <NUM>.

The second identity provider <NUM> may send, to the computing device <NUM> (e.g., using the secure tunneling mechanism <NUM>), the signed response including the data about the computing device <NUM> (e.g., the identifier of the computing device <NUM>). Including the identifier of the computing device <NUM> (e.g., an identifier of the security agent <NUM>) in the signed response may indicate that a known security agent <NUM> is installed on the computing device <NUM>. This could be in the form of a message specifying that the second identity provider <NUM> "knows this machine," or any similar message. The computing device <NUM>, upon receiving such a signed response from the second identity provider <NUM>, may forward the signed response, via the browser <NUM> or the client application <NUM>, to the first identity provider <NUM> along path <NUM>. In this example, the first identity provider <NUM>, upon receiving the signed response from the computing device <NUM> along path <NUM>, may extract the data (e.g., the identifier of the computing device <NUM>) from the signed response, and the first identity provider <NUM> can take this extracted data about the computing device <NUM> into account in determining a result of the authentication request. For example, the first identity provider <NUM> may grant access to the requested resource(s) <NUM> in part because the computing device <NUM> has a security agent <NUM> installed thereon, and the first identity provider <NUM> may provide an indication of the same to the computing device <NUM> along path <NUM>. In some examples, the result of the authentication request is determined by the first identity provider <NUM> applying one or more policies. The policy(ies) applied by the first identity provider <NUM> may be based on the data contained, or not contained, in a signed response received from the computing device <NUM> via path <NUM> (and possibly based on additional data received directly from the second identity provider <NUM> via path <NUM>). Example policies applied by the first identity provider <NUM> include, without limitation, granting access to the requested resource(s) <NUM>, denying access to the requested resource(s) <NUM>, triggering a MFA procedure (e.g., a MFA prompt) that prompts the user for an additional factor, and/or indicating a risk level associated with the request to the service provider <NUM> to cause the service provider <NUM> to restrict access to at least some of its resources <NUM> based on the risk level, such as by denying access to the requested resource(s) <NUM> while granting access to another resource(s) <NUM> that is perhaps less sensitive than the requested resource(s) <NUM>. These types of policies may be communicated back to the computing device <NUM> as indications of a result of the authentication request.

As mentioned above, in some instances, the computing device <NUM>, the first identity provider <NUM>, and/or the second identity provider <NUM> are configured to utilize any suitable federation service(s), such as, without limitation, PingFederate, ADFS, and/or any other federation service. Additionally, or alternatively, in some examples, the computing device <NUM>, the first identity provider <NUM>, and/or the second identity provider <NUM> are configured to communicate over the network(s) <NUM> using a secure protocol or networking technology including, without limitation, SAML, OAuth, OpenID Connect, WS-Fed, HTTPS, and/or any other protocol or set of protocols or network technology, such as the TCP/IP. In examples where SAML protocol is used, the authentication request may be sent by the computing device <NUM> (e.g., with data about the computing device <NUM>) to the second identity provider <NUM> (e.g., via the secure tunneling mechanism <NUM>) using SAML protocol, and, in these examples, the second identity provider <NUM> may act as a SAML claims provider. That is, the second identity provider <NUM> may be configured to sign a response to the authentication request by including one or more signed SAML claims in the response sent back to the computing device <NUM> (e.g., via the secure tunneling mechanism <NUM>). For example, the second identity provider <NUM> may embed the identifier of the computing device <NUM> in the response as a signed SAML claim, and may send the response including the signed SAML claim(s) to the computing device <NUM>. It is to be appreciated that, if a computing device <NUM> does not have a security agent <NUM> installed thereon, the signed response received from the second identity provider <NUM> may not include any SAML claims. In general, the use of SAML protocol in the techniques described herein may prevent a malicious "machine-in-the-middle" from tampering with the SAML claim(s) provided in the response from the second identity provider <NUM>. The techniques and systems using SAML, as described herein, may also protect against malware attempting to modify the SAML claim(s) if a computing device <NUM> is compromised, since the SAML claims calculation is not done on the computing device <NUM>, but rather on an independent, remote, second identity provider <NUM>. In some examples, the signed response sent by the second identity provider <NUM> to the computing device <NUM> may include a timestamp indicating a time at which the second identity provider <NUM> signed the response with the private key. This timestamp may prevent an attacker from effectively using a copy of a signed response from a previous, authenticated session, thereby improving the security of the authentication process.

When the browser <NUM> or the client application <NUM> forwards the signed response to the first identity provider <NUM> along path <NUM>, it is to be appreciated that the browser <NUM> or the client application <NUM> does not have visibility into the use of the secure tunneling mechanism <NUM> to exchange data between the computing device <NUM> (e.g., via the security agent <NUM>) and the second identity provider <NUM>. In other words, from the perspective of the browser <NUM> or the client application <NUM>, an authentication request was redirected to the second identity provider <NUM> using a secure protocol (e.g., SAML), and a signed response (e.g., a response with signed SAML claims) was received from the second identity provider <NUM> using the secure protocol. Meanwhile, if the second identity provider <NUM> receives a redirected authentication request from the computing device <NUM> via the secure tunneling mechanism <NUM>, the second identity provider <NUM> can safely assume that the redirected authentication request (and any data about the computing device <NUM> sent therewith) was not sent by the browser <NUM> or the client application <NUM>.

In some examples, as depicted in <FIG>, a "cloud-to-cloud" path <NUM> may allow the first identity provider <NUM> and the second identity provider <NUM> to communicate directly with each other "out-of-band", before, during, and/or after the authentication process with respect to a user of the computing device <NUM>, as described herein. For example, the second identity provider <NUM> may receive, from the first identity provider <NUM>, one or more queries along path <NUM> for additional data about the computing device <NUM> (e.g., data about the hardware, software, and/or firmware of the computing device <NUM>) that was not already retrieved by the security agent <NUM> or by the second identity provider <NUM>. In some examples, the first identity provider <NUM> may send a query to the second identity provider <NUM> using data about the computing device <NUM> (e.g., the identifier of the computing device <NUM>) that the first identity provider <NUM> received "in-band" from the computing device <NUM> along path <NUM>. In response to the query(ies) sent to the second identity provider <NUM> along path <NUM>, the second identity provider <NUM> may send the additional data to the first identity provider <NUM> along path <NUM>. Such additional data may indicate, without limitation, a version of an OS <NUM> of the computing device <NUM>, a compatibility of the computing device <NUM>, a policy level of the security agent <NUM>, user information about a user of the computing device <NUM>, a strength of a password associated with the user, a location associated with the authentication request, proxy information associated with the authentication request, whether a security feature is enabled on the computing device <NUM>, and/or whether the computing device <NUM> has been involved in a security incident. The second identity provider <NUM> may have such data <NUM> available in the memory <NUM> due to past interactions between the second identity provider <NUM> and the security agent <NUM> of the computing device <NUM>.

The processes described herein are illustrated as logical flow graphs, each operation of which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the processes.

<FIG> illustrates an example process <NUM> to be implemented by a computing device <NUM> for providing data about the computing device <NUM> to a first identity provider <NUM> during authentication of a user of the computing device <NUM>. By way of example, and not limitation, the process <NUM> is described with reference to the previous figures.

At <NUM>, a computing device <NUM> may send, to a first identity provider <NUM>, an authentication request to access a resource <NUM> (e.g., a cloud application). A service provider <NUM> may restrict access to the resource <NUM> to authenticated users, and, as such, the first identity provider <NUM> may handle such user authentication on behalf of the service provider <NUM>. In some examples, the user may have opened a browser <NUM> or a client application <NUM> on the computing device <NUM> and entered a URL associated with the service provider <NUM> in order to access the resource <NUM>, which ultimately caused the authentication request to be send along path <NUM> to the first identity provider <NUM> at block <NUM>.

At <NUM>, the computing device <NUM> may receive, from the first identity provider <NUM>, redirection data to redirect the authentication request to a second identity provider <NUM>. In some examples, the redirection data includes a URL managed by the second identity provider <NUM>.

At <NUM>, a security agent <NUM> executing on the computing device <NUM> may intercept (or capture) the authentication request. In some examples, the intercepting the authentication request at block <NUM> by the security agent <NUM> is based at least in part on the URL included in the redirection data resolving to a localhost associated with the computing device <NUM>, which may be in response to a browser <NUM> of the computing device <NUM> being directed to the URL included in the redirection data.

At <NUM>, the security agent <NUM> may retrieve data about the computing device <NUM>, such as an identifier of the computing device <NUM> and/or additional data besides the identifier. In some examples, the identifier of the computing device <NUM> is an identifier of the security agent <NUM>. In some examples, additional data besides the identifier that is retrieved by the security agent <NUM> at block <NUM> indicates, without limitation, a version of an OS <NUM> of the computing device <NUM>, a compatibility of the computing device <NUM>, a policy level of the security agent <NUM>, user information about a user of the computing device <NUM>, a strength of a password associated with the user, a location associated with the authentication request, proxy information associated with the authentication request, whether a security feature is enabled on the computing device <NUM>, and/or whether the computing device <NUM> has been involved in a security incident.

At <NUM>, the security agent <NUM> of the computing device <NUM> may send the authentication request with the data (e.g., the identifier of the computing device <NUM>) retrieved at block <NUM> to the second identity provider <NUM>. For example, the computing device <NUM> may inject the data retrieved at block <NUM> into the authentication request before sending the authentication request to the second identity provider <NUM> at block <NUM>. In some examples, the sending of the authentication request with the data (e.g., the identifier of the computing device <NUM>) to the second identity provider <NUM> at block <NUM> includes sending the authentication request with the identifier of the computing device <NUM> using a secure tunneling mechanism <NUM> between the security agent <NUM> and the second identity provider <NUM>. In some examples, the authentication request is sent with the data (e.g., the identifier of the computing device <NUM>) to the second identity provider <NUM> using SAML protocol, or another secure protocol.

At <NUM>, the computing device <NUM> may receive, from the second identity provider <NUM>, a signed response to the authentication request, wherein the signed response is signed with a private key accessible to the second identity provider <NUM>, and wherein the signed response includes the data (e.g., the identifier of the computing device <NUM>) retrieved at block <NUM>. In some examples, the receiving the signed response from the second identity provider <NUM> includes receiving the signed response using the secure tunneling mechanism <NUM>. In some examples, the signed response includes additional data about the computing device <NUM> retrieved by the second identity provider <NUM>. In some examples, the signed response includes a signed SAML claim(s). In some examples, the signed response includes a timestamp indicating a time at which the second identity provider <NUM> signed the response with the private key.

At <NUM>, the computing device <NUM> may send the signed response to the first identity provider <NUM>. In some examples the signed response is sent to the first identity provider <NUM> along path <NUM> in <FIG> using SAML protocol, or another secure protocol.

At <NUM>, the computing device <NUM> may receive a result of the authentication request from the first identity provider <NUM>. In some examples, receiving the result of the authentication request from the first identity provider <NUM> at block <NUM> includes at least one of: receiving an indication that access to the resource <NUM> has been granted; receiving an indication that access to the resource <NUM> has been denied; receiving a MFA prompt; and/or receiving an indication that access to the resource <NUM> has been denied, and that access to another resource <NUM> has been granted.

<FIG> illustrates an example process <NUM> to be implemented by a second identity provider <NUM> for providing data about a computing device <NUM> to a first identity provider <NUM> during authentication of a user of the computing device <NUM>. By way of example, and not limitation, the process <NUM> is described with reference to the previous figures.

At <NUM>, a second identity provider <NUM> may receive, from a computing device <NUM>, an authentication request, wherein the authentication request was redirected to the second identity provider <NUM> by a first identity provider <NUM>. In some example, the second identity provider <NUM> may not know which resource(s) <NUM> is/are being requested with the authentication request received at block <NUM>. In other examples, the authentication request received at block <NUM> may be a request to access a particular resource(s) <NUM>, such that the requested resource(s) <NUM> is known to the second identity provider <NUM>.

At <NUM>, the second identity provider <NUM> may sign a response to the authentication request with a private key accessible to the second identity provider <NUM>. In some examples, the signed response includes an indication as to whether a security agent <NUM> managed by the second identity provider <NUM> is or is not installed on the computing device <NUM>.

At <NUM>, the second identity provider <NUM> may send the signed response to the computing device <NUM>. In some examples, SAML protocol, or another secure protocol is used to receive the authentication request at block <NUM> and/or to send the signed response at block <NUM>.

<FIG> illustrates another example process <NUM> to be implemented by a second identity provider <NUM> for providing data about a computing device <NUM> to a first identity provider <NUM> during authentication of a user of the computing device <NUM>. By way of example, and not limitation, the process <NUM> is described with reference to the previous figures.

At <NUM>, a second identity provider <NUM> may receive, from a computing device <NUM>, an authentication request with data about a computing device <NUM> (e.g., an identifier of the computing device <NUM>). In some example, the second identity provider <NUM> may not know which resource(s) <NUM> is/are being requested with the authentication request received at block <NUM>. In other examples, the authentication request received at block <NUM> may be a request to access a particular resource(s) <NUM>, such that the requested resource(s) <NUM> is known to the second identity provider <NUM>. In some examples, the authentication request may have been redirected to the second identity provider <NUM> by a first identity provider <NUM>. In some examples, the authentication request is received at block <NUM> via a security agent <NUM> executing on the computing device <NUM>. In some examples, the receiving of the authentication request at block <NUM> with the identifier of the computing device <NUM> includes receiving the authentication request with the identifier of the computing device <NUM> using a secure tunneling mechanism <NUM> between the security agent <NUM> and the second identity provider <NUM>. In some examples, the identifier of the computing device <NUM> comprises an identifier of the security agent <NUM>.

At <NUM>, the second identity provider <NUM> may validate the data about a computing device <NUM>. For example, the validating at block <NUM> may include validating the identifier of the computing device <NUM> by confirming that the identifier is one of a plurality of identifiers associated with security agents that have been installed on computing devices. Moreover, the confirmation of the security agent may be done by validating the secure channel <NUM> established by the trust relationship between the security agent <NUM> and the second identity provider <NUM>.

At <NUM>, the second identity provider <NUM> may retrieve additional data about the computing device <NUM>, such as additional data that indicates, without limitation, a version of an OS <NUM> of the computing device <NUM>, a compatibility of the computing device <NUM>, a policy level of the security agent <NUM>, user information about a user of the computing device <NUM>, a strength of a password associated with the user, a location associated with the authentication request, proxy information associated with the authentication request, whether a security feature is enabled on the computing device <NUM>, and/or whether the computing device <NUM> has been involved in a security incident.

At <NUM>, the second identity provider <NUM> may sign a response to the authentication request with a private key accessible to the second identity provider <NUM>. The signed response may include the data received with the authentication request at block <NUM>, such as the identifier of the computing device <NUM>, and/or the signed response may include the additional data retrieved by the second identity provider <NUM> at block <NUM>.

At <NUM>, the second identity provider <NUM> may send, to the computing device <NUM>, the signed response. In some examples, the sending of the signed response to the computing device <NUM> at block <NUM> includes sending the signed response using the secure tunneling mechanism <NUM>.

At <NUM>, the second identity provider <NUM> may receive (e.g., directly via path <NUM> of <FIG>) a query from the first identity provider <NUM> for additional data about the computing device <NUM>. In some examples, the additional data indicates, without limitation, a version of an OS <NUM> of the computing device <NUM>, a compatibility of the computing device <NUM>, a policy level of the security agent <NUM>, user information about a user of the computing device <NUM>, a strength of a password associated with the user, a location associated with the authentication request, proxy information associated with the authentication request, whether a security feature is enabled on the computing device <NUM>, and/or whether the computing device <NUM> has been involved in a security incident.

At <NUM>, the second identity provider <NUM> may send the additional data to the first identity provider <NUM>. This allows the first identity provider <NUM> to receive the additional data about the computing device <NUM> "out-of-band" along path <NUM> of <FIG>.

Claim 1:
A method comprising:
sending, by a computing device, an authentication request to a first identity provider (<NUM>);
receiving, by the computing device, from the first identity provider, redirection data to redirect the authentication request to a second identity provider (<NUM>);
when the computing device has a security agent (<NUM>) installed,
intercepting, by a security agent (<NUM>) executing on the computing device (<NUM>), the authentication request;
retrieving, by the security agent, an identifier of the computing device;
sending, by the security agent, the authentication request with the identifier of the computing device to the second identity provider;
receiving, by the computing device, from the second identity provider, a signed response to the authentication request, wherein the signed response includes the identifier of the computing device;
when the computing device does not have a security agent (<NUM>) installed, sending, by the computing device, the authentication request to the second identity provider; receiving, by the computing device, from the second identity provider, a signed response to the authentication request;
sending, by the computing device, the signed response to the first identity provider; and
receiving, by the computing device, a result of the authentication request from the first identity provider;
wherein the signed response includes an indication that a security agent managed by the second identity provider is not installed on the computing device, or,
wherein the authentication request is sent via a security agent executing on the computing device for validating the identifier by confirming at the second identity provider (<NUM>) that the identifier is one of a plurality of identifiers associated with security agents that have been installed on computing devices.