Controlling access to a service provider

Abstract

A method for controlling access of a client (22) to a service provider (24) that trusts an identity provider (30) to authenticate a user of the client includes, using a bridge (28), intermediating between the client and the identity provider such that the identity provider sends an access token, which provides the access to the service provider, to the bridge rather than to the client, and using the bridge, controlling use of the access token, thereby controlling the access of the client to the service provider. Other embodiments are also described.

Description

[0001] CONTROLLING ACCESS TO A SERVICE PROVIDER

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] The present application claims priority to US Provisional Application 63 / 558,667, entitled “Decoupling the identity provider from the web proxy,” fded February 28, 2024, whose disclosure is incorporated herein by reference.

[0004] FIELD OF EMBODIMENTS OF THE INVENTION

[0005] Embodiments of the present invention are related generally to computer security, and particularly to the security of web servers.

[0006] BACKGROUND

[0007] A web proxy is an agent deployed between a client device and a service provider, such as a software as a service application, hosted by a web server. Products and solutions that implement web proxies include CLOUD ACCESS SECURITY BROKERS (CASB)™, SECURE SERVICE EDGE™, application firewalls, and load balancers. One common way to implement a web proxy, especially for CLOUD ACCESS SECURITY BROKERS™, is using a federation protocol such as SECURITY ASSERTION MARKUP LANGUAGE™ or OpenlD CONNECT™.

[0008] Typically, web proxies inspect communication exchanged between the client and the service provider, and if needed, enforce security policies by intervening in the flow of communication. For example, web proxies can perform access management by managing and controlling user access to cloud resources, including enforcing strong passwords and multifactor authentication. Web proxies can also protect data stored in the cloud by encrypting the data and enforcing data loss prevention policies, and / or by preventing access to sites and protocols that are commonly used to exfiltrate data from one network to another. Web proxies can protect against cyber threats such as malware, phishing, and ransomware by scanning for and blocking suspicious activity. Web proxies can apply proactive controls to high-risk applications and user activity to add additional layers of security and preventative controls. As another example, web proxies can enforce step-up authentication or risk-based authentication for accessing web apps or certain types of resources therein. Web proxies can ensure that an organization is compliant with various regulatory standards when using cloud-based services. As a final example, web proxies can create a control layer of visibility into all cloud applications, both sanctioned and unsanctioned, thereby providing a comprehensive picture of cloud activity, and enact security measures accordingly based on risk and policy.

[0009] SUMMARY

[0010] There is provided, in accordance with some embodiments of the present invention, a method for controlling access of a client to a service provider that trusts an identity provider to authenticate a user of the client. The method includes, using a bridge, intermediating between the client and the identity provider such that the identity provider sends an access token, which provides the access to the service provider, to the bridge rather than to the client, and using the bridge, controlling use of the access token, thereby controlling the access of the client to the service provider.

[0011] In some embodiments, intermediating between the client and the identity provider includes intermediating between the client and the identity provider by authenticating to the identity provider instead of the user.

[0012] In some embodiments, intermediating between the client and the identity provider further includes requesting the access in the same session used for authenticating to the identity provider.

[0013] In some embodiments, authenticating to the identity provider includes authenticating to the identity provider using credentials of the user.

[0014] In some embodiments, authenticating to the identity provider includes authenticating to the identity provider using one or more other access tokens that provide access to the identity provider by virtue of the bridge functioning as an external identity provider for the identity provider.

[0015] In some embodiments, intermediating between the client and the identity provider includes intermediating between the client and the identity provider by proxying communication between the client and the identity provider.

[0016] In some embodiments, the method further includes identifying the service provider from the proxying, and intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

[0017] In some embodiments, controlling the use of the access token includes causing the client to access the service provider, using the access token, via a web proxy.

[0018] In some embodiments, controlling the use of the access token further includes proxying at least a beginning of a session between the client and the web proxy, such that the client accesses the web proxy via the bridge.

[0019] In some embodiments, the method further includes using the access token, by the web proxy, to control a session between the client and the service provider.

[0020] In some embodiments, causing the client to access the service provider via the web proxy includes causing the client to access the service provider via the web proxy by encrypting the access token such that the web proxy, but not the service provider, can decrypt the access token.

[0021] In some embodiments, the method further includes, using the web proxy, decrypting the access token.

[0022] In some embodiments, causing the client to access the service provider via the web proxy includes causing the client to access the service provider via the web proxy by redirecting the client to the web proxy with the access token.

[0023] In some embodiments, redirecting the client to the web proxy with the access token includes redirecting the client to the web proxy with the access token by including the access token in a redirection request of the redirection.

[0024] In some embodiments, causing the client to access the service provider via the web proxy includes redirecting the client to the web proxy and sending the access token to the web proxy.

[0025] In some embodiments, sending the access token to the web proxy includes sending the access token to the web proxy via an application programming interface of the web proxy.

[0026] In some embodiments, the bridge and web proxy are implemented as separate software modules on the same server or cloud service, and sending the access token to the web proxy includes sending the access token to the web proxy by communicating the token between the modules.

[0027] In some embodiments, controlling the use of the access token includes: redirecting the client to a web proxy that services the service provider; and using the access token to intermediate between the web proxy and service provider, such that the client accesses the service provider via the web proxy and bridge.

[0028] In some embodiments, controlling the use of the access token includes controlling the use of the access token by implementing one or more security measures prior to allowing use of the access token.

[0029] In some embodiments, the method further includes receiving a redirection of the client from the identity provider, and intermediating between the client and the identity provider includes intermediating between the client and the identity provider by virtue of the redirection.

[0030] In some embodiments, receiving the redirection includes receiving the redirection by virtue of functioning as an external identity provider for the identity provider.

[0031] In some embodiments, receiving the redirection includes receiving the redirection by virtue of providing a custom sign-in form for the identity provider.

[0032] In some embodiments, receiving the redirection includes receiving the redirection by virtue of providing step-up authentication functionality for the identity provider.

[0033] In some embodiments, the method further includes identifying the service provider during the redirection, and intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

[0034] In some embodiments, the method further includes receiving a redirection of the client from a web proxy that services the service provider, and intermediating between the client and the identity provider includes intermediating between the client and the identity provider by virtue of the redirection.

[0035] In some embodiments, the method further includes, using the web proxy, redirecting the client to the bridge such that the bridge receives the redirection.

[0036] In some embodiments, the method further includes identifying the service provider from a redirection request of the redirection, and intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

[0037] In some embodiments, intermediating between the client and the identity provider includes intermediating between the client and the identity provider following an initiation of a session, by the client, with the bridge.

[0038] In some embodiments, the method further includes, prior to intermediating between the client and the identity provider, authenticating the user using the identity provider to validate credentials of the user.

[0039] In some embodiments, the method further includes identifying the service provider via an application programming interface of the identity provider, and intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

[0040] In some embodiments, the method further includes receiving a notification, from the identity provider, identifying the service provider, and intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

[0041] In some embodiments, the method further includes identifying the service provider via an application programming interface of a web proxy servicing the service provider, and intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

[0042] In some embodiments, the method further includes receiving a notification, from a web proxy servicing the service provider, identifying the service provider, and intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

[0043] In some embodiments, the method further includes, using the web proxy, sending the notification to the bridge.

[0044] In some embodiments, the method further includes identifying the service provider via an interface provided, by the bridge, to the user, and intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

[0045] There is further provided, in accordance with some embodiments of the present invention, a computer software product including a tangible non-transitory computer-readable medium in which program instructions are stored. The instructions, when read by at least one processor, cause the processor to control access of a client to a service provider that trusts an identity provider to authenticate a user of the client, by, using a bridge, intermediating between the client and the identity provider such that the identity provider sends an access token, which provides the access to the service provider, to the bridge rather than to the client, and using the bridge, controlling use of the access token, thereby controlling the access of the client to the service provider.

[0046] There is further provided, in accordance with some embodiments of the present invention, a system for controlling access of a client to a service provider that trusts an identity provider to authenticate a user of the client. The system includes a communication interface and a processor configured to intermediate between the client and the identity provider, via the communication interface, using a bridge, such that the identity provider sends an access token, which provides the access to the service provider, to the bridge rather than to the client, and using the bridge, control use of the access token, thereby controlling the access of the client to the service provider.

[0047] The present invention will be more fully understood from the following detailed description of embodiments thereof, taken together with the drawings, in which: BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Fig. 1 is a schematic illustration of a system comprising a bridge for controlling access to a service provider, in accordance with some embodiments of the present invention;

[0049] Fig. 2 is a schematic illustration of exchanges of communication in accordance with some embodiments of the present invention; and

[0050] Fig. 3 and Fig. 4 are diagrams of example flows of communication in accordance with some embodiments of the present invention.

[0051] DETAILED DESCRIPTION

[0052] OVERVIEW

[0053] In a standard deployment of a CASB, the service provider trusts the CASB to authenticate the user, and the CASB trusts a single sign-on solution, which can also be referred to as an identity provider, to authenticate the user. This configuration makes sure that the user cannot authenticate to the service provider without going through the CASB.

[0054] A challenge is that organizations onboarded to a single sign-on solution may already have many service providers trusting the single sign-on solution directly. To fully onboard a CASB, therefore, an organization must separately reconfigure each of its service providers to trust the CASB as its identity provider, which creates an administrative and operational burden while increasing implementation costs. In some cases, this problem leads to the organization not fully deploying or leveraging the full capability of the CASB solution.

[0055] To address this challenge, embodiments of the present invention provide a new agent, referred to herein as a web-proxy bridge or simply as a bridge, that allows a service provider to use a CASB without reconfiguration, even if the service provider already uses a single sign-on solution. In addition, the bridge provides a control layer that monitors user activity, applies riskbased analysis, and when necessary, denies or curtails access based on risk and policy. The bridge can be integrated with the single sign-on solution or the CASB solution, or can be a separate solution. The bridge can be executed on a server deployed in the customer’s environment (e.g., in a local area network to which the user’s device belongs), or delivered as a cloud service.

[0056] In particular, in some embodiments, the bridge acts as a gatekeeper (e.g., a proxy) for the identity provider and requires that access to the service provider be via the CASB. Thus, given that the service provider requires the user to authenticate to the identity provider, the user must authenticate to the bridge, which in turn enforces access to the service provider via the CASB. In other words, any access to the service provider needs to go through the CASB, even without configuring the CASB as an identity provider for the service provider.

[0057] As described in detail below, embodiments of the present invention include techniques for preventing direct access (i.e., access not via the bridge) to the service provider or identity provider, identifying which service provider the user is trying to access, and transitioning from control of the authentication to control of the entire session between the client and the service provider.

[0058] Advantageously, the solutions described herein can be implemented in the initial setup of a CASB or an identity provider, or retrofitted into an existing environment by simple changes to existing identity components, without system reconfiguration for each protected application.

[0059] In addition to a CASB, embodiments described herein are applicable to other types of web proxies, such as those mentioned above in the Background.

[0060] SYSTEM DESCRIPTION

[0061] Reference is initially made to Fig. 1, which is a schematic illustration of a system 20 comprising a bridge 28 for controlling access of a client 22 to a service provider 24, in accordance with some embodiments of the present invention.

[0062] Fig. 1 depicts client 22 attempting to access service provider 24 via a computer network 32, such as the Internet. Service provider 24 is configured to trust identity provider 30 to authenticate the user of client 22. (In the description below, the terms “user” and “client” may be used interchangeably.) For example, in some embodiments, whenever the client attempts to access the service provider directly, the service provider redirects the client to the identity provider for authentication, or alternatively, redirects the client to a web proxy 26 that services the service provider, which in turn redirects the client to the identity provider for authentication. However, as described in detail below, bridge 28 is configured to intermediate between client 22 and identity provider 30, such that the access token for accessing the service provider is sent by the identity provider to the bridge, rather than to the client. By controlling use of the access token, the bridge can control access of the client to service provider 24, despite the service provider not trusting the bridge to authenticate the client.

[0063] For example, the bridge can prevent client 22 from bypassing web proxy 26, i.e., the bridge can cause the client to access the service provider, using the access token, via web proxy 26. For example, the bridge can encrypt the access token such that the web proxy, but not the service provider, can decrypt the access token. In some such embodiments, the bridge redirects the client to the web proxy with the access token or redirects the client to the web proxy and, separately, sends the access token to the web proxy, such that the web proxy can control the session with the service provider. Alternatively, the bridge sends the access token to the web proxy but does not redirect the client to the web proxy immediately, but rather, proxies at least the beginning of the session between the client and the web proxy, such that the client accesses the web proxy via the bridge. As yet another option, the bridge redirects the client to the web proxy but holds on to the access token. The bridge then uses the access token to intermediate between the web proxy and service provider, such that the client accesses the service provider via the web proxy and bridge.

[0064] Alternatively or additionally, the bridge can implement one or more security measures prior to allowing use of the access token by the client or web proxy.

[0065] In some embodiments, the bridge authenticates to the identity provider instead of the user, e.g., using any of the techniques described below in the section entitled “Initial authentication to bridge.” In response, the identity provider communicates with the bridge as if the bridge were the client. Thus, when the bridge subsequently requests access to the service provider (e.g., in the same session used for authenticating to the identity provider), the identity provider sends the access token to the bridge.

[0066] In other embodiments, the bridge proxies communication between the client and the identity provider, thereby obtaining the access token upon the identity provider communicating the access token to the client via the bridge. In some such embodiments, the bridge further identifies the service provider from the proxying, such that the bridge can subsequently request access to the service provider (thereby obtaining the access token) by virtue of having identified the service provider.

[0067] In some embodiments, the identity provider is configured to redirect the client to the bridge in response to the client attempting to access the identity provider directly. By virtue of receiving this redirection (i.e., by virtue of the client connecting to the bridge via the redirection), the bridge can subsequently intermediate between the client and the identity provider. In some such embodiments, the bridge further identifies the service provider during the redirection, such that the bridge can subsequently request access to the service provider by virtue of having identified the service provider. To receive the redirection, the bridge can function as an external identity provider for the identity provider, provide a custom sign-in form for the identity provider, and / or provide step-up authentication functionality for the identity provider by requesting the step-up authentication from the user or simply providing the step-up authentication on behalf of the user, as described below in the section entitled “Configuration of identity provider.”

[0068] Alternatively or additionally, web proxy 26 is configured to redirect the client to the bridge . By virtue of receiving this redirection, the bridge can subsequently intermediate between the client and the identity provider. In some such embodiments, the bridge further identifies the service provider from a redirection request of the redirection, such that the bridge can subsequently request access to the service provider by virtue of having identified the service provider.

[0069] Alternatively or additionally, the bridge is configured to receive a request from the client to initiate a session with the bridge. Following the initiation of the session, the bridge intermediates between the client and the identity provider.

[0070] Typically, prior to intermediating between the client and the identity provider, the bridge authenticates the user by validating credentials of the user or by using the identity provider to validate the user’s credentials.

[0071] As described above, in some embodiments, the bridge identifies the service provider during a redirection from identity provider 30 or web proxy 26. In other embodiments, the bridge identifies the service provider via an application programming interface of the identity provider or web proxy. Alternatively, the bridge receives a notification, from the identity provider or web proxy, identifying the service provider. Subsequently, the bridge can request access to the service provider by virtue of having identified the service provider.

[0072] Typically, the functionality of bridge 28 is implemented in software executed by the processor 34 of at least one server 33, such as a cloud server or a server belonging to the same local area network as client 22. Bridge 28 is referred to as such on account of the bridge intermediating, or bridging, between client 22 and identity provider 30. It is noted that in the context of the present application, including the claims, any reference to an action performed by the bridge (e.g., intermediating communication, controlling use of an access token, or receiving a redirection) may be alternatively phrased as an action performed by processor 34 in the execution of the bridge software.

[0073] In addition to processor 34, which may be embodied as a single processor or as a cooperatively networked or clustered set of processors, server 33 comprises a memory 36, such as a random access memory. Typically, processor 34 comprises a central processing unit and / or a graphics processing unit. Program instructions, including instructions for implementing the functionality of bridge 28, and / or data are loaded into memory 36 for execution and processing by the processor. The program instructions and / or data may be downloaded to the processor in electronic form, over a network, for example. Alternatively or additionally, the program instructions and / or data may be provided and / or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory. Such program instructions and / or data, when provided to the processor, produce a machine or special-purpose computer, configured to perform the tasks described herein.

[0074] Server 33 further comprises a communication interface 38, such as a network interface controller, configured for communication over network 32. Although, for simplicity, bridge 28 is shown directly communicating with other components of system 20 over network 32, this communication actually occurs via communication interface 38.

[0075] Typically, the functionality of each of identity provider 30 and web proxy 26 is also implemented in software executed by processor 34 or by another processor.

[0076] In some embodiments, web proxy 26 is specially configured to perform functionality that facilitates the use of bridge 28. (In some such embodiments, the web proxy and the bridge are implemented on the same server or cloud service.) For example, as described above, in some embodiments, the web proxy is configured to redirect the client to the bridge, decrypt an access token encrypted by the bridge, and / or facilitate identification of service provider 24 by the bridge. In other embodiments, the web proxy is a standard web proxy that is not specially configured.

[0077] Reference is now made to Fig. 2, which is a schematic illustration of exchanges of communication in accordance with some embodiments of the present invention.

[0078] Each double-sided arrow in Fig. 2 represents communication between the two entities at the respective ends of the arrow. As indicated by the solid arrows, communication between client 22 and bridge 28, between bridge 28 and identity provider 30, between client 22 and web proxy 26, and between web proxy 26 and service provider 24 typically (though not necessarily) occurs in embodiments of the present invention. The dashed arrows, on the other hand, indicate communication that is less typical. For example, although in some embodiments, client 22 is allowed to communicate directly with identity provider 30 and / or with service provider 24, in other embodiments, this communication is not allowed (aside from trivial communication, such as the initial opening of a session). For example, in some embodiments, the client is redirected from identity provider 30 to bridge 28 whenever the client attempts a direct session with the identity provider. Alternatively or additionally, the bridge prevents the client from accessing the service provider directly, as described above with reference to Fig. 1.

[0079] The sections below detail various examples of the communication shown in Fig. 2. CONFIGURATION OF IDENTITY PROVIDER

[0080] To facilitate the functionality of bridge 28, identity provider 30 is configured, for the account of client 22 with the identity provider, such that the client cannot obtain access to service provider 24 directly from the identity provider, but rather, only via bridge 28. Examples of ways in which the identity provider can be configured include the following:

[0081] 1. In some embodiments, the identity provider is configured to use the bridge for initial authentication of the user, such that whenever the client attempts to authenticate to the identity provider directly, the client is redirected, by the identity provider, to the bridge. For example: a. In some embodiments, the identity provider is configured to use the bridge as an external identity provider, such that the bridge has control over access to the identity provider. This can be done, for example, using a protocol such as SECURITY ASSERTION MARKUP LANGUAGE™, WEB SERVICES FEDERATION™, OpenlD CONNECT™, or FAST IDENTITY ONLINE™.

[0082] Advantageously, this configuration can apply to any one or more applications including service provider 24, and to any one or more Internet Protocol addresses from which access to the identity provider is requested. Thus, as further described below in the section entitled “Initial authentication to bridge,” notwithstanding this configuration, the bridge can use identity provider to validate the user’s credentials. For example, in some embodiments, the identity provider is configured to use the bridge as an external identity provider for all applications except for the identity provider itself. Alternatively, the identity provider is configured to use the bridge as an external identity provider except for when authentication is attempted from the Internet Protocol address of the bridge. b. Alternatively, the initial authentication to the identity provider is done via a custom sign-in form per which the bridge acts as the server side, such that the bridge must authenticate the user. As in the embodiments described previously, the bridge can use the identity provider to validate the user’s credentials.

[0083] 2. In some embodiments, following the initial authentication of the user, the identity provider is configured to use the bridge for step-up authentication to some or all service providers, including service provider 24. This way, access to these service providers is not authorized by the identity provider before authentication to the bridge is completed. In some such embodiments, the identity provider uses the bridge for step-up authentication also for the initial authentication of the user. In other such embodiments, the initial authentication is performed per option 1 above. It is noted that, typically, the main advantage of this configuration is that this configuration enables redirection of the client from the identity provider to the bridge. The user is not necessarily required to perform step-up authentication every time the user is redirected to the bridge, or even at all. Rather, in some embodiments, the bridge can provide step-up authentication on behalf of the user.

[0084] 3. Alternatively, rather than the first two options above, the identity provider is configured to allow access to some or all service providers, including service provider 24, only from the Internet Protocol address of the bridge. Thus, the bridge acts as the client vis-a-vis the identity provider (e.g., the bridge proxies communication between the actual client and the identity provider) both for the initial authentication and for the subsequent request to access to the service provider, such that the access token for the service provider is always sent to the bridge. In such embodiments, to reach the bridge, the client can be redirected from the web proxy or can initiate a session with the bridge directly.

[0085] INITIATING SESSION WITH IDENTITY PROVIDER OR BRIDGE

[0086] In some cases, to access the service provider, the user initiates a session with the service provider, e.g., by entering the uniform resource locator of the service provider into a web browser running on client 22. The service provider then directs the client to identity provider 30. Alternatively, the user initiates a session with the identity provider directly. Alternatively, in some embodiments, if the user initiates a session with web proxy 26, the web proxy redirects the client to the identity provider.

[0087] In these cases, if this is the user’s first connection to the identity provider, the user authenticates as described below in the section entitled “Initial authentication to identity provider.” After establishing a session with the identity provider, the user may select the service provider from the portal of the identity provider, unless the user reached the identity provider via the service provider, in which case the service provider is already known. Subsequently, if the identity provider is configured to use the bridge for step-up authentication for service provider 24, the user is redirected to the bridge, and the session proceeds as described below in the section entitled “Initial authentication to bridge.”

[0088] In other cases, the user initiates a session with the bridge. Subsequently, the user authenticates to the bridge as described below in the section entitled “Initial authentication to bridge.” Alternatively, if such authentication was already performed, the session proceeds as described below in the section entitled “Obtaining identifier of service provider.” Alternatively, in some embodiments, if the user initiates a session with web proxy 26, the web proxy directs the client to the bridge. Subsequently, if initial authentication is required, the session proceeds as described in “Initial authentication to bridge.”

[0089] For embodiments in which the session is initiated with the web proxy, after a successful initial authentication to the identity provider or bridge, or if the initial authentication was already performed, the user selects the service provider via the web proxy, e.g., via a portal on the web proxy that shows a predefined list of service providers, or by entering the uniform resource locator of the service provider. Subsequently, the web proxy informs the bridge of the selected service provider, as described in the section entitled “Obtaining identifier of service provider.” Alternatively, a session with the service provider is initiated as described in the section entitled “Initiating session with service provider,” and the access token is obtained later.

[0090] INITIAL AUTHENTICATION TO IDENTITY PROVIDER

[0091] The initial authentication to the identity provider may proceed in various ways, depending on the way in which the identity provider is configured, this configuration being described above in the section entitled “Configuration of identity provider.”

[0092] In particular, for embodiments in which the identity provider is configured to use the bridge as an external identity provider, the user is redirected to the bridge. For embodiments in which the identity provider is configured for initial authentication via a custom sign-in form, the user is redirected to the sign-in form from a uniform resource locator assigned to the bridge. In both of these cases, the authentication proceeds as described below in the section entitled “Initial authentication to bridge.”

[0093] On the other hand, for embodiments in which the identity provider is not configured to use the bridge for the initial authentication of the user, the user performs the initial authentication directly with the identity provider. For example, the user can enter a username and password, or use a password-less form of authentication.

[0094] INITIAL AUTHENTICATION TO BRIDGE

[0095] In some embodiments, the user authenticates directly to the bridge, and the bridge validates the user’s credentials. This can be done with regular password authentication or other forms of authentication such as password-less authentication or multi-factor authentication.

[0096] In other embodiments, the bridge collects the credentials of the user to authenticate the user against identity provider 30, another identity provider, or a directory that holds information about the user’s identity.

[0097] Subsequently, the bridge starts a new session with the identity provider or uses a session it previously opened with the identity provider. The bridge then authenticates itself to the identity provider, e.g., on behalf of the user. For example: a. In some embodiments, the bridge uses the user’s credentials to authenticate to the identity provider.

[0098] As noted above in the section entitled “Configuration of identity provider,” in some embodiments, the identity provider is configured to use the bridge for the initial authentication. In such embodiments, to avoid an infinite loop, an exception to this configuration is made for authentication attempts from the bridge itself. For example, as noted above, in some embodiments, the identity provider is configured to use the bridge as an external identity provider except for when authentication is attempted from the Internet Protocol address of the bridge. b. Alternatively, for some embodiments in which the identity provider is configured to use the bridge as an external identity provider, the bridge generates one or more access tokens that provide access to the identity provider. In other words, given that the identity provider trusts the bridge as an external identity provider, the bridge can approve access for any user. Thus, for example, the bridge may generate for itself, in accordance with any suitable protocol (e.g., SECURITY ASSERTION MARKUP LANGUAGE™ or OpenlD CONNECT™), a request with the user identifier of the user. Being the identity provider and having the relevant keys, the bridge may approve the request and generate a valid response to the request, the response including the access tokens that provide access to the identity provider. The bridge may then send the response to the identity provider, which will accept the response and approve access. Since the response includes the identifier of the user, the bridge will be authenticated to the identity provider as the user, and may thus continue the session with the identity provider operating on behalf of the user. c. Alternatively, if the identity provider supports user impersonation, the bridge uses its own credentials to impersonate the user. d. Alternatively, the bridge authenticates to the identity provider using its own credentials, without impersonating the user. In other words, the bridge has its own account with the identity provider, which the bridge uses to authenticate to the identity provider rather than using an account of the user.

[0099] Alternatively, the bridge proxies the session between the user and the identity provider, such that all authentication exchanges between the user and the identity provider pass through the bridge. After authentication succeeds and access to the service provider is granted, the bridge can optionally stop proxying the session, to prevent the user from gaining direct access to the identity provider.

[0100] Typically, if the authentication is unsuccessful, the bridge denies the user access to the service provider.

[0101] On the other hand, if the authentication is successful, the bridge obtains the identifier of the service provider, as described in the section immediately below. Alternatively, if the client reached the bridge by redirection from the identity provider, which may occur in embodiments in which the identity provider is configured to use the bridge for the initial authentication, the bridge may redirect the client to the identity provider with an access token that proves, to the identity provider, that the authentication was successful. Subsequently, in some embodiments, the identity provider uses the bridge for step-up authentication. Alternatively, if the user reached the bridge by redirection from the web proxy, the bridge may redirect the user to the web proxy. Subsequently, for accessing the service provider, the web proxy may again redirect the client to the bridge.

[0102] OBTAINING IDENTIFIER OF SERVICE PROVIDER

[0103] After the initial authentication to the identity provider or bridge, the bridge obtains the identifier of the service provider. For example, in some embodiments, the bridge obtains the identifier from the identity provider, e.g., by one of the following methods: a. In some embodiments, the bridge obtains the identifier during the redirection of the client from the identity provider to the bridge for authentication, e.g., in accordance with the SECURITY ASSERTION MARKUP LANGUAGE™ or OpenlD CONNECT™ protocol. For example, the identifier can be passed to the bridge in the redirection request, e.g., as part of a reply uniform resource locator. b. Alternatively, the identifier is not directly contained in the redirection request. Rather, the bridge follows the reply uniform resource locator contained in the redirection request to obtain additional information used to extract the identifier. For example, in some embodiments, the bridge generates a response to the redirection request, but instead of sending the response to the client, the bridge accesses the identity provider, using the response, as if it were the client. The bridge follows the same steps, vis-a-vis the identity provider, that a regular client would follow so as to obtain, eventually, a redirect to the service provider, or at least to a page that discloses a uniform resource locator, name, or identifier of the service provider. In such embodiments, typically, the access token for the service provider is obtained together with the identifier. c. Alternatively, the bridge uses an application programming interface of the identity provider to obtain the identifier of the service provider. For this purpose, the bridge can use the session established during the initial authentication or open a separate session. d. Alternatively, the identity provider uses an application programming interface of the bridge to notify the bridge of the identifier. This method is applicable, for example, in embodiments in which the initial authentication is performed with the identity provider without redirection to the bridge (though it is emphasized that other methods described herein are also applicable to such embodiments). e. Alternatively, for embodiments in which the bridge proxies communication between the client and the identity provider, the bridge obtains the identifier of the service provider from any of the requests from the client or the responses from the identity provider.

[0104] In other embodiments, provided the user selected the service provider via the web proxy (as described above in the section entitled “Initiating session with identity provider or bridge”), the bridge obtains the identifier of the service provider from the web proxy. For example: i. For some embodiments in which the web proxy redirects the user to the bridge, provided the user already selected the service provider, the redirection request includes an identifier of the service provider. For example, in some embodiments, the identifier is part of the uniform resource locator included in the redirection request. ii. Alternatively, the bridge calls an application programming interface of the web proxy to obtain information about the service provider. iii. Alternatively, the web proxy calls an application programming interface of the bridge to notify the bridge of the selected service provider.

[0105] In yet other embodiments, after authenticating to the bridge, the user selects the service provider using an interface of the bridge.

[0106] In some embodiments, after obtaining the identifier of the service provider, the bridge decides whether to deny the user access to the service provider, or to allow the access only after the implementation of additional security measures. This decision can depend on an administrator’s predefined policy, on inputs that may indicate user or session risk, and / or on additional input from the user. For example, the bridge may deny access to the service provider. REQUESTING ACCESS TO SERVICE PROVIDER

[0107] After the bridge obtains the identifier of the service provider, the bridge requests access to the service provider from the identity provider, e.g., using the SECURITY ASSERTION MARKUP LANGUAGE™ protocol or any other suitable federation protocol. For this request, the bridge can use the same session used during the user’s initial authentication.

[0108] In some cases, the identity provider grants the requested access immediately. In other cases, the identity provider requires step-up authentication from the user. Subsequently, the bridge requests the step-up authentication from the user, or simply provides the step-authentication on behalf of the user, as described in the section entitled “Configuration of identity provider”, option 2. Subsequently, the bridge is granted an access token that can be later used by the user, bridge, or web proxy to access the service provider.

[0109] In some embodiments, after obtaining access to the service provider, the bridge decides whether to implement additional security measures. For example, in some embodiments, the bridge requires step-up authentication from the user, providing a new level of identity segmentation, privileged access control, and / or additional risk-based authentication to enforce zero-trust principles.

[0110] INITIATING SESSION WITH SERVICE PROVIDER

[0111] In some embodiments, after the bridge obtains access to the service provider, the bridge redirects the client to the service provider and provides, to the client, the access token received from the identity provider. From this point the client can work directly with the service provider without further involvement by the bridge. Although the use of the web proxy is not enforced in these embodiments, an advantage is that the bridge had the opportunity to enforce security policies upon obtaining the service-provider identifier (as described in the section entitled “Obtaining identifier of service provider”) and / or upon obtaining access to the service provider (as described in the section immediately above).

[0112] Alternatively, the bridge provides the access token to the web proxy. Subsequently, using the access token, the web proxy controls the session of the client with the service provider. In some embodiments, the web proxy obtains the access token in one of the following ways: a. In some embodiments, the bridge calls an application programming interface of the web proxy to send the access token to the web proxy, and redirects the client to the web proxy. b. Alternatively, the bridge redirects the client to the web proxy, and the redirection request includes the access token. For example, the access token can be included in the uniform resource locator included in the redirection request. In some embodiments, the access token is encrypted by the bridge, such that the client cannot use the token to connect directly to the service provider. Upon receiving the token, the web proxy decrypts the token. c. Alternatively, the bridge redirects the client (without the access token) to the web proxy and then uses the access token to intermediate between the web proxy and service provider, such that the client accesses the service provider via the web proxy and bridge. For example, in some embodiments, the bridge redirects the client with a token for a virtual bridge app, which is created by the bridge in the web proxy configuration. In other words, the web proxy is configured to recognize the bridge as a service provider, and the client is redirected to the web proxy with an access token for this virtual service provider. The bridge then intermediates between the web proxy and the actual service provider, e.g., by functioning as a proxy to the actual service provider, using the access token. For example, if the service provider is SALESFORCE™, the bridge may redirect the user to the web proxy, which proxies the communication to the bridge, which in turn proxies the communication to SALESFORCE™. d. Alternatively, the bridge proxies the entire session, or at least the beginning of the session, between the client and the web proxy. The bridge sends the access token, along with the client’s request to access the service provider, to the web proxy. Typically, in any response from the bridge to the client, the bridge hides, from the client, any tokens or cookies received from the service provider by replacing them or not including them in the response. For embodiments in which only the beginning of the session is proxied, the bridge redirects the client to work directly with the web proxy in the middle of the session. e. Alternatively, the bridge and web proxy are implemented as separate software modules on the same server or cloud service, and the token is communicated between the modules.

[0113] EXAMPLES

[0114] Reference is now made to Fig. 3, which is a diagram of an example flow of communication in accordance with some embodiments of the present invention. In this example, bridge 28 is configured to function as an external identity provider for identity provider (IdP) 30, as described above in the section entitled “Configuration of identity provider,” option La. For convenience, in the description that follows, each exchange of communication represented by a double-sided arrow in Fig. 3 is referred to as a “step.” Client 22 begins the authentication process by connecting to the bridge at a connecting step 40, as described above in the section entitled “Initiating session with identity provider or bridge.” The authentication then proceeds as described above in the section entitled “Initial authentication to bridge.” In particular, the user authenticates to the bridge at an authenticating step 42. After accepting the user’s credentials, the bridge proxies the authentication to identity provider 30 at a proxying step 44. After successful authentication, the bridge displays an interface via which the user selects the target service provider at an SP-selecting step 46, and then enforces a preconfigured security policy (e.g., to enforce step-up authentication) at a security-enforcing step 48, as described above in the section entitled “Obtaining identifier of service provider.”

[0115] Subsequently, at a token-obtaining step 50, using the same session used for proxying step 44, the bridge passes the identifier of the service provider to the identity provider and obtains, in return, a token to access the service provider, as described above in the section entitled “Requesting access to service provider.” Next, at a redirecting step 52, the bridge encrypts the access token and then redirects the client to web proxy 26 with the encrypted access token included in the redirection request, as described above in the section entitled “Initiating session with service provider,” option b. Subsequently, at an accessing step 54, the client accesses the service provider via the web proxy. To facilitate accessing step 54, the web proxy is configured to decrypt the token and to use the token to access the service provider. Thus, advantageously, the client is not granted direct access to the service provider.

[0116] Reference is now made to Fig. 4, which is a diagram of another example flow of communication in accordance with some embodiments of the present invention. In this example, too, bridge 28 is configured to function as an external identity provider for identity provider (IdP) 30, as described above in the section entitled “Configuration of identity provider,” option l.a.

[0117] In this example, client 22 attempts to access service provider 24 at an access-attempting step 56. In response, the service provider redirects the client to identity provider 30 at a redirecting step 58, as described above in the section entitled “Initiating session with identity provider or bridge.” The client then establishes a session with the identity provider at a session-establishing step 60, as described above the aforementioned section. Due to the identity provider being configured to use the bridge as an external identity provider, the identity provider redirects the client to the bridge at a redirecting step 62, as described above in the section entitled “Initial authentication to identity provider.”

[0118] Next, at an authenticating step 64, the client connects to the bridge, and the bridge then requests the user’s credentials from the user and authenticates the user in response thereto, as described above in the section entitled “Initial authentication to bridge.” At this step, the bridge can also obtain the identifier of service provider 24, as described above in the section entitled “Obtaining identifier of service provider,” method b.

[0119] Subsequently, at proxying step 44, the bridge proxies the authentication to identity provider 30, as in Fig. 3. In particular, the bridge validates the user’s credentials with the identity provider, thereby authenticating to the identity provider on behalf of the user. For example, in some embodiments, the bridge accesses an interface of the identity provider that does not use the bridge as an identity external identity provider, thus avoiding an infinite loop.

[0120] Subsequently, at a token-obtaining step 66, the bridge receives a response from the identity provider and follows the response to obtain the access token for service provider 24. The bridge then enforces a pre-configured security policy (e.g., step-up authentication) at a security -enforcing step 72, as described above in the section entitled “Requesting access to service provider.” Subsequently, the flow proceeds with redirecting step 52 and accessing step 54, as described above for Fig. 3.

[0121] It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove, as well as variations and modifications thereof that are not in the prior art, which would occur to persons skilled in the art upon reading the foregoing description.

Claims

CLAIMS1. A method for controlling access of a client to a service provider that trusts an identity provider to authenticate a user of the client, the method comprising: using a bridge, intermediating between the client and the identity provider such that the identity provider sends an access token, which provides the access to the service provider, to the bridge rather than to the client; and using the bridge, controlling use of the access token, thereby controlling the access of the client to the service provider.

2. The method according to claim 1, wherein intermediating between the client and the identity provider comprises intermediating between the client and the identity provider by authenticating to the identity provider instead of the user.

3. The method according to claim 2, wherein intermediating between the client and the identity provider further comprises requesting the access in the same session used for authenticating to the identity provider.

4. The method according to claim 2, wherein authenticating to the identity provider comprises authenticating to the identity provider using credentials of the user.

5. The method according to claim 2, wherein authenticating to the identity provider comprises authenticating to the identity provider using one or more other access tokens that provide access to the identity provider by virtue of the bridge functioning as an external identity provider for the identity provider.

6. The method according to claim 1, wherein intermediating between the client and the identity provider comprises intermediating between the client and the identity provider by proxying communication between the client and the identity provider.

7. The method according to claim 6, further comprising identifying the service provider from the proxying, wherein intermediating between the client and the identity provider comprises requesting the access by virtue of having identified the service provider.

8. The method according to any one of claims 1-7, wherein controlling the use of the access token comprises causing the client to access the service provider, using the access token, via a web proxy.

9. The method according to claim 8, wherein controlling the use of the access token further comprises proxying at least a beginning of a session between the client and the web proxy, such that the client accesses the web proxy via the bridge.

10. The method according to claim 8, further comprising using the access token, by the web proxy, to control a session between the client and the service provider.

11. The method according to claim 8, wherein causing the client to access the service provider via the web proxy comprises causing the client to access the service provider via the web proxy by encrypting the access token such that the web proxy, but not the service provider, can decrypt the access token.

12. The method according to claim 11, further comprising, using the web proxy, decrypting the access token.

13. The method according to claim 8, wherein causing the client to access the service provider via the web proxy comprises causing the client to access the service provider via the web proxy by redirecting the client to the web proxy with the access token.

14. The method according to claim 13, wherein redirecting the client to the web proxy with the access token comprises redirecting the client to the web proxy with the access token by including the access token in a redirection request of the redirection.

15. The method according to claim 8, wherein causing the client to access the service provider via the web proxy comprises redirecting the client to the web proxy and sending the access token to the web proxy.

16. The method according to claim 15, wherein sending the access token to the web proxy comprises sending the access token to the web proxy via an application programming interface of the web proxy.

17. The method according to claim 15, wherein the bridge and web proxy are implemented as separate software modules on the same server or cloud service, and wherein sending the access token to the web proxy comprises sending the access token to the web proxy by communicating the token between the modules.

18. The method according to any one of claims 1-7, wherein controlling the use of the access token comprises: redirecting the client to a web proxy that services the service provider; and using the access token to intermediate between the web proxy and service provider, such that the client accesses the service provider via the web proxy and bridge.

19. The method according to any one of claims 1-7, wherein controlling the use of the access token comprises controlling the use of the access token by implementing one or more security measures prior to allowing use of the access token.

20. The method according to any one of claims 1-7, further comprising receiving a redirection of the client from the identity provider, wherein intermediating between the client and the identity provider comprises intermediating between the client and the identity provider by virtue of the redirection.

21. The method according to claim 20, wherein receiving the redirection comprises receiving the redirection by virtue of functioning as an external identity provider for the identity provider.

22. The method according to claim 20, wherein receiving the redirection comprises receiving the redirection by virtue of providing a custom sign-in form for the identity provider.

23. The method according to claim 20, wherein receiving the redirection comprises receiving the redirection by virtue of providing step-up authentication functionality for the identity provider.

24. The method according to claim 20, further comprising identifying the service provider during the redirection, wherein intermediating between the client and the identity provider comprises requesting the access by virtue of having identified the service provider.

25. The method according to any one of claims 1-7, further comprising receiving a redirection of the client from a web proxy that services the service provider, wherein intermediating between the client and the identity provider comprises intermediating between the client and the identity provider by virtue of the redirection.

26. The method according to claim 25, further comprising, using the web proxy, redirecting the client to the bridge such that the bridge receives the redirection.

27. The method according to claim 25, further comprising identifying the service provider from a redirection request of the redirection, wherein intermediating between the client and the identity provider comprises requesting the access by virtue of having identified the service provider.

28. The method according to any one of claims 1-7, wherein intermediating between the client and the identity provider comprises intermediating between the client and the identity provider following an initiation of a session, by the client, with the bridge.

29. The method according to any one of claims 1 -7, further comprising, prior to intermediating between the client and the identity provider, authenticating the user using the identity provider to validate credentials of the user.

30. The method according to any one of claims 1-7, further comprising identifying the service provider via an application programming interface of the identity provider, wherein intermediatingbetween the client and the identity provider comprises requesting the access by virtue of having identified the service provider.

31. The method according to any one of claims 1 -7, further comprising receiving a notification, from the identity provider, identifying the service provider, wherein intermediating between the client and the identity provider comprises requesting the access by virtue of having identified the service provider.

32. The method according to any one of claims 1-7, further comprising identifying the service provider via an application programming interface of a web proxy servicing the service provider, wherein intermediating between the client and the identity provider comprises requesting the access by virtue of having identified the service provider.

33. The method according to any one of claims 1 -7, further comprising receiving a notification, from a web proxy servicing the service provider, identifying the service provider, wherein intermediating between the client and the identity provider comprises requesting the access by virtue of having identified the service provider.

34. The method according to claim 33, further comprising, using the web proxy, sending the notification to the bridge.

35. The method according to any one of claims 1-7, further comprising identifying the service provider via an interface provided, by the bridge, to the user, wherein intermediating between the client and the identity provider comprises requesting the access by virtue of having identified the service provider.

36. A computer software product comprising a tangible non-transitory computer-readable medium in which program instructions are stored, which instructions, when read by at least one processor, cause the processor to control access of a client to a service provider that trusts an identity provider to authenticate a user of the client, by: using a bridge, intermediating between the client and the identity provider such that the identity provider sends an access token, which provides the access to the service provider, to the bridge rather than to the client, and using the bridge, controlling use of the access token, thereby controlling the access of the client to the service provider.

37. The computer software product according to claim 36, wherein intermediating between the client and the identity provider includes intermediating between the client and the identity provider by authenticating to the identity provider instead of the user.

38. The computer software product according to claim 37, wherein intermediating between the client and the identity provider further includes requesting the access in the same session used for authenticating to the identity provider.

39. The computer software product according to claim 37, wherein authenticating to the identity provider includes authenticating to the identity provider using credentials of the user.

40. The computer software product according to claim 37, wherein authenticating to the identity provider includes authenticating to the identity provider using one or more other access tokens that provide access to the identity provider by virtue of the bridge functioning as an external identity provider for the identity provider.

41. The computer software product according to claim 36, wherein intermediating between the client and the identity provider includes intermediating between the client and the identity provider by proxying communication between the client and the identity provider.

42. The computer software product according to claim 41, wherein the instructions further cause the processor to identify the service provider from the proxying, wherein intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

43. The computer software product according to any one of claims 36-42, wherein controlling the use of the access token includes causing the client to access the service provider, using the access token, via a web proxy.

44. The computer software product according to claim 43, wherein controlling the use of the access token further includes proxying at least a beginning of a session between the client and the web proxy, such that the client accesses the web proxy via the bridge.

45. The computer software product according to claim 43, wherein the instructions further cause the processor to use the access token, using the web proxy, to control a session between the client and the service provider.

46. The computer software product according to claim 43, wherein causing the client to access the service provider via the web proxy includes causing the client to access the service provider via the web proxy by encrypting the access token such that the web proxy, but not the service provider, can decrypt the access token.

47. The computer software product according to claim 46, wherein the instructions further cause the processor to decrypt the access token using the web proxy.

48. The computer software product according to claim 43, wherein causing the client to access the service provider via the web proxy includes causing the client to access the service provider via the web proxy by redirecting the client to the web proxy with the access token.

49. The computer software product according to claim 48, wherein redirecting the client to the web proxy with the access token includes redirecting the client to the web proxy with the access token by including the access token in a redirection request of the redirection.

50. The computer software product according to claim 43, wherein causing the client to access the service provider via the web proxy includes redirecting the client to the web proxy and sending the access token to the web proxy.

51. The computer software product according to claim 50, wherein sending the access token to the web proxy includes sending the access token to the web proxy via an application programming interface of the web proxy.

52. The computer software product according to claim 50, wherein the bridge and web proxy are implemented as separate software modules on the same server or cloud service, and wherein sending the access token to the web proxy comprises sending the access token to the web proxy by communicating the token between the modules.

53. The computer software product according to any one of claims 36-42, wherein controlling the use of the access token includes: redirecting the client to a web proxy that services the service provider, and using the access token to intermediate between the web proxy and service provider, such that the client accesses the service provider via the web proxy and bridge.

54. The computer software product according to any one of claims 36-42, wherein controlling the use of the access token includes controlling the use of the access token by implementing one or more security measures prior to allowing use of the access token.

55. The computer software product according to any one of claims 36-42, wherein the instructions further cause the processor to receive a redirection of the client from the identity provider, wherein intermediating between the client and the identity provider includes intermediating between the client and the identity provider by virtue of the redirection.

56. The computer software product according to claim 55, wherein receiving the redirection includes receiving the redirection by virtue of functioning as an external identity provider for the identity provider.

57. The computer software product according to claim 55, wherein receiving the redirectionincludes receiving the redirection by virtue of providing a custom sign-in form for the identity provider.

58. The computer software product according to claim 55, wherein receiving the redirection includes receiving the redirection by virtue of providing step-up authentication functionality for the identity provider.

59. The computer software product according to claim 55, wherein the instructions further cause the processor to identify the service provider during the redirection, wherein intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

60. The computer software product according to any one of claims 36-42, wherein the instructions further cause the processor to receive a redirection of the client from a web proxy that services the service provider, wherein intermediating between the client and the identity provider includes intermediating between the client and the identity provider by virtue of the redirection.

61. The computer software product according to claim 60, wherein the instructions further cause the processor to redirect the client to the bridge, using the web proxy, such that the bridge receives the redirection.

62. The computer software product according to claim 60, wherein the instructions further cause the processor to identify the service provider from a redirection request of the redirection, wherein intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

63. The computer software product according to any one of claims 36-42, wherein intermediating between the client and the identity provider includes intermediating between the client and the identity provider following an initiation of a session, by the client, with the bridge.

64. The computer software product according to any one of claims 36-42, wherein the instructions further cause the processor to authenticate the user, using the identity provider to validate credentials of the user, prior to intermediating between the client and the identity provider.

65. The computer software product according to any one of claims 36-42, wherein the instructions further cause the processor to identify the service provider via an application programming interface of the identity provider, wherein intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

66. The computer software product according to any one of claims 36-42, wherein the instructions further cause the processor to receive a notification, from the identity provider,identifying the service provider, wherein intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

67. The computer software product according to any one of claims 36-42, wherein the instructions further cause the processor to identify the service provider via an application programming interface of a web proxy servicing the service provider, wherein intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

68. The computer software product according to any one of claims 36-42, wherein the instructions further cause the processor to receive a notification, from a web proxy servicing the service provider, identifying the service provider, wherein intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

69. The computer software product according to claim 68, wherein the instructions further cause the processor to send the notification to the bridge using the web proxy.

70. The computer software product according to any one of claims 36-42, wherein the instructions further cause the processor to identify the service provider via an interface provided, by the bridge, to the user, wherein intermediating between the client and the identity provider includes requesting the access by virtue of having identified the service provider.

71. A system for controlling access of a client to a service provider that trusts an identity provider to authenticate a user of the client, the system comprising: a communication interface; and a processor, configured to: using a bridge, intermediate between the client and the identity provider, via the communication interface, such that the identity provider sends an access token, which provides the access to the service provider, to the bridge rather than to the client, and using the bridge, control use of the access token, thereby controlling the access of the client to the service provider.

Images