Identity broker that provides access control and single sign-on

Abstract

Techniques for providing secure access to cloud-based services are disclosed. In various embodiments, a request is received from a client app on a device to connect to a security proxy associated with the cloud-based service. A secure tunnel connection is used between the device and a node with which the security proxy is associated to establish the requested connection to the security proxy. Information associated with the secure tunnel is used to determine that the requesting client app is authorized to access the cloud-based service from the device and to obtain a security token from an identity provider associated with the cloud-based service, the security token to be used by the client app to authenticate to the cloud-based service.

Description

[0001] This application is a divisional application. The name of the invention of the parent case is “Identity agent providing access control and single sign-on”. The application date is January 26, 2016, and the application number is 201680012311.7.

[0002] Cross-references to other applications

[0003] This application claims priority to U.S. Provisional Patent Application No. 62 / 107,927, filed on January 26, 2015, entitled IDENTITY PROXY TO PROVIDE MOBILE APP ACCESS CONTROL AND SINGLE SIGN ON, which is incorporated herein by reference for all purposes. Background Art

[0004] Increasingly, mobile devices are incorporating security protections and technologies into the operating system. In many types of devices, applications are "sandboxed" and cannot be attacked by other apps on the device. This also means that each application typically performs authentication and authorization processes in its own sandbox. For example, applications typically cannot share sessions or tokens that would allow one application to authenticate and allow other applications to use the same session / token to get single sign-on.

[0005] Security Assertion Markup Language (SAML) is an XML standard that allows user authentication and authorization data to be exchanged. Using SAML, an online service provider (SP) can contact a separate online identity provider (IDP) to authenticate a user who is trying to access a secure resource. In mobile devices, for example, SAML or other standards and / or protocols can be used to authenticate mobile app users to associated online services. However, some apps may not support certain protocols / standards, and / or may not support certain techniques, such as redirection to a separate IDP.

[0006] Using basic authentication may not be desirable, for example, to prevent a user's enterprise credentials (such as an enterprise username and password) from being exposed on the mobile device and / or to a cloud-based service provider (SP). BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Various embodiments of the invention are disclosed in the following detailed description and accompanying drawings.

[0008] Figure 1A is a block diagram illustrating an embodiment of a system that provides secure mobile access to cloud-based services.

[0009] Figure 2is a flow diagram illustrating an embodiment of a process for providing secure mobile access to cloud-based services.

[0010] Figure 3 is a flow diagram illustrating an embodiment of a process for providing secure mobile access to cloud-based services.

[0011] Figure 1B is a block diagram illustrating an embodiment of a system that provides secure mobile access to cloud-based services.

[0012] Figure 4 is a flow diagram illustrating an embodiment of a process for establishing a secure tunnel and requesting a connection on behalf of a mobile client app.

[0013] Figure 5 is a flow diagram illustrating an embodiment of a process for monitoring and controlling access to cloud-based services based on device security posture.

[0014] Figure 6 is a flow diagram illustrating an embodiment of a process for providing secure mobile access to cloud-based services.

[0015] Figure 7 is a flow diagram illustrating an embodiment of a process for providing secure mobile single sign-on access to cloud-based services.

[0016] Figure 8 is a flow diagram illustrating an embodiment of a process for monitoring and controlling access to cloud-based services based on device security posture.

[0017] Fig. 9 is a flow diagram illustrating an embodiment of a process for providing secure mobile access to cloud-based services.

[0018] Fig.10 is a block diagram illustrating an embodiment of a system for providing secure access to cloud-based services via a delegated identity provider architecture and model.

[0019] Fig.11A and 11B is an illustration of providing secure access to services in various embodiments Fig.10 A sequence diagram showing an example of a sequence of calls between entities. DETAILED DESCRIPTION

[0020] The present invention may be implemented in many ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as: a processor configured to execute instructions stored on and / or provided by a memory, the memory being coupled to the processor. In this specification, these implementations or any other form that the present invention may take may be referred to as techniques. In general, the order of the steps of the disclosed processes may be changed within the scope of the present invention. Unless otherwise stated, a component such as a processor or memory described as being configured to perform a task may be implemented as: a general component that is temporarily configured to perform a task at a given time; or a specific component that is manufactured to perform a task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data (such as computer program instructions).

[0021] A detailed description of one or more embodiments of the present invention is provided below together with the accompanying drawings that illustrate the principles of the present invention. The present invention is described in conjunction with such embodiments, but the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention encompasses many alternatives, modifications and equivalents. Many specific details are set forth in the following description in order to provide a thorough understanding of the present invention. These details are provided for illustrative purposes, and the present invention can be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical materials known in the art related to the present invention are not described in detail so that the present invention is not unnecessarily obscured.

[0022] A secure identity proxy for accessing secure resources for use with modern operating systems, including, but not limited to, mobile apps running on mobile operating systems, is disclosed. In various embodiments, the identity proxy may be used to access secure resources from a mobile device, such as a mobile app (e.g., an app running on an iOS® or Android® operating system and / or device), or in other contexts where applications may be sandboxed or otherwise isolated from one another by an operating system (e.g., Microsoft Windows® 10). In various embodiments, the identity proxy may be configured and / or used to perform one or more of the following:

[0023] Secure access control for mobile app users, incorporating dynamic information such as the security posture of the mobile device and whether the app is managed, without exposing credentials to the service provider;

[0024] Single sign-on for multiple mobile device apps (e.g., a collection of managed apps associated with an enterprise or other entity).

[0025] In various embodiments, a security agent can be provided. The security agent can include a tunnel server, and the managed mobile device can be configured (e.g., configured by a tunnel plug-in or other tunnel client) to connect to the tunnel server via a secure tunnel. The establishment of the tunnel can be based at least in part on a security certificate received from a tunnel client or another trusted client on a mobile device. The device identity can be determined based on the certificate, and the device security posture information (e.g., under management, compromised, lost / stolen, etc.) can be used to determine whether a secure tunnel will be established. Once trust has been established, a TCP or other connection from a mobile client app for accessing cloud-based services to an identity provider (IdP) agent can be established and used to obtain a SAML assertion (or other security token or information) for the client app to use to access cloud-based services. In some embodiments, if the security posture or other information of the app, device, user, etc. changes, the previously established access to cloud-based services may be cut off. In some embodiments, single sign-on is provided by enabling a secure tunnel and associated trust of a mobile device, once established, to be used by other client apps on the mobile device to obtain SAML assertions or other tokens via an IdP proxy to access corresponding cloud-based services associated with such other client apps.

[0026] In some embodiments, the security proxy may include a delegated identity provider (delegated IdP). Trust may be established between a service provider and an identity provider proxy (IdP proxy) including a security proxy. In various embodiments, a service provider proxy may be included and used to provide secure access when access is requested directly from an identity provider (IdP) (e.g., via IdP-initiated authentication).

[0027] Figure 1A1 is a block diagram illustrating an embodiment of a system for providing secure mobile access to cloud-based services. In the example shown, a mobile device 102 includes a mobile device management agent 104. The mobile device management (MDM) agent 104 may include one or both of a native MDM client and / or functionality of the mobile operating system (e.g., iOS, Android) of the mobile device 102 and a third-party MDM client, agent, and / or app (e.g., one provided by a third-party mobility management provider (such as Mobile Iron, Inc.)). The mobile device 102 has installed thereon a mobile app 106 configured to access a cloud-based service 108. Examples of cloud-based services 108 include, but are not limited to, cloud-based productivity suites (such as Microsoft® Office 365) and customer relationship management (CRM) and other business applications (such as SAP® and salesforce.com®). In various embodiments, the cloud-based service may be accessed by one or more of the following: a native client application (e.g., a mail application); a third-party client app associated with the cloud-based service, such as one provided by the service; and a third-party client app that is not provided by the service but can be used and / or configured to access the service.

[0028] exist Figure 1A In the example shown in , the tunnel plug-in 110 has been installed on the mobile device 102. In various embodiments, the tunnel plug-in 110 can be configured to establish a secure tunnel 112 to a tunnel server 114 running on a security proxy server or other server system 116. In some embodiments, a user of the mobile device 102 can register the device, for example, via an enterprise mobility management (EMM) server 118. The EMM server 118 can be configured to configure the mobile device 102 to be managed by the EMM server 118 and associated elements (such as the security agent 116). The EMM server 118 can be configured to establish MDM control of the mobile device 118 via the MDM agent 104 (such as by having the associated MDM agent 104 installed on the device and / or by configuring the native MDM functionality of the mobile device 102). In various embodiments, the client app 106 can be placed under the management of the EMM server 118 and / or the MDM agent 104. For example, a configuration profile or other configuration data may be provided to ensure that connection requests and / or other traffic associated with the client app 106 are sent via and / or under the supervision of the tunnel plugin 110 .

[0029] In various embodiments, tunnel plug-in 110 may be configured to selectively direct traffic associated with client app 106. For example, tunnel plug-in 110 may be configured to forward traffic addressed by client app 106 to cloud-based service 108 directly to cloud-based service 108, but to send traffic addressed to a node associated with security proxy server 116 via tunnel 112. In some embodiments, client app 106 may address all traffic to service 108, and a mobile or other operating system (e.g., Android®, Microsoft Windows® 10) may be configured (e.g., by a mobile device management server or other MDM authority) to send selected app traffic directly to service 108 and only send other traffic from the same app via a tunnel (such as tunnel 112).

[0030] In various embodiments, the secure tunnel 112 can be established based at least in part on a certificate provided to the tunnel plugin 110 (eg, a certificate provided to the tunnel plugin 110 by the EMM server 118 ).

[0031] exist Figure 1A In the example shown in , the security proxy 116 includes an identity provider (IdP) proxy 120 that is configured to have a "chained IdP" or other trust relationship 122 with a "real" identity provider (IdP) 124 that is associated with the cloud-based service 108 via a trust relationship 126. In some embodiments, the cloud-based service 108 can be configured to trust (e.g., based on previously exchanged certificates, etc.) the real IdP 124, but redirect connection requests received at the cloud-based service 108 to the IdP proxy 120 to perform authentication, as described below in conjunction with Figure 1B as more fully described.

[0032] Figure 1B 1 is a block diagram illustrating an embodiment of a system for providing secure mobile access to cloud-based services. In the example shown, the client app 106 sends a request to establish a connection 128 to the cloud-based service 108 via the tunnel plug-in 110. In various embodiments, the mobile device 102 can be configured (e.g., by the MDM agent 104 and / or native MDM functionality of the mobile device 102) to send connection requests and / or other communications associated with the client app 106 via the tunnel plug-in 110. In various embodiments, the cloud-based service 108 can be configured to redirect connection requests from clients that have not yet been authenticated (such as the client app 106) to an authentication node. In some embodiments, the Security Access Markup Language (SAML) standard can be used.

[0033] In the example shown, the cloud-based service 108 can be configured to redirect the connection request to a URL associated with the IdP proxy 120. Upon being redirected, the client app 106 can send a request to establish a connection 130 to the IdP proxy 120 to perform authentication required to gain access to the cloud-based service 108. In various embodiments, the tunnel plugin 110 can be configured to identify the connection request as being associated with the IdP proxy 120 (e.g., based on the URL), and can be configured to only send connection requests and / or other traffic directed to the IdP proxy 120 via a secure tunnel, such as the tunnel 112. In some embodiments, if the tunnel 112 has not yet been established, the tunnel plugin 110 can be configured to establish a secure tunnel in response to the connection request, and once the tunnel has been established, send the connection request via the tunnel.

[0034] In various embodiments, the certificate or other security credentials and / or information provided to the tunnel plug-in 110 can be used by the tunnel plug-in 110 to establish a secure tunnel 112. The certificate or other information can be used by the tunnel server 114, the IdP agent 120, and / or other components to authenticate the user and / or the mobile device 102. In some embodiments, certificate-based authentication enables authentication to be performed without requiring the user's enterprise credentials (e.g., username and password) to be entered at the mobile device 102 or otherwise stored on the mobile device 102 and / or disclosed to the cloud-based service 108. In some embodiments, the certificate presented by the tunnel plug-in 110 to establish the secure tunnel 112 can be used at the security proxy server 116 to authenticate the user and the mobile device 102. User and / or device information can be associated with the certificate at the security proxy server 116. The security proxy server 116 can have a trust relationship and direct or indirect (e.g., via another server) connection to an enterprise directory (such as Microsoft® Active Directory®), and can be configured to obtain user information (e.g., roles, zones, groups, or partitions, etc.) from the directory.

[0035] exist Figure 1BIn the example shown in , the tunnel server 114 and / or the IdP agent 120 have allowed the establishment of a connection 130 between the client app 106 and the IdP agent 120 via the secure tunnel 112. In some embodiments, the device security posture and / or other posture information of the mobile device 102 can be checked before the secure tunnel 112 and / or the connection 130 are allowed to be established. For example, a compliance check can be performed by querying the EMM server 118 to ensure that the mobile device 102 complies and / or remains compliant. The EMM server 118 can be configured to receive information from the mobile device 102 (e.g., via the MDM agent 104) and make security or other device compliance posture determinations based thereon. For example, if the mobile device 102 and / or one or more apps that were previously under management are no longer under management, or the mobile device 102 has been "jailbroken" or root access has been obtained or otherwise compromised, or if an unauthorized app has been installed, etc., the EMM server 118 can determine that the mobile device 102 is no longer compliant. In various embodiments, one or more of the tunnel plugin 110 , the tunnel server 114 , the IdP proxy 120 , and / or other components may be configured to perform compliance checking with respect to the mobile device 102 .

[0036] In some embodiments, one or more of the tunnel server 114, the IdP proxy 120, and / or the IdP 124 may be included in the EMM server 118. In some embodiments, the IdP proxy 120 may be omitted, for example, if the EMM server 118 is on-premises and / or the IdP 124 is included in the EMM server 118. In some embodiments, at least a limited number of tunnel servers 114 may be included in the EMM server 118. A tunnel client, such as the tunnel plugin 110, may be configured to perform mobile device compliance verification by communicating directly with the EMM server 118.

[0037] In some embodiments, the tunnel plugin 110 can support and provide advanced split tunneling capabilities. For example, in some embodiments, the tunnel plugin 110 can be configured to select which tunnel server it needs from among multiple tunnel servers for various destinations in addition to sending traffic directly to the service provider or other destinations. For example, in an embodiment where the IdP proxy 120 is included in the EMM server 118, the IdP proxy traffic can be sent to the EMM server 118, while traffic destined for a cloud-based service provider can be sent directly to the service.

[0038] In various embodiments, ongoing compliance monitoring is performed after the tunnel 112 and / or connection 130 is established. If a previously compliant mobile device 102 is determined to have ceased to be compliant, a responsive action may be taken, such as severing one or more of the connection 130, the tunnel 112, and the communication from the client app 106 directly to the cloud-based service 108. In various embodiments, ongoing compliance may be monitored, and / or access control may be enforced by one or both of the tunnel server and the tunnel plug-in. For example, the tunnel plug-in may enforce local policies, such as "loss of contact with the EMM server for more than a specified number of hours." In some embodiments, split tunneling may be used, and policies may be enforced on a per-app and / or per-tunnel basis.

[0039] In various embodiments, connection 130 may be used by client app 106 to obtain a SAML assertion or other security token from IdP proxy 120 for use by client app 106 to authenticate itself to cloud-based service 108. IdP proxy 120 may be configured to obtain a security token from IdP 124 on behalf of client app 106 that is signed by IdP 124 and thus trusted by cloud-based service 108. Once authenticated, service-related traffic between client app 106 and cloud-based service 108 may be sent via connection 128 in some embodiments.

[0040] In various embodiments, a single sign-on functionality may be provided. The tunnel plugin 110 may be configured to use an existing secure tunnel, such as tunnel 112, that was established to enable a first client app, such as client app 106, to connect to the IdP proxy 120, in order to subsequently enable a second (or another) client app (not shown) to connect to the IdP proxy 120 via the same tunnel 112. Trust between the mobile device 102 and the security proxy server 116 will have been established in conjunction with establishing the tunnel 112, and in some embodiments, the user and / or device information obtained and cached in conjunction with authentication and providing a security token to the client app 106 may be used to obtain and provide a security token to the second (or other subsequent) client app for use by the second (or other subsequent) app to authenticate itself and obtain access to the cloud-based services with which the second (or other subsequent) app is associated.

[0041] Figure 2 is a flow chart illustrating an embodiment of a process for providing secure mobile access to cloud-based services. In various embodiments, Figure 2 The process can be performed by a tunnel plugin or other tunnel client (such as Figure 1A and 1BIn the example shown, a connection request is received from a client app associated with a cloud-based service (202). If the connection request no The tunnel plugin or other entity is configured to only communicate through secure tunnels such as Figure 1A and 1B If, instead, the connection request is determined to be associated with a destination to be connected to only via a secure tunnel (such as, for example, in Figure 1A and 1B In the example shown in , a connection request to the IdP proxy 120 is sent (204), a secure tunnel to the destination is established (208) (in some embodiments, unless it already exists), and the connection request is sent to the destination via the secure tunnel (210). If the connection is successfully established (212), the process ends. If not (212), a suitable error message is returned, such as "Authentication failed" (214), after which the process ends.

[0042] Figure 3 is a flow chart illustrating an embodiment of a process for providing secure mobile access to cloud-based services. In various embodiments, Figure 3 The process may be performed by a tunnel server or other server-side component such as Figure 1A and 1B In the example shown, a request is received from a mobile device to establish a secure tunnel and connect to an IdP proxy (302). The security (or other compliance) posture of the mobile device is verified (304). For example, the security (or other compliance) posture of the mobile device may be verified based at least in part on a request from an EMM server (such as a server configured to manage the mobile device) to establish a secure tunnel and connect to an IdP proxy (302). Figure 1A and 1B The EMM server 118) provides information to perform compliance verification. If the mobile device is determined to be No If the mobile device is determined to be secure (or otherwise compliant) (306), the request to establish a tunnel and / or connect to the IdP proxy is denied (308). If the mobile device is determined to be secure (or otherwise compliant) (306), the tunnel and requested connection to the IdP proxy is established (310).

[0043] Figure 4 is a flow chart illustrating an embodiment of a process for establishing a secure tunnel and requesting a connection on behalf of a mobile client app. In various embodiments, Figure 4 The process can be used to perform Figure 3 Step 310 of the process and may be performed by a tunnel server or other server-side component such as Figure 1A and1B In the example shown, terminating (ie, establishing) a secure tunnel, such as Figure 1A and 1B The traffic to be sent to the IdP proxy is converted into a TCP stream (eg, by a tunnel server such as Figure 1A and 1B The tunnel server 114) converts (404). In some embodiments, a connection other than a TCP connection can be used and step 404 is omitted. A TCP (or other) connection to the IdP proxy is established on behalf of the mobile app and device that requested the connection to the IdP proxy (406) and the TCP (or other) connection is used to send the TCP stream (or other app traffic). The mobile app, user, device and / or certificate information is passed to the IdP proxy via a secure dedicated channel (408). In various embodiments, the information passed to the IdP proxy via the secure dedicated channel can be used by the IdP proxy to authenticate the user / device / app and / or obtain credentials from a "real" IdP associated with the cloud-based service, which is to be used by the requesting mobile client app to access the cloud-based service.

[0044] Figure 5 is a flow chart illustrating an embodiment of a process for monitoring and controlling access to cloud-based services based on device security posture. In various embodiments, Figure 5 The process can be performed by a mobile device management agent, a tunnel plug-in, a tunnel server, and an identity provider (IdP) agent (such as Figure 1A and 1B In the example shown, mobile device security (or other compliance) posture information is monitored to ensure continued compliance (502). If the mobile device and / or mobile app is determined to have become non-compliant (504), further access to the cloud-based service is blocked (506). Otherwise, monitoring continues until completed (508), for example, the mobile device is no longer connected to the access to which is implemented by the implementation. Figure 5 Any cloud-based service managed by the process node.

[0045] Figure 6 is a flow chart illustrating an embodiment of a process for providing secure mobile access to cloud-based services. In various embodiments, Figure 6 The process can be brokered by an identity provider (IdP) such as Figure 1A and 1BIn the example shown, a TCP connection is accepted from a mobile client app (602). For example, in Figure 1B In the example shown in , the IdP proxy 120 can accept the establishment of the TCP connection 130. Use the mobile device, app, user and / or certificate information received from the tunnel server (or other node) via the secure dedicated channel to authenticate one or more of the requesting app, mobile device and / or user (604). If access to the cloud-based service to which access has been requested is determined to be not yet If the access is determined to be authorized (606), a response is returned indicating that authentication has failed (608). If access is determined to be authorized (606), a SAML assertion is generated and sent to an identity provider (IdP) associated with the cloud-based service (such as Figure 1A and 1B ) (610). A SAML assertion is received from an IdP associated with a cloud-based service to be provided to a requesting client app to authenticate to the service (612). The SAML assertion received from the IdP is provided to a client app that has requested access to the service (614) for use by the client app in order to authenticate to the cloud-based service.

[0046] Although the above examples and other examples described herein refer to the use of SAML assertions, in various embodiments, other security tokens and / or credentials may be used and / or provided to enable the mobile client app to communicate with the client based at least in part on establishing a secure tunnel (such as Figure 1A and 1B tunnel 112) and between the mobile device and the management node (such as Figure 1A and 1B The trust established between the security proxy server system 116) to authenticate to the cloud-based service.

[0047] Figure 7 is a flow chart illustrating an embodiment of a process for providing secure mobile single sign-on access to cloud-based services. In various embodiments, Figure 7 The process can be performed by a tunnel plugin or other tunnel client (such as Figure 1A and 1B Tunnel plug-in 110) and / or tunnel server or other server-side components (such as Figure 1A and 1B In the example shown, a request to establish a connection to an IdP proxy is received (702), for example, in a tunnel plugin (such as Figure 1A and 1BA determination is made as to whether a secure tunnel to a destination associated with the IdP has already been established (704). If so, the existing tunnel is used to establish a connection to the IdP on behalf of the requesting mobile client app (706). If not (704), a tunnel is established as described above and used to establish the requested connection to the IdP proxy.

[0048] In various embodiments, if one mobile app has authenticated to its associated cloud-based service as described herein, a subsequent app can authenticate to its corresponding associated service using the same secure tunnel and associated trust that was established to service the first mobile app's connection request for a connection to the IdP proxy. In various embodiments, a security token (e.g., cookie, SAML assertion) cached and / or regenerated at a security proxy server can be used to allow a subsequent app to authenticate to its corresponding cloud-based service. In various embodiments, one or more of user, mobile device, app, and certificate information can be cached at a security proxy server (e.g., at / by a tunnel server, IdP proxy, or another entity) and can be used to obtain a security token to be used by a second or other subsequently requesting mobile app on the same device to authenticate to its corresponding cloud-based service.

[0049] Figure 8 is a flow chart illustrating an embodiment of a process for monitoring and controlling access to cloud-based services based on device security posture. In various embodiments, Figure 8 The process can be performed by a mobile device management agent, a tunnel plug-in, a tunnel server, and an identity provider (IdP) agent (such as Figure 1A and 1B In the example shown, updated mobile device security, policy, and / or other compliance information is received (802). For example, the tunnel plug-in, and one or more of the MDM agent, and the security proxy server may receive updated information about the mobile device from an EMM server or other node that monitors the mobile device for compliance. One or more conditional access control rules may be applied, where applicable, to determine and take any response actions that may be necessary. For example, one or more rules may be stored in a security proxy server (such as Figure 1A and 1BEach rule may indicate one or more criteria that, if met, require one or more response actions defined in the rule to be taken. For example, a rule may indicate that if a mobile device is determined to have been jailbroken and / or rooted, access to cloud-based and / or enterprise premises-based services is to be cut off. Another rule may indicate that if the device is taken outside of a certain geographic area (e.g., a geo-fence, a native country, a home area, a corporate campus, or none of these), access may be downgraded or regulated in a manner that lacks blocking access (e.g., by limiting access to certain services and / or resources in the house or based in the cloud, limiting functions such as downloading, forwarding, posting, etc.).

[0050] In various embodiments, a rule-based approach enables policies to be easily changed by updating rule sets and allows more granular controls to be defined and exercised over mobile devices and apps installed thereon.

[0051] Fig. 9 is a flow chart illustrating an embodiment of a process for providing secure mobile access to cloud-based services. In various embodiments, Fig. 9 The process can be brokered by an identity provider (IdP) such as Figure 1A and 1B In various embodiments, Fig. 9 The process can be used to manage access to cloud-based or other services differently depending on the nature of the device and / or application used to access the service. In the example shown, the IdP proxy is directly (i.e., not as Figure 1BIn various embodiments, the connection request may be received from a browser or other application (via a tunnel or tunnel server as in the example shown in FIG. 9 ) rather than via a secure tunnel. In various embodiments, the connection request may be received from a communicating browser, an unmanaged application, or a managed application rather than via a secure tunnel. If the browser or other requesting application is determined to be associated with a mobile device in contrast to a desktop browser or other desktop software (904), a challenge is sent to request the provision of a certificate in order to authenticate the user and / or device (906). In some embodiments, a response other than a challenge to present a certificate may be sent. For example, a determination may be made based on an IP address (e.g., a whitelisted IP address range, etc.) and / or other dynamically determined information related to whether a connection should be allowed. If a certificate is not provided and / or is determined to be not valid (or in some embodiments, is determined to be associated with a device that is not currently in a secure or otherwise compliant posture), or in some alternative embodiments, if other criteria for accepting the connection (e.g., within a whitelisted IP address range and / or other configured and / or configurable acceptance criteria), access is denied (910). If a valid certificate is present (908), or if the browser is determined to be a desktop (i.e., non-mobile) browser (and / or other acceptance criteria have been determined to have been met) (904), the request is processed normally (912), such as by passing the request (e.g., proxying the connection) to a "real" IdP associated with the service. In some embodiments, even if a valid certificate has been presented (908), conditional access rules may be applied to determine whether to allow or block the request, e.g., based on the user agent (e.g., the brand or version of the browser or other software being used, the source IP address, etc.).

[0052] In the example shown, the system and environment 1000 includes one or more user agents, which are represented by user agent 1002 in Fig.101004 (e.g., Box.com™, Dropbox™, or salesforce.com®) provided by a service provider 1004. The user agent 1002 is associated with an identity provider 1006, which is, for example, an on-premises, cloud-based, or other identity provider, such as the PingOne™ service supplied by Ping Identity Corporation™. In the example shown, a trust relationship has been established between the service provider 1004 and the identity provider agent 1008 running on the security proxy server 1010. For example, the service provider 1004 and the identity provider agent 1008 may have exchanged certificates. Similarly, a trust relationship has been established between the identity provider 1006 and the service provider agent 1012 (e.g., via the exchange of certificates).

[0053] In combination with Fig.11A and 11B In some embodiments described more fully, the identity provider proxy 1008 and the service provider proxy 1012 have a trust relationship established between them, and each has been configured to re-sign assertions on behalf of the other. For example, in various embodiments, the identity provider proxy 1008 is configured to provide (e.g., for further presentation to and consumption by the identity provider 1006) assertions signed by the identity provider proxy 1008 on behalf of (i.e., act as and appear as) the service provider proxy 1012 to the service provider 1004 and / or the user agent 1002. Similarly, in various embodiments, the service provider proxy 1012 is configured to provide (e.g., for further presentation to and consumption by the service provider 1004) assertions signed by the service provider proxy 1012 on behalf of (i.e., act as and appear as) the identity provider proxy 1008 to the identity provider 1006 and / or the user agent 1002.

[0054] In various embodiments, the user agent 1002 may initiate access to services provided by the service provider 1004 by first contacting the service provider 1004 or by first authenticating with the identity provider 1006 and then accessing the services provided by the service provider 1004. For example, the user agent 1002 may send a request to access a service to the service provider 1004. If the service provider 1004 determines that there is no existing (i.e., previously authenticated) session with the user agent 1002, the service provider 1004 may be configured to redirect the user agent 1002 to the identity provider proxy 1008, which in turn may redirect the user agent 1002 to the identity provider 1006 via a communication signed by the identity provider proxy 1008 using a certificate associated with the service provider proxy 1012. The identity provider 1006 may challenge the user agent 1002 for credentials and upon successful login may provide a first (SAML or other) assertion to the user agent 1002 for presentation to the service provider proxy 1012, which may be configured to provide the user agent 1002 with a second (SAML or other) assertion signed by the service provider proxy 1012 using a certificate associated with the identity provider proxy 1008, for presentation to the service provider 1004 in order to gain access to a service (or other resource).

[0055] In various embodiments, identity provider initiated authentication may be performed by a user agent 1002 for access and login via the identity provider 1006 prior to attempting to access services associated with the service provider 1004. Upon successful login, the identity provider 1006 may provide, via a graphical or other user interface presented at the user agent 1002, for example a web page, list, or other representation of one or more services accessible to the authenticated user. Selection of a service associated with the service provider 1004 may result in the identity provider 1006 providing a first (SAML or other) assertion to the user agent 1002 for presentation to the service provider proxy 1012, which may be configured to provide the user agent 1002 with a second (SAML or other) assertion signed by the service provider proxy 1012 using a certificate associated with the identity provider proxy 1008, for presentation to the service provider 1004 in order to obtain access to the service (or other resource).

[0056] Fig.11A and 11B is an illustration of providing secure access to services in various embodiments Fig.10 A sequence diagram showing an example of a sequence of calls between entities represented in FIG. Fig.11A, in the example shown, a request 1102 to access a service is sent from a user agent 1002 to a service provider 1004. The service provider 1004 processes the request (1104) and determines in this example that there is no previously authenticated session. The service provider 1004 redirects the user agent 1002 to the identity provider proxy 1008 via a communication 1106, which includes an authentication request to be presented to the identity provider proxy 1008. The user agent 1002 provides the authentication request to the identity provider proxy 1008 via a hypertext transfer protocol (HTTP) GET request 1108. In various embodiments, the request 1108 may be gated by conditional access control rules enforced, for example, by a tunnel plug-in or other entity on a mobile (or other) device. The identity provider proxy 1008 processes the request (1110), including by generating a second authentication request signed by the identity provider proxy 1008 using a certificate (or other secret data) associated with the service provider proxy 1012. The second authentication request is provided to the user agent 1002 via a redirect communication 1112, which redirects the user agent to the identity provider 1006. The user agent 1002 in turn provides the second authentication request (signed by the identity provider proxy 1008 using a certificate associated with the service provider proxy 1004 so as to appear to have been signed by the service provider proxy 1004) to the identity provider 1006 via a GET request 1114. The identity provider 1006 receives and processes the GET request (1116).

[0057] Now refer to Fig. 11B , in a service provider initiated authentication scenario (such as the above combined Fig.11A ), the processing performed by the identity provider 1006 at 1116 may include: verifying the second authentication request using the service provider proxy signing certificate; and concluding that no existing authenticated identity provider session was found for the user agent 1002. In some embodiments, the processing at 1116 may be performed by the identity provider 1006 in response to an identity provider initiated authentication request (e.g., from the user agent 1002).

[0058] Further references Fig. 11B , in the authentication initiated by the service provider (see Fig.11A) or identity provider initiated authentication, the identity provider 1006 sends a challenge for credentials 1118. The user may enter credentials (e.g., username and password) at 1120 and submit them to the identity provider 1006 via a user login response 1122. The identity provider verifies the credentials at 1124 (e.g., using enterprise Active Directory® or other directory information) and generates a first SAML (or other) assertion (as shown as "Assertion1") and an associated identity provider session (e.g., setting cookies for the identity provider domain). The first assertion is provided to the service provider proxy 1012 via HTTP POST communication via the user agent 1002 (1126, 1128). In some embodiments, the communication 1128 may be gated by conditional access rules (e.g., by a tunnel plugin). For example, in some embodiments, if the device is in a compliant posture / state, the communication 1128 may only be posted to the service provider proxy. The service provider proxy 1012 processes the request (1130), e.g., by consuming the first assertion and generating a second assertion signed by the service provider proxy 1012 on behalf of the identity provider proxy 1008 (i.e., using the identity provider proxy 1008's credentials so as to appear to have been issued and / or sent by the identity provider proxy 1008). The second assertion is sent to the user agent 1002 via a POST communication 1132, resulting in the second assertion being presented to the service provider 1004 via a POST communication 1134. The service provider 1004 consumes the second assertion (1136) and generates a service provider session for the user agent 1002 (e.g., sets a cookie or other token, such as OAuth, for the service provider domain), thereby enabling the user agent 1002 to access services or other resources during a service access session 1138.

[0059] In some embodiments, the delegated identity provider architecture and model may be used in environments where mobile or other devices may be under the management of an EMM server or other mobile device management (MDM) entity and / or where all apps or a subset of apps on the managed devices may be managed (or not managed), such as Fig.10 The architecture and model shown in . In some embodiments, MDM compliance or other device posture information can be used to block or limit access to services provided by a service provider.

[0060] In some embodiments, a secure tunnel can be established between a managed mobile or other device and a security proxy server or other server or a node associated with such a security proxy server, where one or both of an identity provider agent (such as identity provider agent 1008) and a service provider agent (such as service provider agent 1012) are present on the security proxy server or other server. As described above, a certificate or other cryptographic data can be presented to establish a secure tunnel. The certificate can be mapped to equipment, users, app, etc., and can be used to determine compliance / situation information. In various embodiments, a secure tunnel can be used to control access to cloud-based services, such as by blocking connections to an identity provider agent and / or a service provider agent.

[0061] In various embodiments, conditional access rules can be defined by the user and implemented by the security proxy server or related nodes, including: in a system where a delegated identity provider proxy architecture is used. Conditional access rules can be applied based on contextual information, such as: whether the device and / or user agent (e.g., a mobile app making a request) is managed; the type, provider and version of the user agent software (e.g., browser, type of browser, etc.); IP address (e.g., whitelisted IP address range); whether the connection is initiated via an identity provider or a service provider; the type of operating system and / or platform; etc.

[0062] In various embodiments, the technology disclosed herein can enable secure access to cloud-based services. Single sign-on and device security posture (and / or other information) can be used to provide, manage, and / or control access to cloud-based services by users of mobile devices without exposing enterprise user credentials, such as usernames and passwords, stored or entered on the mobile device and / or at the cloud-based service.

[0063] Although the above embodiments have been described in some detail for the purpose of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways to implement the invention. The disclosed embodiments are illustrative rather than restrictive.

Claims

1. A method for providing secure mobile access to a cloud-based service, comprising: receiving a request for a client application on a device to connect to a security proxy associated with the cloud-based service, wherein the security proxy is remote from the cloud-based service; establishing a secure tunnel between the device and the security agent; determining, based on information associated with the device, that a requesting client application is authorized to access the cloud-based service from the device; obtaining a security token trusted by the cloud-based service; providing the security token to the client application, wherein the security token is used by the client application to access the cloud-based service; monitoring a compliance posture associated with the device to ensure the device remains compliant; as well as Access to the cloud-based service is blocked based at least in part on the indication that a compliance posture of the device has changed. 2 . The method of claim 1 , wherein the information associated with the device comprises a security posture associated with the device. 3 . The method of claim 2 , wherein a security posture associated with the device indicates that the device is compliant.

4. The method of claim 1, wherein the request is sent by the client application in response to a redirect message received from the cloud-based service.

5. The method of claim 4, wherein the redirect message includes a uniform resource locator (URL) or other locator associated with the security proxy.

6. The method of claim 1, wherein establishing a secure tunnel between the device and the security agent comprises: A security credential is received from the device.

7. The method of claim 6, further comprising: The security credentials are utilized to determine one or more of device, application, user, and / or credential information.

8. The method of claim 6, further comprising: Information associated with the security certificate is utilized to determine that a requesting client application is authorized to access the cloud-based service.

9. The method of claim 1, wherein the security agent uses information associated with the device to determine that a requesting client application is authorized to access the cloud-based service from the device at least in part by performing a compliance check on the device.

10. The method of claim 1, wherein the security agent comprises: An identity provider proxy is configured to have a chained identity provider or other trust-based relationship with an identity provider associated with the cloud-based service.

11. The method of claim 1, wherein the security token comprises a Security Assertion Markup Language (SAML) assertion.

12. The method of claim 1, wherein the security token is cached and allows one or more other client applications on the device to be authenticated to one or more corresponding cloud-based services using the secure tunnel.

13. The method of claim 1, wherein the security proxy comprises a delegated identity provider.

14. The method of claim 1, wherein the security proxy comprises a service provider proxy.

15. The method of claim 14, wherein the service provider proxy signs the security token as and on behalf of an identity provider proxy associated with the cloud-based service.

16. A system for providing secure mobile access to a cloud-based service, comprising: Memory; as well as a processor coupled to the processor, wherein the processor: receiving a request for a client application on a device to connect to a security proxy associated with the cloud-based service, wherein the security proxy is remote from the cloud-based service; establishing a secure tunnel between the device and the security agent; determining, based on information associated with the device, that a requesting client application is authorized to access the cloud-based service from the device; obtaining a security token trusted by the cloud-based service; providing the security token to the client application, wherein the security token is used by the client application to access the cloud-based service; monitoring a compliance posture associated with the device to ensure the device remains compliant; as well as Access to the cloud-based service is blocked based at least in part on the indication that a compliance posture of the device has changed.

17. The system of claim 16, wherein the request is sent by the client application in response to a redirect message received from the cloud-based service.

18. A computer program product for providing secure mobile access to cloud-based services, the computer program product embodied in a non-transitory computer-readable storage medium and comprising computer instructions for performing the following operations: receiving a request for a client application on a device to connect to a security proxy associated with the cloud-based service, wherein the security proxy is remote from the cloud-based service; establishing a secure tunnel between the device and the security agent; determining, based on information associated with the device, that a requesting client application is authorized to access the cloud-based service from the device; obtaining a security token trusted by the cloud-based service; providing the security token to the client application, wherein the security token is used by the client application to access the cloud-based service; monitoring a compliance posture associated with the device to ensure the device remains compliant; as well as Access to the cloud-based service is blocked based at least in part on the indication that a compliance posture of the device has changed.

Images