Application integration using multiple user identities

A method of providing access to digital resources using multiple user identities comprises receiving, from a client application, a first set of authentication tokens that authorize a user to acquire target data provided by a server application. The method further comprises receiving, from the client application, a second set of authentication tokens that authorize the same user to access a connected application. The method further comprises sending, to the server application, a first request to acquire the target data provided by the server application, the first request including the first set of authentication tokens and an identifier of the target data. The method further comprises receiving, from the server application, the target data. The method further comprises sending the target data from the application connector to the connected application in a second request that also includes the second set of authentication tokens.

BACKGROUND

Authentication systems identify an entity. Authorization systems determine rights granted to an entity. In combination, authentication and authorization systems enable efficient and secure management of resources such as physical space, equipment, materials, and logical resources. Logical resources include data storage, software application access, digital services, and user data. Authentication and authorization systems allow individuals to be identified and provided with access to the resources needed to perform their assigned roles and tasks, thereby helping an organization to achieve its goals efficiently and securely.

In the context of logical resource management, an “identity provider” is an entity that creates, maintains, and manages identity information for individual users. Applications, services, and other digital resource providers often outsource their user authentication requirements to a trusted identity provider. Relying on a trusted identity provider for user authentication offers a number of advantages, such as facilitating single sign-on access to multiple resources, enhancing user experience by mitigating password fatigue, and decreasing potential attack surface. A wide range of identity providers have been developed, examples of which include Azure® Active Directory® (provided by Microsoft Corporation (Redmond, WA)), Okta® (provided by Okta, Inc. (San Francisco, CA)), and Citrix Gateway™ (provided by Citrix Systems, Inc. (Fort Lauderdale, FL)).

SUMMARY

In a first example implementation, a method of providing access to digital resources using multiple user identities comprises receiving, by an application connector, from a client application, a first set of authentication tokens that authorize a user of the client application to acquire target data provided by a server application. The method further comprises receiving, by the application connector, from the client application, a second set of authentication tokens that authorize the same user to access a connected application. The method further comprises sending, from the application connector, to the server application, a first request to acquire the target data provided by the server application, the first request including the first set of authentication tokens and an identifier of the target data. The method further comprises receiving, by the application connector, from the server application, the target data. The method further comprises sending the target data from the application connector to the connected application in a second request that also includes the second set of authentication tokens.

In a second example implementation, the user is a member of an organization; the first set of authentication tokens includes a customer identifier that uniquely identifies the organization to the server application; and the second set of authentication tokens includes a tenant identifier that uniquely identifies the organization to the connected application.

In a third example implementation, the first and second sets of authentication tokens are received in a single communication sent from the client application to the application connector.

In a fourth example implementation, the first and second sets of authentication tokens, as well as the identifier of the target data, are received in a single communication sent from the client application to the application connector.

In a fifth example implementation, the method further comprises, before the application connector receives the first and second sets of authentication tokens: receiving, by the application connector, from the client application, an HTTP GET request for a URI path that includes (a) a domain associated with the server application and (b) a ticket that is correlated to a customer identifier that uniquely identifies an organization to the server application, wherein the user is a member of the organization; generating a modified URI path that (a) includes a new domain associated with the organization and (b) excludes the ticket; and sending, from the application connector, to the client application, a redirect to the modified URI path.

In a sixth example implementation, the first set of authentication tokens is issued by a first identity provider that the server application recognizes as having authority to authenticate the user; and the second set of authentication tokens is issued by a second identity provider that the connected application recognizes as having authority to authenticate the user.

In a seventh example implementation, the user is a member of an organization; the first set of authentication tokens includes a customer identifier that uniquely identifies the organization to the server application; the second set of authentication tokens includes a tenant identifier that uniquely identifies the organization to the connected application; the method further comprises validating a mapping between the customer identifier and the tenant identifier; and the application connector receives the mapping from a configuration application.

In an eighth example implementation, a computer system comprises a memory, a network interface, and at least one processor coupled to the memory and the network interface. The processor is configured to receive, from a client application, a first set of authentication tokens that authorize a user of the client application to acquire target data provided by a server application. The processor is further configured to receive, from the client application, a second set of authentication tokens that authorize the same user to access a connected application. The processor is further configured to send, to the server application, a first request to acquire the target data provided by the server application, the first request including the first set of authentication tokens and an identifier of the target data. The processor is further configured to receive, from the server application, the target data. The processor is further configured to send the target data to the connected application in a second request that also includes the second set of authentication tokens.

In a ninth example implementation, the user is a member of an organization; the first set of authentication tokens includes a customer identifier that uniquely identifies the organization to the server application; and the second set of authentication tokens includes a tenant identifier that uniquely identifies the organization to the connected application.

In a tenth example implementation, the first and second sets of authentication tokens are received in a single communication sent from the client application.

In an eleventh example implementation, the first and second sets of authentication tokens, as well as the identifier of the target data, are received in a single communication sent from the client application.

In a twelfth example implementation, the at least one processor is further configured to, before receiving the first and second sets of authentication tokens: receive, from the client application, an HTTP GET request for a URI path that includes (a) a domain associated with the server application and (b) a ticket that is correlated to a customer identifier that uniquely identifies an organization to the server application, wherein the user is a member of the organization; generate a modified URI path that (a) includes a new domain associated with the organization and (b) excludes the ticket; and send, to the client application, a redirect to the modified URI path.

In a thirteenth example implementation, the first set of authentication tokens is issued by a first identity provider that the server application recognizes as having authority to authenticate the user; and the second set of authentication tokens is issued by a second identity provider that the connected application recognizes as having authority to authenticate the user.

In a fourteenth example implementation, the user is a member of an organization; the first set of authentication tokens includes a customer identifier that uniquely identifies the organization to the server application; the second set of authentication tokens includes a tenant identifier that uniquely identifies the organization to the connected application; and the at least one processor is further configured to validate a mapping between the customer identifier and the tenant identifier; and the mapping is received from a configuration application.

In a fifteenth example implementation, a non-transitory computer readable medium storing processor executable instructions to authorize an application connector to access digital resources using multiple user identities. The instructions comprise instructions to receive, from a client application, a first set of authentication tokens that authorize a user of the client application to acquire target data provided by a server application. The instructions further comprise instructions to receive, from the client application, a second set of authentication tokens that authorize the same user to access a connected application. The instructions further comprise instructions to send, to the server application, a first request to acquire the target data provided by the server application, the first request including the first set of authentication tokens and an identifier of the target data. The instructions further comprise instructions to receive, from the server application, the target data. The instructions further comprise instructions to send the target data to the connected application in a second request that also includes the second set of authentication tokens.

In a sixteenth example implementation the user is a member of an organization; the first set of authentication tokens includes a customer identifier that uniquely identifies the organization to the server application; and the second set of authentication tokens includes a tenant identifier that uniquely identifies the organization to the connected application.

In a seventeenth example implementation the first and second sets of authentication tokens are received in a single communication sent from the client application.

In an eighteenth example implementation the first and second sets of authentication tokens, as well as the identifier of the target data, are received in a single communication sent from the client application.

In a nineteenth example implementation the instructions further comprise instructions to, before receiving the first and second sets of authentication tokens: receive, from the client application, an HTTP GET request for a URI path that includes (a) a domain associated with the server application and (b) a ticket that is correlated to a customer identifier that uniquely identifies an organization to the server application, wherein the user is a member of the organization; generate a modified URI path that (a) includes a new domain associated with the organization and (b) excludes the ticket; and send, to the client application, a redirect to the modified URI path.

In a twentieth example implementation the first set of authentication tokens is issued by a first identity provider that the server application recognizes as having authority to authenticate the user; and the second set of authentication tokens is issued by a second identity provider that the connected application recognizes as having authority to authenticate the user.

For purposes of clarity in the figures, the abbreviation “3PY” is used as a shorthand for “third-party”; the abbreviation “WSP” is used as a shorthand for “workspace”; and the abbreviation “ATs” is used as a shorthand for “authentication tokens”.

DETAILED DESCRIPTION

As noted above, applications, services, and other digital resource providers often outsource their user authentication requirements to a trusted identity provider. A wide range of identity providers have been developed, each incorporating different operating parameters, different policies that dictate how users should be authenticated, and different criteria for managing identity information and granting authentication tokens. As a user accesses different resources, he/she may need to be authenticated by corresponding different identity providers, each issuing unique authentication tokens to the user. This will occur where, for example, a resource management system that uses a first identity provider is integrated with a connected application that uses a second identity provider. Disclosed herein are techniques that streamline the process of acquiring authentication tokens from multiple identity providers. This allows a user to send a single request that includes multiple authentication tokens for the corresponding multiple resources that need to be accessed to respond to the user request. More broadly, this facilitates integration between services that require different authentication identities.

System Architecture

FIG.1is a block diagram schematically illustrating selected components of an example system1000for using multiple user identities to integrate functionality provided by multiple digital services. System1000includes, among other things, a workspace application110, a workspace120, an application connector160, and a connected application170. A user uses workspace application110to access resources provided by workspace120and connected application170, each of which may require the user to be authenticated by a different one of multiple identity providers140. Application connector160manages and streamlines access to the target resources using authentication tokens provided by identity providers140. For example, a workspace identity provider142generates workspace authentication tokens142athat allow the user to access resources provided by workspace120. Likewise, a third-party identity provider144generates third-party authentication tokens144athat allow the user to access resources provided by connected application170.FIG.1illustrates a single workspace application110, workspace120, application connector160, and connected application170for the sake of clarity. Other implementations may include any suitable number of workspace applications110, workspaces120, and connected applications170, as well as an appropriate number of corresponding application connectors160and identity providers140.

In general, authentication tokens142a,144aauthenticate the identity of the user of workspace application110and enable identification of resources that the authenticated user is authorized to access. In an example implementation, each set of authentication tokens includes a first token that identifies the user, and a second token that identifies the organization to which the user belongs. Because a set of authentication tokens is specific to a particular resource provider, two sets of authentication tokens that identify the same user (and same corresponding organization) may, in fact, constitute different tokens. As used herein, the terms “customer identifier”, “organization identifier”, and “workspace organization identifier” refer to an identifier of the organization to which a user belongs, as recognized by workspace120. In contrast, as used herein, the term “tenant identifier” refers to an identifier of the organization to which a user belongs, as recognized by connected application170. More generally, the term “tenant” refers to an organization that receives services provided by connected application170, and to which a user of connected application170belongs. Thus workspace authentication tokens142awill be understood as including a customer identifier (or organization identifier), while third-party authentication tokens144awill be understood as including a tenant identifier.

In an example implementation workspace application110comprises a software application that provides content browsing capability. For example, in certain implementations workspace application110may be an HTML5 compliant browser; a software application that includes or otherwise initiates a hosted/embedded browser; or any other software application that is capable of acquiring and displaying digital resources as a result of processing a uniform resource identifier (URI). Workspace application110provides session storage112for temporary storage of, for example, authentication tokens used during a given browsing session in a given browser window or tab. Data stored in session storage112disappears when a browsing session ends, for example, as will occur when a browser window or tab is closed. Workspace application110is also capable of providing a login interface114through which an authentication workflow can be performed. Such an authentication workflow may involve two-way communications with one or more of identity providers140, wherein such communications result in receipt of workspace authentication tokens142aand/or third-party authentication tokens144aupon successful authentication of the user. Workspace application110is executed on any suitable computing device, examples of which include desktop computers, laptop computers, tablet computers, and smartphones.

In an example implementation, workspace120is a digital resource management system such as Citrix Workspace™ (provided by Citrix Systems, Inc. (Fort Lauderdale, FL)). Workspace120is capable of providing a wide range of digital resources from networked locations, and may include systems or services for providing workspace application110with access to virtual applications, virtual desktops, file repositories, file sharing systems, secure browser services, and application management services. Workspace120may be located within an on-premises data center of an organization for which system1000is deployed, within a cloud computing environment, or elsewhere. Example cloud computing environments that may support implementation of workspace120include Microsoft Azure® Cloud (provided by Microsoft Corporation (Redmond, WA)), Amazon Web Services® (provided by Amazon.com, Inc. (Seattle, WA)), Google Cloud™ (provided by Google LLC (Mountain View, CA)), and IBM Cloud® (provided by International Business Machines Corporation (Armonk, NY)).

In some embodiments workspace application110and workspace120are implemented in a client-server relationship wherein digital resources are served from workspace120(server) to workspace application110(client). Thus workspace application110may also be referred to herein as a “client application” and workspace120may also be referred to herein as a “server application”.

Connected application170refers generally to any application capable of integrating with, and connecting to, workspace120, but that uses a different identity provider than that used by workspace120. Connected applications may include, for example, software-as-a-service (SaaS) applications, web applications, desktop applications, and Linux® applications. In one example implementation, connected application170is a collaboration platform such as Microsoft Teams® (provided by Microsoft Corporation (Redmond, WA)), although other SaaS applications, such as other Office 365° applications (provided by Microsoft Corporation (Redmond, WA)), may be used in other implementations. Thus, using the example workspaces120and connected applications170disclosed herein, certain implementations would enable a Citrix Workspace™ user to send notifications to Microsoft Teams®, even though these two resources require the user to be authenticated by different identity providers. However, it should be appreciated that the workspaces and applications disclosed herein are provided by way of example only, and that, in general, workspace application110can be configured to access resources provided by any suitable workspace120and/or connected application170.

As noted above, application connector160manages and streamlines access to resources provided by workspace120and connected application170. Application connector160employs authentication tokens provided by appropriate identity providers140to authenticate the user of workspace application110and, following authentication, identify resources that the user is authorized to access. Application connector160can be understood as being a cloud-based software service that enables local processes, for instance using injected code that is specific to workspace120. For example, in certain implementations the injected code enables the communication sequences illustrated inFIGS.3A through3FandFIGS.4A through4C, as will be described in greater detail below. This allows application connector160to become part of a virtualization infrastructure of workspace120that provides access to resources associated with connected application170. Application connector160therefore has a degree of extensibility that allows it to be adapted for use with a wide range of connected applications170.

In some implementations, application connector160uses one or more configuration services150to identify resources that a particular user is authorized to access and to verify that resources are allowed to be shared between particular services, such as between a particular workspace120and a particular connected application170. For example, in one implementation configuration services150verify an established mapping between workspace authentication tokens142aand third-party authentication tokens144a. In some cases configuration services150include one or more of a workspace cloud configuration152, a workspace ticketing module154, and/or a workspace configuration user interface156. The particular configuration services150illustrated inFIG.1will be described in greater detail in conjunction with the communication sequences illustrated inFIGS.3A through3FandFIGS.4A through4C. Configuration services150may be individually or collectively referred to herein as a “configuration application”. In some implementations application connector160sends appropriate authentication tokens to a gateway service, while in other implementations application connector160sends the authentication tokens directly to a corresponding resource provider, such as workspace120and/or connected application170.

FIG.1illustrates multiple identity providers140, including for example workspace identity provider142that generates workspace authentication tokens142athat allow the user to access resources provided by workspace120; and third-party identity provider144that generates third-party authentication tokens144athat allow the user to access resources provided by connected application170. The different identity providers140may be deployed in different locations, for example on the premises of the organization for which identity services are provided. In some implementations one or more of identity providers140is a cloud-based service such as Azure® Active Directory®. In some cases an identity provider is capable of receiving and responding to a sign-on request transmitted from login interface114of workspace application110.

Integration with Microapp Services

In some applications, workspace application110may present a user with a list of resources that are available via workspace120and/or one or more connected applications170. Additionally or alternatively, workspace application110may provide a user with access to a streamlined feed of event notifications and/or available actions that may be taken with respect to detected events. Such an “activity feed”, which may be user-customized, allows users to monitor important activity involving relevant resources, including resources available via workspace120, resources available via one or more connected applications170, virtual desktop resources, and networked storage resources. In some implementations, the activity feed allows a user to access resources through a single interface, referred to in some applications as a “notification card”, without needing to switch context from one resource to another. Further, event notifications in the activity feed may be accompanied by a discrete set of user-interface elements, such as “approve”, “deny”, and “see more detail” buttons, that allow a user to take one or more simple actions with respect to a reported event. Enabling such actions to be taken from within a notification card interface allows a user to avoid context switching in many instances.

In some embodiments, an activity feed may be enabled by one or more micro-applications, also referred to as “microapps”, that can interface with underlying associated resources using, for example, an application programming interface (API). The responsive actions may be user-initiated actions that are taken within a microapp and that provide inputs to the underlying applications through the API. The actions a user performs within a microapp may, for example, be designed to address specific common problems and use cases quickly and easily, adding to increased user productivity. Examples of such actions include responding to a vacation request, submitting a help desk ticket, approving an expense report, and responding to a new course registration announcement. Microapp notifications may be displayed via an interface provided by workspace application110, thereby notifying a user of something that requires attention.

In this context, a microapp can be understood as a single use case made available to users to streamline functionality from complex enterprise applications. Microapps may, for example, use APIs available within SaaS, web, or proprietary applications, thereby allowing users to see content without needing a full launch of the application or needing to switch focus to the application. Absent such microapps, users would need to launch an application, navigate to the desired action, and invoke the action. Microapps may therefore streamline routine tasks for frequently performed actions and provide users the ability to perform actions from within workspace application110without having to launch or switch context to a separate native application. Microapps allow workspace application110to aggregate relevant notifications, tasks, and insights, thus providing the user with a dynamic productivity tool.

In some embodiments, workspace120includes a microapp service that can intelligently populate a user's resource activity feed by using machine learning and artificial intelligence algorithms. Further, in some implementations, microapps may be configured by an administrator of workspace120, thus giving the administrator a powerful tool to create more productive workflows without requiring additional infrastructure. Whether pushed to a user or initiated by a user, microapps may provide shortcuts that simplify and streamline key tasks that would otherwise require launching or switching context to full enterprise applications. In some embodiments, out-of-the-box templates allow administrators with API account permissions to build microapp solutions targeted for their needs. Administrators may also, in some embodiments, be provided with tools to build custom microapps.

FIG.5is a block diagram schematically illustrating specific resource management services502that, in certain implementations, may be incorporated into or otherwise provided by workspace120. One or more of resource management services502support the provision of a streamlined resource activity feed and/or notification process for a user of workspace application110. Correspondingly, workspace application110can leverage one or more of resource management services502to provide a user with a personalized and integrated interface that enables seamless access to one or more external resources528that the user is authorized to access, including virtual workspaces, connected applications170, and data storage resources. Example resource management services502include, but are not limited to, a client interface service516, a microapp service530, a data integration provider service532, a credential wallet service534, an active data cache service536, an analytics service538, and a notification service540. Client interface service516is configured to send a sign-on request to one or more of identity providers140, optionally via workspace application110. Each of resource management services502may be located within an on-premises data center of an organization for which system1000is deployed, within one or more cloud computing environments, or elsewhere.

External resources528include applications and/or other resources that workspace120can leverage. Microapps can leverage external resources528via corresponding APIs. External resources528can be hosted on-premises or within a cloud computing environment. Connectors with out-of-the-box templates for frequently-used applications may be provided by default. Integration with other applications may additionally or alternatively be configured through a microapp page builder. A microapp page builder may, for example, connect to legacy, on-premises, and SaaS systems by creating streamlined user workflows via customized microapp actions. To implement such integrations, workspace120, and in particular data integration provider service532, may, for example, support representation state transfer APIs, JavaScript® Object Notation (JSON), Open Data Protocol JSON, and 6connect Markup Language (6ML™). Data integration provider service532may interact with external resources528to decrypt end user credentials. Data integration provider service532can also be configured to write back to external resources528under the identity of the user, for example using OAuth 2.0 or a suitable service account. The write-back actions may use the user's actual account to ensure that all actions performed are compliant with data policies of the interacting application or resource.

Still referring to the resource management services502illustrated inFIG.5, microapp service530may be a single-tenant service responsible for creating, administering, and implementing microapps. Microapp service530may, for example, periodically pull active data from external resources528via data integration provider service532and send the resulting raw events to analytics service538. Analytics service538processes the raw events to create targeted, scored notifications. Such notifications are sent to notification service540, which is configured to process and store the notifications in a database from which they can be served in a notification feed at an appropriate time. In other implementations, notification service540may additionally or alternatively send the notifications to workspace application110immediately as a push notification that is provided via client interface service516. Active data cache service536optionally provides a single-tenant service that stores configuration information and microapp data using, for example, a per-tenant database encryption key and per-tenant database credentials. Credential wallet service534stores encrypted service credentials and OAuth 2.0 authentication tokens for external resources528. In an alternative implementation authentication tokens are stored in session storage112of workspace application110. Details with respect to how authentication tokens can be acquired from multiple different identity providers will be disclosed in turn.

An example process for synchronizing workspace120with external resources528, and for generating resulting notifications as appropriate, may operate as follows. Microapp service530retrieves encrypted service account credentials for external resources528from credential wallet service534and requests synchronization with data integration provider service532. Data integration provider service532decrypts the service account credentials and uses those credentials to retrieve data from external resources528. Data integration provider service532then streams the retrieved data to microapp service530. Microapp service530stores the received data in active data cache service536and sends raw events to analytics service538. Analytics service538creates targeted scored notifications and sends the notifications to notification service540. Notification service540stores the notifications in a database to be served in a notification feed at an appropriate time. Alternatively, notification service540sends the notifications to workspace application110immediately as a push notification that is provided via client interface service516. Upon receiving the notification, workspace application110can render the received information in an interactive notification card that includes graphical elements, textual content, and/or interactive user interface elements.

An example process for processing a user-initiated action via a microapp may operate as follows. A notification card is rendered at workspace application110that alerts of an outstanding action, such as a newly received vacation request, help desk ticket, expense report, or course registration announcement. The notification card may include user interface elements that allow the user to respond immediately, such as “approve”, “deny”, or “see more detail” buttons. When the user invokes an action from the notification card interface, workspace application110sends the user's requested action (for example, “approve expense report”) to microapp service530via client interface service516. Microapp service530then retrieves, from credential wallet service534, an encrypted OAuth 2.0 token for one or more external resources that are required to complete the action. Microapp service530sends the action to data integration provider service532together with the encrypted OAuth 2.0 token. Data integration provider service532decrypts the OAuth 2.0 token and sends the action to the appropriate external resource under the user's identity. Data integration provider service532then reads back, from the external resource, response data that the external resource generates as a result of completing the requested action. Data integration provider service532sends the response data to microapp service530, which in turn updates active data cache service536and causes a message to be sent to workspace application110via client interface service516. The response data may, for example, notify the user with respect to whether the requested action was successfully completed and provide the user with any data generated as a result of completing (or attempting to complete) the action.

In some embodiments, in addition to or in lieu of the functionality described above, workspace120may provide users the ability to search for relevant information across files and applications, including in external resources528. For example, a simple keyword search may be used to find application resources, SaaS applications, virtual desktops, files, and the like. This functionality may enhance user productivity and efficiency as application and data sprawl is prevalent across many organizations.

In some embodiments, in addition to or in lieu of the functionality described above, workspace120may support virtual assistance functionality that allows users to enhance productivity and take quick actions. Users may, for example, interact with a “Virtual Assistant” provided by workspace application110to ask questions such as “What is Bob Smith's phone number?” or “What absences are pending my approval?”. Workspace application110may parse requests such as these and respond based on information provided via workspace120and/or external resources528, such as Microsoft Teams®. This may help employees to work efficiently, stay organized, and deliver only the specific information that is sought in a given instance.

Methodology

As noted above, a wide range of identity providers have been developed, each incorporating different operating parameters, different policies that dictate how users should be authenticated, and different criteria for managing identity information and granting authentication tokens. Different resource providers may require authentication tokens issued by different identity providers. Thus, a user who wishes to access resources from different resource providers may need to authenticate himself/herself with different identity providers, each issuing unique authentication tokens to the user. Often a single task will require accessing resources from multiple identity providers, meaning that multiple sets of authentication tokens will be required to complete even a single task. Disclosed herein are methods that streamline the process of acquiring multiple sets of authentication tokens from multiple identity providers, and then using those multiple sets of authentication tokens to complete a task within the context of a digital workspace.

FIG.2is a flowchart illustrating an example method2000for acquiring and using multiple user identities to integrate functionality provided by multiple digital services. Method2000, which can be invoked using the system illustrated inFIG.1, provides a secure way to integrate services provided by workspace120and connected application170, which in general, may require authentication by two different identity providers. Such integration allows a user to invoke compound operations that require the user to be successfully authenticated to both workspace120and connected application170. In particular, such compound operations can be invoked using authentication tokens issued by respective APIs that are dependent on a particular identity provider.

Certain of the techniques disclosed herein also provide a method to enforce the use of related identities from different identity providers at a particular endpoint, such as at workspace application110. In particular, the identity of the user can be enforced through a mapping of a customer identifier associated with workspace authentication tokens142ato a tenant identifier associated with third-party authentication tokens144a. Such mapping can be administered by configuration services150illustrated inFIG.1. Such a mapping helps to enhance security by providing a way to (a) prevent an inconsistent pair of accounts from attempting to share resources, and (b) ensure that the accounts used to share resources also share the same user scope. For even further security, a mapping between customer and tenant identifiers can optionally be extended to include user account mapping, for example using a user's email address, principal name, object identifier, or any other suitable unique user identifier.

As disclosed previously, in one specific implementation the functionality associated with workspace120is provided by Citrix Workspace™ and the functionality associated with connected application170is provided by Microsoft Teams®. As part of the integration of these two services, Citrix Workspace™ enables users to send workspace notification cards to Microsoft Teams®. This “Send to Teams” operation, which could for example be invoked via a microapp notification card displayed at workspace application110, requires the user to be authenticated by two different identity providers. In particular, Citrix Workspace™ requires the user to be authenticated by Citrix Gateway™ while Microsoft Teams® requires the user to be authenticated by Azure® Active Directory®. The techniques disclosed herein allow a user to acquire a first set of authentication tokens for Citrix Gateway™ (that is, workspace authentication tokens142a) and a second set of authentication tokens for Microsoft Teams® (that is, third-party authentication tokens144a), such that when the user invokes the aforementioned “Send to Teams” operation, both sets of authentication tokens can be included in the request. This effectively allows workspace application110to leverage multiple different identity providers. As noted above, configuration services150can be used to ensure that a user who authenticates with the multiple different identity providers is a member of a commonly-recognized organization, as defined by the mapping between the customer and tenant identifiers included in the authentication tokens. This helps to prevent an inconsistent pair of accounts from sharing resources.

Referring again toFIG.2, method2000can be implemented, for example, using the system1000illustrated inFIG.1and described herein, and in particular, using functionality provided by workspace application110and application connector160. However other system architectures and components can be used in other implementations. To this end, the correlation of the various functionalities shown inFIG.2to workspace application110or workspace connector160is not intended to imply any structural or use limitations. Rather, other implementations may include, for example, varying degrees of integration wherein certain functionalities are effectively performed by different components. For example, in an alternative implementation application connector160may be integrated into workspace120, optionally using one or more resource management services502illustrated inFIG.5. Thus other implementations may have fewer or more components depending on the granularity of a particular implementation. As can be seen, method2000includes a number of phases and sub-processes, the sequence of which may vary from one implementation to another. However, when considered in the aggregate, these phases and sub-processes are capable of acquiring and using multiple user identities to integrate functionality provided by multiple digital services.

Method2000can be understood as being initiated by a user who has already used workspace application110to authenticate himself/herself with workspace120, meaning that the user already possesses workspace authentication tokens142aissued by workspace identity provider142. For example, where the functionality associated with workspace120is provided by Citrix Workspace™ and the user is authenticated by Citrix Gateway″, then workspace authentication tokens142amay comprise DS-Auth tokens stored in session storage112of workspace application110. In other implementations OAuth 2.0 is used to authenticate the user with workspace120. This prior authentication is represented inFIG.1by workspace authentication tokens142apositioned on an arrow from workspace identity provider142to workspace application110. Once workspace application110holds workspace authentication tokens142a, the user can access resources provided by workspace120, as represented inFIG.1by workspace authentication tokens142apositioned on an arrow from workspace application110to workspace120.

Thus, in one implementation method2000can be understood as beginning when a previously authenticated user invokes a command via workspace application110, wherein the command represents a request to send data from workspace120to connected application170. See reference numeral210inFIG.2. One example of such a command is the “Send to Teams” operation described above. More specifically, a notification card generated by a microapp may present a user with new data (for example, new contact information), and may further include a “Send to Teams” button that allows the user to share the new data provided on the notification card with colleagues using Microsoft Teams®. While this particular example command involves data flowing in a particular direction (from workspace120to connected application170), in general the command may represent any request that requires the user to be authenticated by multiple identity providers, regardless of the direction of data flow. Thus other implementations may involve data being sent from, for example, connected application170to workspace120and/or workspace application110.

Upon receiving the command, workspace application110initiates authentication of the user with third-party identity provider144, for example using OAuth 2.0. See reference numeral220inFIG.2. OAuth 2.0, as described in Request for Comments (RFC) 6479 and RFC 8252, enables an application to obtain secure, limited access to a user's protected resources, such as a user's data, without requiring the user to provide a password to the application. In the context of the example “Send to Teams” operation described above, workspace application110may use login interface114to initiate an authentication session with Azure® Active Directory®, which is the identity provider used by Microsoft Teams®. This can be accomplished using an OAuth 2.0 implicit flow wherein the workspace application110receives an access token at the conclusion of a successful authentication session. These authentication tokens can be used to access the Microsoft Graph API using application connector160, which in turn allows the user to access Microsoft Cloud service resources, including Microsoft Teams® services. This subsequent authentication is represented inFIG.1by third-party authentication tokens144apositioned on an arrow from third-party identity provider144to workspace application110.

Once the user has been successfully authenticated by third-party identity provider144, application connector160acquires the identification and access tokens that form third-party authentication tokens144a. See reference numeral230inFIG.2. Application connector160then leverages configuration services150to verify a mapping between the previously acquired workspace authentication tokens142aand the newly-acquired third-party authentication tokens144a. See reference numeral240inFIG.2. The verified mapping can be represented as follows:workspace account↔workspace organization↔tenant↔tenant account
This mapping recognizes that workspace identity provider142and third-party identity provider144authenticate the same user, but nevertheless generate different tokens configured to be accepted by different entities (that is, workspace120and connected application170). For example, each set of authentication tokens may include a token that identifies the organization to which the user belongs. But because a given set of authentication tokens is specific to a particular resource provider, two sets of authentication tokens that identify the same user (and same corresponding organization) may, in fact, constitute different tokens. For example, workspace authentication tokens142amay include a customer identifier that identifies the organization to which the user belongs, as recognized by workspace120. And third-party authentication tokens144amay include a tenant identifier that identifies that same organization, as recognized by connected application170. These different identifiers of the same organization are linked by the “workspace organization↔tenant” preconfigured relationship.

Once the mapping between the workspace organization and tenant have been verified, third-party authentication tokens144acan be validated against this mapping. See reference numeral245inFIG.2. Validating the tokens helps to enhance security by providing a way to (a) prevent an inconsistent pair of accounts from attempting to share resources, and (b) ensure that the accounts used to share resources also share the same user scope. For example, this validation operation helps to protect against token substitution by workspace application110. For even further security, a mapping between customer and tenant identifiers can optionally be extended to include user account mapping, for example using a user's email address, principal name, object identifier, or any other suitable unique user identifier.

In certain embodiments workspace configuration user interface156(illustrated inFIG.1) provides a tool that an administrator can use to configure application connector160, and in particular, to define the “workspace organization↔tenant” mapping. This mapping is based on a recognition that two particular resource providers (for example, workspace120and connected application170) may share resources to an authenticated user of a particular organization. This organizational-level mapping ensures that the authentications provided by workspace identity provider142and third-party identity provider144link two different resource providers. This is intended to prevent authentications issued to one organization from leaking information into a different organization.

Referring still toFIG.2, after validating the mapping between the user's identity as authenticated by different identity providers, third-party authentication tokens144aare returned to login interface114of workspace application110. See reference numeral250inFIG.2. This may include steps to ensure that third-party authentication tokens144aare returned to the correct workspace domain to protect against the tokens falling into unauthorized hands, as will be discussed in greater detail below. Third-party authentication tokens144acan be stored in session storage112of workspace application110. When the user later generates a request that requires authenticated access to both workspace120and connected application170, the workspace authentication tokens142aand third-party authentication tokens144acan be retrieved from session storage112. Once the workspace application110has access to authentication tokens issued by multiple identity providers140, the workspace application110can make various calls to application connector160that result in an API producing a URI that connected application170can recognize as indicating that the holder can access particular resources. As a security measure, data stored in session storage112disappears when a browsing session ends, for example, as will occur when a browser window or tab is closed. This helps to deter unauthorized use of authentication tokens stored at workspace application110.

At some point workspace application110can be used to generate a request that requires authenticated access to both workspace120and connected application170. Such request can be sent to application connector160along with workspace authentication tokens142aand third-party authentication tokens144a. See reference numeral260inFIG.2. This request is represented inFIG.1by workspace authentication tokens142aand third-party authentication tokens144apositioned on an arrow from workspace application110to application connector160. This request can be generated, for example, as a result of user interaction with a notification card generated by a microapp, such as when the user receives a notification card announcing new contact information for a key vendor and the user responds to such notification by selecting a “Send to Teams” button on the notification card. A wide range of other requests may likewise require authenticated access to both workspace120and connected application170, and thus it should be appreciated that such request does not necessarily involve data flow in a particular direction or between particular applications.

Upon receiving the request, application connector160acquires the requested data from workspace120using workspace authentication tokens142a. See reference numeral270inFIG.2. This acquisition is represented inFIG.1by workspace authentication tokens142apositioned on an arrow from workspace connector160to workspace120. Workspace authentication tokens142aoptionally include additional data, referred to as “universal claims”, that helps to identify the organization associated with the authenticated user. This enables application connector160to extract additional information regarding the notification card from which the user's request was generated. In certain embodiments this additional information is acquired from notification service540provided at workspace120. After workspace120returns the requested data, application connector160sends the data to connected application170using third-party authentication tokens144a. See reference numeral280inFIG.2. Application connector160can accomplish this by generating a “card” based on the notification details obtained from workspace120, and by further calling an API implemented with connected application170that causes the card to be shared to connected application170. For example, where connected application170is Microsoft Teams®, application connector160calls the Microsoft Graph API to share the card to Microsoft Teams®. Third-party authentication tokens144aare also passed to connected application170to establish the user's identity and authority. This data transmission is represented inFIG.1by third-party authentication tokens144apositioned on an arrow from workspace connector160to connected application170.

Data Flows—Using Customer Identifier

FIGS.3A through3Fcomprise a sequence diagram schematically illustrating selected communication sequences that occur in an example technique for acquiring and using multiple user identities to integrate functionality provided by multiple digital services. More specifically, the communication sequences illustrated inFIGS.3A through3Finvolve transmitting a customer identifier between login interface114and third-party identity provider144. The communication sequences illustrated inFIGS.3A through3Fcan be used to implement the method2000illustrated inFIG.2. As noted above, method2000can be understood as being initiated by a user who has already used workspace application110to authenticate himself/herself with workspace120, meaning that the user already possesses workspace authentication tokens142aissued by workspace identity provider142. For example, where the functionality associated with workspace120is provided by Citrix Workspace™ and the user is authenticated by Citrix Gateway™, then workspace authentication tokens142amay comprise DS-Auth tokens stored in session storage112of workspace application110.

Given the foregoing, the communication sequences illustrated inFIGS.3A through3Fcan be understood as being triggered when an authenticated user of workspace120uses workspace application110to issue a command that requires the user to be authenticated by both workspace identity provider142and third-party identity provider144. See reference numeral301inFIG.3A. Such command may be referred to herein as the “trigger command”. Fulfilling the trigger command involves accessing resources provided by both workspace120and connected application170, each of which require the user to be authenticated by a different identity provider140. One example of a trigger command is the aforementioned “Send to Teams” command that may be issued when a user of Citrix Workspace™ wishes to send information to collaborators using Microsoft Teams®. The user may issue the trigger command in response to workspace application110presenting the user with a notification card that was generated by a microapp. While this particular example trigger command involves data flowing in a particular direction (from workspace120to connected application170), in general the trigger command may represent any request that requires the user to be authenticated by multiple identity providers140, regardless of the direction of data flow.

Upon receipt of the trigger command, workspace application110attempts to acquire third-party authentication tokens144afrom session storage112. See reference numeral302inFIG.3A. Session storage112responds to such request by either returning the requested third-party authentication tokens144a, or returning a message that such tokens do not exist, are expired, or are otherwise unavailable. See reference numeral303inFIG.3A. Third-party authentication tokens144amay already exist in session storage112, for example because method2000was previously performed using the same browser tab or window of workspace application110. In general, data stored in session storage112disappears when a browsing session ends, for example, as will occur when a browser window or tab is closed.

Upon receiving the response form session storage112, workspace application110determines whether valid third-party authentication tokens144awere received. See reference numeral304inFIG.3A. For example, in certain implementations authentication tokens may be subject to expiration, and thus even if session storage112returns authentication tokens, such tokens would not be considered “valid” if they have previously expired. If valid third-party authentication tokens144aare received, workspace application110can send such tokens to application connector160with the trigger command, as will be described in greater detail in turn (see reference numeral329inFIG.3E).

However, if valid third-party authentication tokens144aare not received, workspace application110can be configured to open login interface114. See reference numeral305inFIG.3A. This can be accomplished by, for example, opening a new browser tab. Once opened, login interface114initiates authentication of the user via third-party identity provider144. See reference numeral306inFIG.3A. This can be understood as sending a request for third-party authentication tokens144afrom login interface114to third-party identity provider144. Upon receiving the request, third-party identity provider144authenticates the user via a suitable authentication protocol, one example of which is OAuth 2.0. See reference numeral307inFIG.3A. Regardless of the particular protocol used, authentication of the user may require multiple back-and-forth communications between login interface114and third-party identity provider144. These individual communications are not separately illustrated inFIG.3Afor clarity. Similarly, depending on the particular authentication protocol used and the configuration of third-party identity provider144, multifactor authentication may be required, for example using an additional token sent to the user via a different communication channel, such as by text message, email, telephone call, or mobile application.

If the user fails to complete all authentication requirements imposed by the applicable authentication protocol, third-party identity provider144may return an authentication failure message to login interface114. On the other hand, if the user is able to successfully complete all authentication requirements, third-party identity provider144establishes that the user is successfully authenticated. See reference numeral308inFIG.3A. In this case, third-party identity provider144returns a redirect to login interface114. See reference numeral309inFIG.3B. A redirect is returned because third-party identity provider144expects to be communicating with a browser. An example of such a redirect is as follows:

This example redirect includes a common “base URI” (“http://connector.example.com/handle3PYRedirect/”) and a “hash fragment” (the portion of the redirect following the base URI and beginning with the # symbol). The hash fragment comprises a plurality of name-value pairs. Specifically, the “access token=EFGH” name-value pair form the third-party authentication tokens144aestablishes that the user has been authenticated by third-party identity provider144. The “client_info=XYZ” name-value pair identifies the requesting browser that is authorized to access resources of connected application170, that is, workspace application110. The “state=customerid” name-value pair allows additional information to be passed under the OAuth 2.0 standard. In this example implementation, the user's customer identifier (“customerid”) is provided in this field. The hash fragment may additionally or alternatively contain other name-value pairs such as an expiration timestamp or a token scope value. In such embodiments the hash fragment is not actually transmitted to workspace120, but is instead retained at login interface114, thus further enhancing security.

Applications that use OAuth 2.0 expect to receive redirect calls. However, to enhance security and limit scope, such applications typically only allow redirects from a relatively small preconfigured set of whitelisted URIs. For instance, the example redirect provided above includes the whitelisted base URI “connector.example.com/handle3PYRedirect”. In general, it may be desired to use a different base URI in subsequent communications. Thus, upon receiving the redirect, login interface114responds by sending a first GET request to application connector160. See reference numeral310inFIG.3B. An example of such a first GET request is as follows:GET https://connector.example.com/handle3PYRedirect
Thus, in certain embodiments the first GET request includes the base URI included in the redirect that was received from the third-party identity provider144. This notifies application connector160that workspace application110has acquired authentication tokens from third-party identity provider144, but that further processing is requested, as will be explained in turn. This first GET request, when processed by application connector160, causes application connector160to return executable code to login interface114. See reference numeral311inFIG.3B. This executable code, which in certain implementations may comprise a JavaScript® element, is injected into login interface114. When executed, it causes the “customerid” value to be extracted from the hash fragment included in the redirect that was received from third-party identity provider144.

Login interface114executes the received code and extracts the “customerid” value from the hash fragment. See reference numeral312inFIG.3B. Login interface114then sends a second GET request to application connector160. See reference numeral314inFIG.3B. An example of such a second GET request is as follows:

https://connector.example.com/handle3PYRedirect/customerid#access_token=EFGH&client_info=XYZ&state=customerid
As can be seen, this second GET request is similar to the redirect received from third-party identity provider144, except that the “customerid” value has been appended to the base URI.

Upon receiving this second GET request, application connector160initiates a process for verifying a mapping between the previously acquired workspace authentication tokens142aand third-party authentication tokens144a. As explained above, this mapping can be represented as follows:workspace account↔workspace organization↔tenant↔tenant account
This mapping recognizes that workspace identity provider142and third-party identity provider144authenticate the same user, but nevertheless generate different tokens configured to be accepted by different entities (that is, workspace120and connected application170). Application connector160initiates this mapping verification subprocess by requesting, from workspace cloud configuration152, the mapping between the workspace organization and the tenant (that is, “workspace organization↔tenant”, as represented above). See reference numeral315inFIG.3B. In certain implementations workspace cloud configuration152forms a part of workspace120, and is defined when an organization is first onboarded as an organizational user of workspace120. Workspace cloud configuration152can be understood as mapping to third-party identity provider144. Thus, if a particular customer identifier is provided to workspace cloud configuration152, the corresponding tenant can be identified.

Workspace cloud configuration152responds by sending the requested mapping to application connector160. See reference numeral316inFIG.3C. Workspace connector160makes a determination with respect to whether the received mapping is valid. See reference numeral317inFIG.3C. Such validation can be based on validated mappings between workspace organizations and tenants, as saved at application connector160. Such validated mapping can be defined, for example by an administrator using workspace configuration user interface156. This organizational-level mapping ensures that the authentications provided by workspace identity provider142and third-party identity provider144also identify a specific subset of users at the organizational level. This is intended to prevent authentications issued to one organization from leaking information into a different organization. If application connector160cannot validate the mapping received from workspace cloud configuration152, the process can be terminated and an error message can be returned to login interface114.

As described above, the relationship between the previously acquired workspace authentication tokens142aand third-party authentication tokens144acan be verified using the mapping between the workspace organization and the tenant. However in alternative implementations additional or alternative identifiers could be used for the same purpose. For example, in an alternative implementation the tenant identifier is sent to application connector160to further strengthen the validation of the authentication scope. Likewise, in alternative implementations additional account mappings configured by an administrator of the workspace organization can be used to strengthen the validation as well.

If application connector160can validate the mapping, application connector160requests the organization domain name (for example, “CustomerName.example.com”) from workspace cloud configuration152. See reference numeral318inFIG.3C. Workspace cloud configuration152returns the requested domain name to application connector160. See reference numeral319inFIG.3C. Upon receiving the domain name, application connector160uses the domain name to generate and send a redirect to login interface114. See reference numeral320inFIG.3C. An example of such a redirect is as follows:

https://CustomerName.example.com/Store/Web/#access_token=EFGH&client_info=XYZ&state=(customerid)
This redirect includes a hash fragment that, in turn, includes the validated third-party authentication tokens144a(the “access token=EFGH” name-value pair). Login interface114recognizes this redirect by virtue of the matching hash fragment.

In response to receiving the redirect, login interface114uses the redirect to generate and send a third GET request to workspace120. See reference numeral321inFIG.3D. An example of such a third GET request is as follows:

https://CustomerName.example.com/Store/Web/#access_token=EFGH&client_info=XYZ&state=(customerid)
This third GET request, when processed by workspace120, causes workspace120to return executable code to login interface114. See reference numeral322inFIG.3D. This executable code, which in certain implementations may comprise a JavaScript® element, is injected into login interface114. When executed, it causes the third-party authentication tokens144ato be extracted from the hash fragment included in the redirect that was received from application connector160.

Login interface114executes the received code, parses the hash fragment, and extracts the third-party authentication tokens144a. See reference numeral323inFIG.3D. The extracted third-party authentication tokens144acan then be stored in session storage112. See reference numeral324inFIG.3D. To successfully store third-party authentication tokens144ain the correct session storage112, the page domain of login interface114should be the same as the page domain of the browser window provided by workspace application110. The organization domain name retrieved from workspace cloud configuration152provides this link. Once third-party authentication tokens144aare stored in session storage112, login interface114can be closed. See reference numeral325inFIG.3E.

In certain implementations workspace application110is configured to detect that login interface114has been closed. See reference numeral326inFIG.3E. In such implementations this triggers workspace application110to once again attempt to acquire third-party authentication tokens144afrom session storage112. See reference numeral327inFIG.3E. In this case, session storage112is able to return third-party authentication tokens144ato workspace application110. See reference numeral328inFIG.3E. Workspace application110is now able to fulfill the user's original trigger command, that is, the command that requires the user to be authenticated by both workspace identity provider142and third-party identity provider144. Workspace application110thus sends the trigger command to application connector160in a communication that includes both workspace authentication tokens142aand third-party authentication tokens144a. See reference numeral329inFIG.3E. This request is represented inFIG.1by workspace authentication tokens142aand third-party authentication tokens144apositioned on an arrow from workspace application110to application connector160.

Upon receiving the trigger command, application connector160can be configured to validate the received authentication tokens. See reference numeral330inFIG.3E. In particular, because the request received from workspace application110includes authentication tokens for both workspace application110and connected application170, application connector160is able to perform additional validation that normally would not be possible vis-à-vis a request including authentication tokens associated with a single entity. In particular, authentication tokens issued by different identity providers140can be validated not only on the basis of their inherent characteristics (for example, each individual token not expired), but also on the basis of their relationship between each other. This relationship can be validated regardless of the fact that the tokens were issued by different identity providers140.

Application connector160can extract identifiers for the workspace organization and the tenant from the workspace authentication tokens142aand the third-party authentication tokens144a, respectively. In some implementations these identifiers are verified against a whitelisted mapping stored at application connector160. Additionally or alternatively, application connector160can request a whitelisted mapping between workspace organization and tenant identifiers from workspace cloud configuration152(that is, “workspace organization↔tenant”, as represented above). See reference numeral331inFIG.3E. Workspace cloud configuration152responds by sending the requested mapping. See reference numeral332inFIG.3F. This allows application connector160to validate the mapping. See reference numeral333inFIG.3F. Regardless of how the authentication tokens are validated, such validation provides an additional layer of protection against malicious attacks, for example based on attempted spoofing of the authentication tokens. This additional layer of protection would not be possible in a framework relying on authentication tokens issued by a single identity provider.

Once the authentication tokens are validated against each other, application connector160requests target data from workspace120using workspace authentication tokens142a. See reference numeral334inFIG.3F. In this context, “target data” refers to a resource provided by workspace120that needs to be accessed to fulfill the user's original trigger command. Referring again to the aforementioned application wherein the user has executed a “Send to Teams” command, the target data would refer to the data that the user desires to send to Microsoft Teams®. This request sent to workspace120is represented inFIG.1by workspace authentication tokens142apositioned on an arrow from workspace connector160to workspace120. Upon receiving the request, workspace120validates the received workspace authentication tokens142aand sends the requested data to application connector160. See reference numeral335inFIG.3F.

Application connector160can send the data received from workspace120to connected application170in a communication that includes third-party authentication tokens144a. See reference numeral336inFIG.3F. This data transmission is represented inFIG.1by third-party authentication tokens144apositioned on an arrow from workspace connector160to connected application170. Connected application170validates the received third-party authentication tokens144aand processes the received data under the user's identity. Upon successfully validating the authentication tokens and processing the received data, connected application170can return an operation success notification to application connector160. See reference numeral337inFIG.3F. Application connector160can, in turn, return an operation success notification to workspace application110. See reference numeral338inFIG.3F. Workspace authentication tokens142aand third-party authentication tokens144aare optionally retained in session storage112in the event that the user invokes additional commands that require both sets of tokens. Data stored in session storage112will disappear when the user's browsing session ends, for example, as will occur when the browser window or tab is closed.

Data Flows—Hidden Customer Identifier

The communication sequence described above with respect toFIGS.3A through3Finvolves transmitting a customer identifier between login interface114and third-party identity provider144. In some applications it may be desired to avoid transmitting the customer identifier in any communications that involve workspace application110. This can be avoided through the use of a one-time-use ticket that is issued by configuration services150, and in particular, workspace ticketing module154. The one-time-use ticket can serve as a temporary proxy for the customer identifier, thus enhancing security.FIGS.4A through4Ccomprise a sequence diagram schematically illustrating selected communication sequences that occur in an example technique for acquiring multiple user identities to integrate functionality provided by multiple digital services, wherein a one-time-use ticket serves as a proxy for the customer identifier. In particular, certain portions of the communication sequence illustrated inFIGS.3A through3Fcan be replaced with the communication sequence illustrated inFIGS.4A through4C, as will be described in turn.

As described above with respect toFIG.3A, when a user invokes a trigger command workspace application110attempts to acquire valid third-party authentication tokens144afrom session storage112. When such an attempt fails, workspace application110is configured to open a login interface114which is, in turn, used to authenticate the user via third-party identity provider144. This authentication procedure involves transmitting communications that include, embedded in a URI, a customer identifier associated with the user. As noted above, in some applications this may be undesirable from a security standpoint. Thus, in an alternative implementation, once workspace application110fails to acquire valid third-party authentication tokens144afrom session storage122, the alternative sequence of communications illustrated inFIGS.4A through4Cis initiated. This initial branching to an alternative procedure occurs after reference numeral304inFIG.3A.

Turning nowFIG.4A, once workspace application110fails to acquire valid third-party authentication tokens144afrom session storage122, workspace application110requests an authentication context from application connector160. See reference numeral401inFIG.4A. Application connector160forwards this request to workspace cloud configuration152. See reference numeral402inFIG.4A. In this context, the requested “authentication context” defines the user's identity based on the user's prior authentication by workspace identity provider142. Given the workspace organization identifier associated with the requesting user, workspace cloud configuration152is able to determine the associated tenant identifier. More specifically, this tenant identifier is determined based on the whitelisted “workspace organization↔tenant” mapping, as discussed above. Workspace cloud configuration then returns the tenant identifier to application connector160. See reference numeral403inFIG.4A.

Application connector160can then use workspace organization identifier and tenant identifier to request a one-time-use ticket from workspace ticketing module154. See reference number404inFIG.4A. Workspace ticketing module154generates the one-time-use ticket. See reference numeral405inFIG.4A. This one-time-use ticket can be associated with the whitelisted “workspace organization↔tenant” mapping that forms the basis for the request received from application connector160. Workspace ticketing module154then returns the one-time-use ticket to application connector160. See reference numeral406inFIG.4A. Application connector160can then return the one-time-use ticket, the workspace organization identifier, and the tenant identifier to workspace application110. See reference numeral407inFIG.4A. Collectively, this communication can be understood as comprising the aforementioned authentication context since it provides the context within which the user will be authenticated, wherein the context is defined by the different organizations (workspace120, connected application170) within which the user is authorized to access resources.

Upon receiving the authentication context, workspace application110can set a “domain hint” using the tenant identifier. See reference numeral408inFIG.4A. For example, a variable domain hint can be used to set a ticket identifier value. Workspace application110then opens login interface114. See reference numeral409inFIG.4B. This can be accomplished by, for example, opening a new browser tab. Once opened, login interface114initiates authentication of the user via third-party identity provider144. To support such authentication, login interface114sends data to support authentication with third-party identity provider144, thus streamlining the authentication process from the user's perspective. Where third-party identity provider144uses OAuth 2.0, this supporting information can include an identifier of the workspace organization, a redirect URI, and/or a copy of the one-time-use ticket acquired from workspace ticketing module154. See reference numeral410inFIG.3B. An example of a request sent from login interface114to third-party identity provider144is as follows:

Third-party identity provider144can use this information to authorize the user via, for example, OAuth 2.0. See reference numeral411inFIG.4B. Regardless of the particular protocol used, authentication of the user may require multiple back-and-forth communications between login interface114and third-party identity provider144. These individual communications are not separately illustrated inFIG.4Afor clarity. Similarly, depending on the particular authentication protocol used and the configuration of third-party identity provider144, multifactor authentication may be required, for example using an additional token sent to the user via a different communication channel, such as by text message, email, telephone call, or mobile application. If the user fails to complete all authentication requirements imposed by the applicable authentication protocol, third-party identity provider144may return an authentication failure message to login interface114. On the other hand, if the user is able to successfully complete all authentication requirements, third-party identity provider144establishes that the user is successfully authenticated. See reference numeral412inFIG.4B.

In response to successfully authenticating the user, third-party identity provider144returns a redirect to login interface114. See reference numeral414inFIG.4B. A redirect is returned because third-party identity provider144expects to be communicating with a browser. An example of such a redirect is as follows:

https://connector.example.com/handle3PYRedirect/#access_token=EFGH&client_info=XYZ&state=ticket
This example redirect includes a common “base URI” (“http://connector.example.com/handle3PYRedirect/”) and a “hash fragment” (the portion of the redirect following the base URI and beginning with the # symbol). The hash fragment comprises a plurality of name-value pairs. Specifically, the “access token=EFGH” name-value pair form the third-party authentication tokens144aestablishes that the user has been authenticated by third-party identity provider144. The “client_info=XYZ” name-value pair identifies the requesting browser that is authorized to access resources of connected application170, that is, workspace application110. The “state=ticket” name-value pair represents the one-time-use ticket acquired from workspace ticketing module154. The hash fragment may additionally or alternatively contain other name-value pairs such as an expiration timestamp or a token scope value.

Applications that use OAuth 2.0 expect to receive redirect calls. However, to enhance security and limit scope, such applications typically only allow redirects from a relatively small preconfigured set of whitelisted URIs. For instance, the example redirect provided above includes the whitelisted base URI “connector.example.com/handle3PYRedirect”. In general, it may be desired to use a different base URI in subsequent communications. Thus, upon receiving the redirect, login interface114responds by sending a first GET request to application connector160. See reference numeral415inFIG.4B. An example of such a first GET request is as follows:GET https://connector.example.com/handle3PYRedirect
Thus, in certain embodiments the first GET request includes the base URI included in the redirect that was received from the third-party identity provider144. This notifies application connector160that workspace application110has acquired authentication tokens from third-party identity provider144, but that further processing is requested, as will be explained in turn. This first GET request, when processed by application connector160, causes application connector160to return executable code to login interface114. See reference numeral416inFIG.4B. This executable code, which in certain implementations may comprise a JavaScript® element, is injected into login interface114. When executed, it causes the one-time-use ticket to be extracted from the hash fragment included in the redirect that was received from third-party identity provider144.

Login interface114executes the received code and extracts the one-time-use ticket from the hash fragment. See reference numeral417inFIG.4C. Login interface114then sends a second GET request to application connector160. See reference numeral418inFIG.4C. An example of such a second GET request is as follows:

https://connector.example.com/handle3PYRedirect/?ticket#access_token=EFGH&client_info=XYZ
As can be seen, this second GET request is similar to the redirect received from third-party identity provider144, except that the one-time-use ticket has been appended to the base URI.

Upon receiving this second GET request, application connector160sends a request to workspace ticketing module154to redeem the one-time-use ticket included in the second GET request. See reference numeral419inFIG.4C. As noted above, workspace ticketing module154associates the one-time-use ticket with the whitelisted “workspace organization4→tenant” mapping. Workspace ticketing module154uses the one-time-use ticket to look up the workspace organization identifier and tenant identifier, which are then returned to application connector160. See reference numeral420inFIG.4C.

Application connector160requests the organization domain name (for example, “CustomerName.example.com”) from workspace cloud configuration152. See reference numeral421inFIG.4C. Workspace cloud configuration152returns the requested domain name to application connector160. See reference numeral422inFIG.4C. Upon receiving the domain name, application connector160uses the domain name to generate and send a redirect to login interface114. See reference numeral423inFIG.4C. An example of such a redirect is as follows:

https://CustomerName.example.com/Store/Web/#access_token=EFGH&client_info=XYZ
This redirect includes a hash fragment that, in turn, includes the validated third-party authentication tokens144a(the “access token=EFGH” name-value pair). Login interface114recognizes this redirect by virtue of the matching hash fragment. In response to receiving the redirect, login interface114uses the redirect to generate and send a third GET request to workspace120. See reference numeral424inFIG.4C. An example of such a third GET request is as follows:

https://CustomerName.example.com/Store/Web/#access_token=EFGH&client_info=XYZ
This third GET request, when processed by workspace120, causes workspace120to return executable code to login interface114. See reference numeral322inFIG.3D. At this point the sequence of communications illustrated inFIGS.3D through3Fcan be followed since such communications do not require the customer identifier to be transmitted in communications involving workspace application110. In particular, because the one-time-use ticket serves as a temporary proxy for the customer identifier, security is enhanced because the customer identifier is not transmitted in communications that involve workspace application110.

Computing Devices for Application Connector

FIG.6is a block diagram schematically illustrating an example computing device600configured to implement various components of the systems disclosed herein. Computing device600includes a processor603, volatile memory622(for example, random access memory (RAM)), nonvolatile memory628(also referred to as non-transitory memory), a user interface670, a network or communication interface618, and a communication bus650. Computing device600may also be referred to as a client device, endpoint device, computer, or computer system. Computing device600may be used to implement, for example, workspace application110, workspace120, application connector160, and/or connected application170. In particular, computing device600is shown merely as an example client device or server and can be implemented within any suitable computing or processing environment with any suitable type of physical or virtual machine or set of physical and virtual machines that can have suitable hardware and/or software capable of operating as described herein.

Nonvolatile memory628can include one or more hard disk drives or other magnetic or optical storage media. Nonvolatile memory628can additionally or alternatively include one or more solid state drives, such as a flash drive or other solid-state storage media. Nonvolatile memory628can additionally or alternatively include one or more hybrid magnetic and solid-state drives. Nonvolatile memory628can additionally or alternatively include one or more virtual storage volumes, such as a cloud storage, or a combination of such physical storage volumes and virtual storage volumes or arrays thereof.

User interface670can include a graphical user interface, examples of which include controls presented on a touchscreen, a display, or the like. User interface670can additionally or alternatively include one or more input/output devices, examples of which include a mouse, a keyboard, a microphone, one or more speakers, one or more cameras, one or more biometric scanners, one or more environmental sensors, one or more accelerometers, one or more visors, and the like.

Nonvolatile memory628stores an operating system615, one or more applications or programs616, and data617. Operating system615and programs616include sequences of instructions that are encoded for execution by processor603. Execution of these instructions results in manipulated data. Prior to their execution, the instructions can be copied to volatile memory622. In some examples, volatile memory622can include one or more types of RAM and/or a cache memory that can offer a faster response time than a main memory. Data617can be entered through user interface670or received from the input/output devices such as communication interface618. The various elements of computing device600described above can communicate with one another via communication bus650.

Processor603can be implemented by one or more programmable processors to execute one or more executable instructions, such as a computer program, to perform the functions of the system. As used herein, the term “processor” describes circuitry that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations can be hard coded into the circuitry or soft coded by way of instructions held in a memory device and executed by the circuitry. Processor603can perform the function, operation, or sequence of operations using digital values and/or using analog signals. In some examples, processor603can be embodied in one or more application specific integrated circuits, microprocessors, digital signal processors, graphics processing units, microcontrollers, field programmable gate arrays, programmable logic arrays, multicore processors, or general-purpose computers with associated memory. Processor603can be analog, digital, or mixed. In some examples, processor603can be one or more local physical processors or one or more remotely-located physical processors. A processor including multiple processor cores and/or multiple processors can provide functionality for parallel, simultaneous execution of instructions or for parallel, simultaneous execution of one instruction on more than one piece of data.

Communication interface618can include one or more interfaces to enable computing device600to access a computer network680such as a local area network, a wide area network, a personal area network, or the Internet through a variety of wired and/or wireless connections, including cellular connections and Bluetooth connections. In some examples, network680may allow for communication with other computing devices690to enable distributed computing. Examples of other computing devices690include workspace application110, workspace120, application connector160, and connected application170. Network680can include, for example, one or more private and/or public networks over which computing devices can exchange data.

In described examples, computing device600can execute an application on behalf of a user of a client device. For example, computing device600can execute one or more virtual machines managed by a hypervisor. Each virtual machine can provide an execution session within which applications execute on behalf of a user or a client device, such as a hosted desktop session. Computing device600can also execute a terminal services session to provide a hosted desktop environment. Computing device600can provide access to a remote computing environment including one or more applications, one or more desktop applications, and one or more desktop sessions in which one or more applications can execute.

Conclusion

The foregoing description and drawings of various embodiments are presented by way of example only. These examples are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Alterations, modifications, and variations will be apparent in light of this disclosure and are intended to be within the scope of the invention as set forth in the claims. In addition, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. Any references to examples, components, elements, or acts of the systems and methods herein referred to in the singular can also embrace examples including a plurality. Likewise, any references in plural to any example, component, element, or act herein can also embrace examples including only a singularity. References in the singular or plural form are not intended to limit the presently disclosed systems or methods, their components, acts, or elements. The use herein of “including”, “comprising”, “having”, “containing”, “involving”, and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. References to “or” can be construed as inclusive so that any terms described using “or” can indicate any of a single, more than one, and all of the described terms.