Single sign-on for remote browsing web applications

Abstract

Architecture has been designed that introduces a "bootstrap server" into a single sign-on procedure to bootstrap SSO context to a remote browsing session. The bootstrap server provides a session token to the client browser to establish and secure a session between the client browser and the remote browsing system. After the client browser obtains the SSO token and is redirected to the bootstrap server, the bootstrap server provides a session token for the remote browsing session. The bootstrap server also generates a response to the client browser to cause the client browser to connect to the remote browsing system to establish the remote browsing session with the session token provided by the bootstrap server. Using the remote browsing session, the client browser transmits the SSO token for use by the remote browser.

Description

Technical Field

[0001] This disclosure generally relates to the transmission of digital information (e.g., CPC class H04L) and network architectures or network communication protocols for network security (e.g., CPC subclass H04L63 / 00). Background Technology

[0002] National Institute of Standards and Technology (NIST) Special Publication 800-207 provides a brief history of the term "zero trust" and explains that zero trust is "a paradigm focused on resource protection and presuming that trust is never implicitly granted but must be continuously evaluated." Remote Browser Isolation (RBI) is a technology included in zero trust implementations. Browser isolation uses containerization or virtualization technologies to isolate web browsers and browsing activity. RBI remotely provides browser isolation as a cloud-hosted or cloud-based service. Users interact with the remote browser via a secure client application or web-based interface that transmits input to the remote, isolated browser. The remote browser provides sanitized web page rendering (e.g., pixel reconstruction, Document Object Model (DOM) mirroring, streaming media). Attached Figure Description

[0003] The embodiments disclosed herein can be better understood with reference to the accompanying drawings.

[0004] Figure 1-2 This is a conceptual system diagram for bootstrapping single sign-on to remote browsing. Figure 1 This is a schematic diagram illustrating the system that transmits the single sign-on authentication context to the remote browsing session. Figure 2 This is a schematic diagram illustrating the system for handling re-authentication events detected in remote browser 113.

[0005] Figure 3 This is a flowchart illustrating a sample operation for bootstrapping a single sign-on login to a remote browser for a client browser.

[0006] Figure 4 This is a flowchart of an example operation for managing remote browsing with bootstrap single sign-on.

[0007] Figure 5 An example computer system with single sign-on to a remote browsing bootloader is described. Detailed Implementation

[0008] The following description includes example systems, methods, techniques, and process flows to aid in understanding this disclosure and is not intended to limit the scope of the claims. For the sake of brevity, well-known examples of instructions, protocols, structures, and techniques have not been shown in detail.

[0009] the term This specification relates to a "bootstrap server." A bootstrap server is a communication endpoint that can be hosted on a physical or virtual server. A bootstrap server is associated with one or more domains of an organization that provides services to protect remote browsing or RBI with a seamless single sign-on experience.

[0010] This specification uses the term "token" to refer to data representing the context or state of a session. In the case of "SSO token," the term refers to data representing the authentication context of an SSO session. In the case of "session token," the term refers to data representing the state of an application-layer session. Token implementations will vary depending on the standard or protocol. For example, different standards exist for authentication and authorization, including OpenID Connect and Security Assertion Markup Language (SAML) 2.0. Different standards and different implementations of those standards use different types of tokens (e.g., identity tokens, access tokens, refresh tokens) and different implementations of tokens (e.g., SAML assertions). Regardless of these differences, SSO tokens are consumed to authenticate digital identities, and session tokens are used to establish and maintain sessions.

[0011] Unless otherwise expressly stated, the use of the phrase "at least one" before a list containing the conjunction "and" should not be considered an exclusive list and should not be interpreted as a list of categories with an item from each category. A clause stating "at least one of A, B, and C" may be infringed by only one of the listed items, multiple listed items, one or more items in the list, and another unlisted item.

[0012] Overview While Remote Browser Isolation (RBI) can reduce the attack surface and facilitate zero-trust implementation, it can interfere with the Single Sign-On (SSO) experience. For SSO, a token representing digital identity authentication (“SSO token”) is maintained at the client browser that interacts with the identity provider. For RBI, the remote browser interacts with service provider endpoints that provide web-based services or applications. Without the client browser context (i.e., without an SSO token), the remote browser will interact with these service provider endpoints as directed by the client browser. If re-authentication is triggered, the SSO experience will be disrupted. Furthermore, authentication schemes that enforce multi-factor authentication (MFA) using local device hardware (such as fingerprint scanners) cannot be implemented using RBI.

[0013] An architecture has been designed to incorporate a "bootstrapping server" into the SSO process to bootstrap the SSO context to the remote browsing session. The bootstrapping server provides a session token to the client browser to establish and secure the session between the client browser and the remote browsing system. A trust relationship is pre-established between the bootstrapping server, the remote browsing system, and the identity provider. Furthermore, the identity provider offering the SSO service is configured to redirect requests to the bootstrapping server. After the client browser obtains the SSO token and is redirected to the bootstrapping server, the bootstrapping server provides a session token for the remote browsing session. The bootstrapping server also generates a response for the client browser, enabling the client browser to connect to the remote browsing system and establish a remote browsing session using the session token provided by the bootstrapping server. After verifying the session token, the remote browsing system, or an isolated environment provided by the remote browsing system, passes the SSO token to the remote browser instantiated within the isolated environment, allowing the remote browser to access the service endpoint belonging to the identity provider.

[0014] Example illustration Figure 1-2 This is a schematic diagram of a conceptual system used to bootstrap single sign-on to remote browsing. Figure 1 This is a schematic diagram illustrating the system for transferring SSO authentication context to a remote browsing session. It assumes that a trust relationship has been established between the organization managing or owning bootstrap server 107 and the remote browsing system providing remote browsing as a service. The remote browsing system has infrastructure for instantiating or provisioning an isolated environment 111 (e.g., a container or virtual machine) and instantiating a browser 113 within that isolated environment. As an example, the remote browsing system could be a cloud service provider or a cloud service platform provider. The organization owning / managing bootstrap server 107 provides services that facilitate SSO experience access to remote browsing while also securing remote browsing. A trust relationship has also been established between bootstrap server 107 and identity provider 103.

[0015] Figure 1 and Figure 2 All are labeled with a series of letters AK, where each stage represents one or more operations. Although these stages are ordered for this example, they illustrate an example to aid in understanding this disclosure and should not be used to limit the claims. Subject matter falling within the scope of the claims may differ from that shown in the illustrations.

[0016] In phase A, client browser 101 submits its credentials to identity provider 103. Client browser 101 may be accessing identity provider 103's login portal, or it may have been redirected to identity provider 103 when attempting to access protected resources of a service provider that has a relationship with identity provider 103.

[0017] In phase B, identity provider 103 responds to client browser 101 with a redirect to bootstrap server 107. The response includes a Single Sign-On (SSO) token 105, which provides an authentication context for the digital identity. For example, SSO token 105 could be a Security Assertion Markup Language (SAML) assertion. Configuration has already been completed at identity provider 103 to enable the redirection. For example, the domain mapped to bootstrap server 107 is set to an Assertion Consumer Service (ACS) endpoint targeting the organization corresponding to client browser 101 and / or the digital identity corresponding to the credentials submitted via the client browser.

[0018] In phase C, client browser 101 submits a request to bootstrap server 107 based on a redirect from identity provider 103. The redirected request includes an SSO token 105 providing the authentication context.

[0019] In phase D, bootstrapping server 107 uses identity provider 103 to verify SSO token 105. As mentioned earlier, a trust relationship has already been established with identity provider 103.

[0020] In phase E, bootstrap server 107 generates session token 109 and communicates it to client browser 101. Session token 109 allows client browser 101 to establish a secure remote browsing session with the remote browsing system, which will verify session token 109. Due to the previously established trust relationship, the remote browsing system can use a key for verification, for example, a key previously provided by bootstrap server 107 or another element of the organization managing bootstrap server 107. Bootstrap server 107 also instructs client browser 101 to send SSO token 105 to the remote browsing system.

[0021] In phase F, client browser 101 connects to the remote browsing system using session token 109 and transmits SSO token 105 as the payload. Calls to web application programming interface (API) functions or access to web pages can communicate requests to connect to the remote browsing system. In the example of requesting a connection using Hypertext Transfer Protocol (HTTP) message 110, session token 109 is encoded in the header of message 110, and SSO token 105 is transmitted in the body of message 110.

[0022] In phase G, after verifying session token 109, the isolation environment 111 of the remote browsing system establishes a remote browsing session with the client browser 101. If session token 109 is not valid, the connection request will be rejected. Also after verifying session token 109, the isolation environment 111 determines that message 110 includes SSO token 105 and stores SSO token 105 in the cache of browser 113.

[0023] In phase H, client browser 101 communicates input to isolation environment 111. This phase is a general example of input transfer from client browser to isolation environment. For this illustration, input includes input navigating to the service provider endpoint of web application 115 with the identifier Web_App1.

[0024] In Phase I, remote browser 113 attempts to access Web_App1. As part of the exchange for authentication with Web_App1, remote browser 113 communicates an SSO token 105.

[0025] In phase J, Web_App1 uses identity provider 103 to verify SSO token 105. Of course, this presupposes that the service provider of Web_App1 has a trust relationship with identity provider 103 and has delegated the authentication responsibility to the identity provider.

[0026] In phase K, after verifying the SSO token 105, Web_App1 provides a cookie (a small file) and content. The cookie is provided to maintain the state of the application session between the remote browser 113 and Web_App1.

[0027] Figure 2 This is a system diagram illustrating the handling of re-authentication events detected by remote browser 113. Re-authentication events can be triggered from the service provider endpoint being accessed. For example, security policies may change or application sessions may expire. Re-authentication events can also be triggered by navigating to different service provider endpoints. Figure 2 The re-authentication event is described as being triggered by navigation to web application 211, identified as Web_App2. In phase A, Web_App2 communicates the re-authentication event to remote browser 113. This communication may be a redirect to identity provider 103.

[0028] In phase B, isolation environment 111 intercepts the re-authentication event and communicates it to client browser 101. Since remote browser 113 is isolated within isolation environment 111, isolation environment 111 monitors communication with remote browser 113 and can detect and intercept re-authentication events. Intercepting the re-authentication event prevents remote browser 113 from taking action on the re-authentication event. Assuming the re-authentication event communicates with a redirected HTTP request, isolation environment 111 can forward the re-authentication event to client browser 101. The communication of the re-authentication event includes the Uniform Resource Locator (URL) of the service provider endpoint that generated the re-authentication event. Isolation environment 111 can transmit the redirection request message from the service provider endpoint to client browser 101.

[0029] Figure 2 The subsequent operation phase CK is similar to Figure 1 The stages AG and IJ in the middle.

[0030] In phase C, client browser 101 submits credentials to identity provider 103. A re-authentication event may indicate a multi-factor authentication (MFA) requirement. If the MFA requirement involves biometrics, remote browser 113 will be unable to meet the MFA requirement. Since the authentication event with the MFA requirement is intercepted and communicated to client browser 101, which is assumed to be present at a device near the user, biometrics can be provided to identity provider 103.

[0031] In phase D, identity provider 103 responds to client browser 101 with a redirect to bootstrap server 107. The response includes SSO token 205. This can be a renewed version of SSO token 105, depending on the validity of the SSO token 105 used for re-authentication.

[0032] In phase E, client browser 101 submits a request based on a redirect from identity provider 103. The redirected request includes an SSO token 205 providing the authentication context.

[0033] In phase F, bootstrapping server 107 uses identity provider 103 to verify SSO token 205. When client browser 101 submits a request to identity provider 103, client browser 101 may include a cookie previously provided to client browser 101. If the cookie is still valid (i.e., the session between client browser 101 and bootstrapping server 107 is still valid), bootstrapping server 107 can bypass the verification of SSO token 205.

[0034] In phase G, bootstrap server 107 renews session token 109 and sends the renewed session token 109 to client browser 101. Bootstrap server 107 may interact with multiple client browsers and remote browsing sessions. Bootstrap server 107 maintains information about the generated session tokens to determine whether the session token is still valid and whether session token renewal is allowed. Bootstrap server 107 also instructs client browser 101 to send SSO token 205 to the remote browsing system.

[0035] In phase H, client browser 101 connects to the remote browsing system using the renewed session token 109 and transmits the SSO token 205 as a payload. Client browser 101 transmits a request message 210, which includes the renewed session token 109 and the SSO token 205. After the phase B communication reauthentication event, the underlying connection to the remote browsing system may have been maintained or terminated. If the connection is terminated, client browser 101 will run code to reopen the connection.

[0036] In Phase I, after verifying the renewed session token 109, the isolated environment 111 of the remote browsing system establishes a remote browsing session with the client browser 101. The previously established remote browsing session should have expired. Therefore, the request is for a new remote browsing session with the renewed session token 109. The request for the remote browsing session includes the URL of the service provider endpoint that generated the re-authentication event. This can be included in a field of the redirect message sent by the identity provider 103 in Phase D. For example, the service provider URL can be in the meta refresh field. Persisting the URL via a bootstrap re-authentication path allows browsing to continue seamlessly, even if the original remote browser 113 and the isolated environment 111 are released. However, embodiments may maintain the isolated environment 111 for a period sufficient for the client browser 101 to respond with the new SSO token 109. In this scenario, after the isolated environment 111 extracts the SSO token 205 from message 210 and provides the SSO token 205 to the remote browser 113, it can release the intercepted re-authentication event to the remote browser 113 or a new instance of the remote browser 113.

[0037] In phase J, remote browser 113 responds to the re-authentication event with a new SSO token 205.

[0038] In phase K, Web_App2 uses identity provider 103 to verify SSO token 205.

[0039] although Figure 1-2 The illustrations provide illustrative context to help understand the disclosed technology, but the scope of the claims is not limited to what is depicted. Figure 3-4 It is a flowchart with example operations that enhance the understanding of the process. Figure 1-2 The example deployments described herein should not limit the scope of the claims. Figure 3-4 Further operational details are provided to aid in understanding the technology. (In conjunction with the previously attached...) Figure 1 To, Figure 3 The bootstrap server is designated as the one performing the example operations, and Figure 4The isolated environment of the remote browsing system is used to refer to the execution of example operations. The name chosen for the program code is not intended to limit the claims. The structure and organization of the program can vary due to platform, programmer / architect preferences, programming language, etc. Furthermore, the names of code units (programs, modules, methods, functions, etc.) can vary for the same reasons and can be arbitrary.

[0040] Figure 3 This is a flowchart illustrating a sample operation for bootstrapping a single sign-on (SSO) service to a remote browser for a client browser. The bootstrap code will run on a server provided by an organization offering remote browsing services with SSO.

[0041] In block 301, the bootstrap server receives a redirected request with an SSO token for the client's browser. The user may be logged into the identity provider's portal or attempting to access an endpoint redirected to the identity provider, which in turn redirects to the bootstrap server. In other implementations, security facilities (such as firewalls) are configured to route SSO responses from the identity provider (e.g., SAML assertions) to the bootstrap server. For example, a rule can be configured on the firewall specifying the identity provider's network address or network address range to intercept and analyze traffic to determine if it is an SSO response. If the traffic matches the rule, the firewall routes the SSO response to the bootstrap server.

[0042] At block 303, the bootstrap server determines whether the SSO token is valid. If no session exists between the client browser sending the request and the bootstrap server (as evidenced by the cookie in the redirected request), the bootstrap server will verify the SSO token using an identity provider. If a valid session exists between the bootstrap server and the client browser, the bootstrap server considers the SSO token valid, and unless otherwise specified by procedure or security policy, in which case the bootstrap server will verify it using an identity provider. If the SSO token is valid, the process continues to block 307. If the SSO token is not valid, the process continues to block 305.

[0043] At block 305, the bootstrap server responds to the client browser with a webpage indicating that the SSO token is invalid. The bootstrap server may return a code indicating that the resource is unavailable or inaccessible. Figure 3 The operation process ends after block 305.

[0044] At block 307, the bootstrap server determines whether a valid session token exists for the client browser for remote browsing. For an existing remote browsing session for which the bootstrap server has already provided a session token, the bootstrap server will maintain session information, for example, in a local database or table. The session information may include the expiration time and unique identifier of the previously provided session token. The session information is associated with the session identifier in a cookie, which was also previously provided to the client browser. The cookie, indicating the session state between the bootstrap server and the client browser, includes data that associates it with the session token for the remote browsing session. The bootstrap server will look up the session identifier indicated in the cookie from the client browser. If no such identifier is found, no existing valid remote browsing session exists. If a valid remote browsing session exists for the client browser, the process continues to block 311. If no valid remote browsing session exists for the client browser, the process continues to block 309.

[0045] In block 309, the bootstrap server generates a remote browsing session for the client browser, which is signed by the bootstrap server. For example, the bootstrap server may generate an object with a unique identifier and then digitally sign the object to generate a session token. The process continues to block 313A.

[0046] If the bootstrap server determines that the client has a valid remote browsing session (307), the bootstrap server renews the valid remote browsing session token in block 311. The bootstrap server locates the unique identifier of the remote browsing session in a remote browsing session table or database maintained by the bootstrap server. The entry for the unique identifier includes an expiration time, which the bootstrap server extends to renew the session token. Subsequently, the bootstrap server will issue the same session token, but with the issuance time updated in the session table / database.

[0047] In block 313A, the bootstrap server responds to the client browser with a web page component, enabling the client browser to connect to the remote browsing system using a session token and communicate the SSO token to the remote browsing system. The web page component may include program code (e.g., a script) to be executed by the client browser, or references to program code to be executed by the client browser, to enable the client browser to open a connection to the remote browsing system. For example, a script may be run to create a socket and establish a connection to the remote browsing system specified in the script. The socket-based connection will output from the client browser to the isolated environment of the remote browsing system. After the connection is established, the script will cause the client browser to communicate an HTTP request that includes the remote browsing session token provided by the bootstrap server. The script will also cause the client browser to embed the SSO token into the body of the HTTP message.

[0048] In some cases, a view server will be used to reduce the responsibility of the bootstrap server. Block 313B is an alternative to 313A. In Block 313B, the bootstrap server communicates session tokens and SSO tokens to the view server. This communication includes instructions to generate the previously described web page components.

[0049] Figure 4 This is a flowchart illustrating example operations for managing remote browsing with bootstrap single sign-on. The isolated environment of the isolated remote browser will be programmed to authenticate the remote browsing session, extract the SSO token of the isolated environment as a payload, and intercept re-authentication events intended for the remote browser for transmission back to the client browser.

[0050] In Block 401, the isolation environment receives remote browsing requests from the client browser. The isolation environment can handle messages typically received by a browser. Furthermore, the isolation environment translates input from the client browser into input from the remote client. For example, the isolation environment maps pixel-based input to document objects (such as buttons or links) and can create events (such as clicks or selections). The translation of client browser input depends on how the content is sanitized for the client browser. However, some input from the client browser (such as HTTP GET requests specifying a URL) can be transmitted without translation, such as requests to navigate to a URL.

[0051] At block 403, the isolated environment determines whether the request includes a valid session token. For example, the isolated environment would have access to a key or secret previously shared via certificate distribution. In this way, the isolated environment can verify the signature on the session token. If the session token is valid, the operation continues to block 407. If not, the request is rejected (block 405) and the operation ends.

[0052] At block 407, the isolation environment determines whether the request includes an SSO token. The isolation environment will be programmed or configured to search for an SSO token in the body of the request. If the request does not include an SSO token, remote browsing may continue to an endpoint or domain that does not require authentication (i.e., until the process continues to block 413). If the request includes an SSO token, the operation continues to block 409.

[0053] In block 409, the browser is instantiated in the isolated environment and the SSO token is stored in the browser cache. In some cases, the browser may already be instantiated in the isolated environment.

[0054] In block 411, the browser in the isolated environment requests access to the service provider endpoint indicated in the input from the client browser. During the authentication exchange with the service provider endpoint, the browser will provide an SSO token.

[0055] Since synchronization is not necessary, dashed lines are depicted from blocks 407 and 411 through 413. Input may be non-navigational input interacting with a webpage, and navigational input may not be able to access protected resources that require authentication for authorization. In block 413, the isolation environment detects and intercepts a re-authentication event. Re-authentication events can be sent by the server endpoint due to changes in authentication requirements, expiration of the SSO token, navigation to a different service provider endpoint, etc. When the isolation environment detects a re-authentication event, it intercepts the event to prevent delivery to the included browser. The isolation environment may cache the re-authentication event until the client browser responds with a new SSO token, and then subsequently deliver the re-authentication event to the browser.

[0056] In block 415, the isolation environment will communicate the reauthentication event to the client browser. If the reauthentication event is communicated as an HTTP message from the service provider endpoint, the isolation environment can forward the message to the client browser, which should then redirect to the identity provider.

[0057] The flowcharts are provided to aid in understanding the illustrations and are not intended to limit the scope of the claims. The flowcharts depict example operations that can be varied within the scope of the claims. Additional operations may be performed; fewer operations may be performed; operations may be performed in parallel; and operations may be performed in a different order. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by program code. The program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable machine or device.

[0058] It should be understood that aspects of this disclosure can be embodied as systems, methods, or program code / instructions stored in one or more machine-readable media. Accordingly, these aspects can take the form of hardware, software (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects, which are generally referred to herein as “circuit,” “module,” or “system.” Functionality presented as a separate module / unit in the example illustrations can be organized in different ways depending on any of the following: platform (operating system and / or hardware), application ecosystem, interface, programmer preferences, programming language, administrator preferences, etc.

[0059] Any combination of one or more machine-readable media may be used. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable storage medium can be, for example, but not limited to, a system, apparatus, or device that uses any or a combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technologies to store program code. More specific examples of machine-readable storage media (a non-exhaustive list) will include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a machine-readable storage medium can be any tangible medium that can contain or store a program for use by or connected to an instruction execution system, apparatus, or device. A machine-readable storage medium is not a machine-readable signal medium.

[0060] Machine-readable signal media may include propagated data signals embodying machine-readable program code, for example, in baseband or as a carrier wave. Such propagated signals may take any of a variety of forms, including but not limited to electromagnetic, optical, or any suitable combination thereof. A machine-readable signal medium may be any machine-readable medium that is not a machine-readable storage medium but can communicate, propagate, or transmit programs for use by or connected to an instruction execution system, apparatus, or device.

[0061] Program code embodied on a machine-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, or any suitable combination thereof.

[0062] Program code / instructions may also be stored in a machine-readable medium that can instruct a machine to operate in a particular manner, such that the instructions stored in the machine-readable medium produce an article of manufacture, which includes instructions that implement functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0063] Figure 5An example computer system with a bootstrap for single sign-on to remote browsing is depicted. The computer system includes a processor 501 (which may include multiple processors, multiple cores, multiple nodes, and / or implement multiple threads, etc.). The computer system includes memory 507. Memory 507 may be any one or more possible implementations of system memory or machine-readable media as described above. The computer system also includes a bus 503 and a network interface 505. The system also includes a bootstrap for SSO to remote browsing 511 (“bootstrap”). Bootstrap 511 transmits an SSO token (e.g., a SAML assertion) to a remote browser over a remote browsing session to allow remote browsing with a seamless SSO experience. Bootstrap 511 transmits the SSO token based on an overlapping trust relationship, which is: 1) a trust established between bootstrap 511 and the remote browsing system and 2) a trust established between bootstrap 511 and an identity provider. Bootstrap 511 associates these different trust domains by instructing the client browser to establish a remote browsing session using a session token provided by bootstrap 511, and by using the remote browsing session to transmit an SSO token to the remote browser. Any of the foregoing functions can be implemented partially (or completely) in hardware and / or on processor 501. For example, the functions can be implemented using application-specific integrated circuits, logic implemented in processor 501, coprocessors on peripheral devices or cards, etc. Furthermore, the implementation may include fewer components or Figure 5 Additional components not shown (e.g., video card, sound card, additional network interface, peripherals, etc.). Processor 501 and network interface 505 are coupled to bus 503. Although shown as being coupled to bus 503, memory 507 may be coupled to processor 501.

Claims

1. A method comprising: Based on the redirected request received from the client browser, determine whether the redirected request includes a valid Single Sign-On (SSO) token; Based on the determination that the redirected request includes a valid SSO token, Determine whether the redirected request includes a valid cookie from the client's browser; Based on the determination that the redirected request does not contain a valid cookie, a session token for the remote browsing session is generated; Based on the determination that the redirected request includes a valid cookie for the client browser and a session renewal token; The generation and transmission enable the client browser to use the session token to request a remote browsing session and include the SSO token in the request. Based on the determination that the SSO token is not valid, the client browser is redirected to the identity provider; as well as A remote browsing session is established between the client browser and the remote browser based on the session token verified by the remote browsing system, and an SSO token is provided for the remote browser to use to access the service provider endpoint.

2. The method according to claim 1, wherein, The redirected request is redirected by the identity provider that generated the SSO token, or the security facility intercepts the redirected request from the identity provider and routes it to the server or service, wherein the communication that generates and transmits the SSO token so that the client browser can use the session token to request a remote browsing session and includes the SSO token in the request is performed by the server or service.

3. The method according to claim 1, wherein, The communication that enables a client browser to request a remote browsing session includes generating a web page component with program code to connect the client browser to the remote browsing system using a session token and including an SSO token as a payload in the remote browsing session request. Optionally, the payload is in the body of the remote browsing session request. The communication includes responding to a redirected request with the web page component, the session token, and the SSO token. Optionally, the communication is transmitted to the view server.

4. The method according to any one of claims 1 to 3, further comprising: Remote browsing system Intercept re-authentication events received in a remote browser, wherein the re-authentication event may optionally indicate multi-factor authentication; Communicate the re-authentication event to the client browser; and Depending on whether the client browser presents a valid cookie after obtaining the second SSO token from the identity provider, generates a new session token or renews the session token, and optionally, the client browser obtains the second SSO token based on interacting with the identity provider to satisfy the indicated multi-factor authentication.

5. A non-transitory machine-readable medium having program code stored thereon, the program code including instructions for performing the following operations: Based on the redirected request received from the client browser, determine whether the redirected request includes a valid Single Sign-On (SSO) token; Based on the determination that the redirected request includes a valid SSO token, Determine whether the redirected request includes a valid cookie for the client's browser; Based on the determination that the redirected request does not contain a valid cookie, a session token for the remote browsing session is generated; Based on the determination that the redirected request includes a valid cookie for the client browser and a session renewal token; as well as Generate a web page component with second program code to connect the client browser to the remote browsing system using a session token and include the SSO token as a payload in the remote browsing session request or in the body of the remote browsing session request.

6. The non-transitory machine-readable medium of claim 5, having stored thereon third program code, the third program code including instructions that cause the remote browsing system to provide an SSO token for the remote browser to use to access the service provider endpoint after the remote browsing system verifies the session token.

7. The non-transitory machine-readable medium according to claim 6, wherein, The third program code also includes instructions for the following operations: Intercepting re-authentication events received in a remote browser; and The re-authentication event is communicated to the client browser.

8. The machine-readable medium according to any one of claims 5 to 7, wherein, The program code also includes instructions that, based on the determination that the SSO token is not valid, redirect the client browser to the identity provider.

9. A system comprising: The first server executes the program using the first piece of code. Based on the redirected request received from the client browser, determine whether the redirected request includes a valid Single Sign-On (SSO) token; Based on the determination that the redirected request includes a valid SSO token, Determine whether the redirected request includes a valid cookie for the client's browser; Based on the determination that the redirected request does not contain a valid cookie, a session token for the remote browsing session is generated; Based on the determination that the redirected request includes a valid cookie for the client browser and a session renewal token; The generation and transmission enable the client browser to use the session token to request a remote browsing session and include the SSO token in the request. as well as The second server executes the program using a second set of program code. After establishing a remote browsing session based on the authentication session token, an SSO token is provided for the remote browser to use to access the service provider endpoint.

10. The system according to claim 9, wherein, The first server includes a first processor and a first memory thereon storing first program code executable by the first processor, and the second server includes a second processor and a second memory thereon storing second program code.

11. The system according to claim 9 or 10, wherein, The instructions for generating first program code that causes a client browser to request a remote browsing session include instructions executable to cause a first server to generate a web page component with third program code, the client browser running the third program code to connect the client browser to the remote browsing system using a session token and including an SSO token as a payload in the remote browsing session request, wherein the instructions for transmitting the first program code include instructions executable to cause the first server to respond to the redirected request with a web page component, a session token, and an SSO token.

12. The system according to claim 11, wherein, When run by the client browser, the third-party program code causes the client browser to include the SSO token in the body of the remote browsing session request.

13. The system according to claim 11, wherein, The instructions for generating first program code that causes a client browser to request a remote browsing session include instructions executable to cause a first server to instruct communication to a view server to generate a web page component with third program code, which, when run by the client browser, uses a session token to connect the client browser to the remote browsing system and includes an SSO token as a payload in the remote browsing session request.

14. The system according to any one of claims 9 to 13, wherein, The second program code also includes instructions executable by the second server to: Intercept re-authentication events received in a remote browser; as well as The re-authentication event is communicated to the client browser.

15. The system according to any one of claims 9 to 14, wherein, The first program code also includes instructions that are executable to cause the first server to redirect the client browser to the identity provider based on the determination that the SSO token is not valid.

Images