In addition to integrating independent Horizon pods with Workspace ONE Access, you can integrate Horizon Cloud Pod Architecture (CPA) deployments.

Figure 1. Integrating Horizon Pod Federations with Workspace ONE Access

The Horizon Cloud Pod Architecture feature links together multiple Horizon pods to form a single large desktop and application brokering and management environment called a pod federation. A pod federation can span multiple sites and data centers.

You can integrate one or more pod federations with the Workspace ONE Access service. Note that pod federations are created and managed in Horizon, and that user and group entitlements to the pod federation's desktops and application pools are set in Horizon. You sync the resources and entitlements to Workspace ONE Access.

Pod federations have global entitlements, which enable you to entitle users to desktops and applications which can be accessed from any pod in the pod federation. A global entitlement can consist of resources from multiple pods in the federation. For example, a global desktop entitlement might contain desktop pools from three different pods in three different data centers. Individual pods in the pod federation can also have local entitlements configured. You can sync both global and local entitlements to Workspace ONE Access.

Integrating a pod federation with the Workspace ONE Access service involves the following high-level tasks in the Workspace ONE Access console:

  • Add all the pods that form the pod federation, specifying Horizon Connection Server details for each.

    While Workspace ONE Access can sync global entitlements from any one of the pods in the pod federation, it needs to connect to each pod to sync metadata required for SAML authentication. It also needs to connect to the pods to sync local entitlements, if applicable.

  • Add the pod federation details and specify the global launch URL. The global launch URL, typically the global load balancer URL, is used to launch globally-entitled desktops and applications.

    You can customize the global launch URL for specific network ranges, for example for internal and external access.

  • Sync resources and entitlements from the pod federation to the Workspace ONE Access service.
    Note: Only global entitlements that have the All Sites scope policy in a pod federation are synced. The All Sites scope policy sets the scope of the search for an application or desktop to all the pods across the pod federation.
  • Customize the global launch URL by setting client access URLs for specific network ranges. These URLs are used to launch globally-entitled resources from the pod federation. By default, the global launch URL you specify while adding the federation is used as the global launch URL for all network ranges.
  • Specify client access URLs for each pod in the pod federation that has local entitlements configured. These URLs are used to launch locally-entitled desktops and applications from the pod. A client access URL can be a Horizon Connection Server URL, a Security Server URL, or a load balancer URL. Client access URLs are set for specific network ranges. By default, the Horizon Connection Server you specify while adding the pod is used as the client access URL for all network ranges.

When you integrate a pod federation with the Workspace ONE Access service, the service does the following:

  • Syncs all global entitlements that have the All Sites scope policy from the pod federation.
  • Syncs local entitlements, if selected, from the pods that are part of the pod federation.
  • Syncs metadata from all the Horizon Connection Servers in the pod federation.
  • Allows end users to access their Horizon applications and desktops from the Workspace ONE portal.

End users access their Horizon applications and desktops from the Workspace ONE portal. All the resources to which they are entitled, whether through global entitlements or local entitlements, are displayed. Applications and desktops are launched in the Horizon Client. When a user launches a locally-entitled application or desktop, it is launched from the Horizon Connection Server to which the user connects. Globally-entitled resources are launched from the Horizon Connection Server in which the resource is located.

Sample Cloud Pod Architecture Deployment

The following diagram shows a sample cloud pod architecture deployment and how it is integrated with the Workspace ONE Access service.

Figure 2. Cloud Pod Architecture Deployment Example

This diagram depicts a sample pod federation deployment. A pod federation, named Federation 1, is created in Horizon 6. It has three pods, Pod 1, Pod 2, and Pod 3. Pod 1 and Pod 2 are configured with Security Server instances for each Horizon Connection Server and an external load balancer for external access, and with an internal load balancer for internal access. Pod 3 is configured for only internal access with an internal load balancer. The pod federation as a whole has an external global load balancer and an internal global load balancer.

Desktop and application pools are deployed on the pods. Global entitlements are configured for Federation 1 and local entitlements are also configured for the individual pods.

Federation 1 is integrated with the Workspace ONE Access service. The Workspace ONE Access service syncs global entitlements as well as local entitlements from Federation 1. Because global entitlements are replicated in each pod, it syncs global entitlements from Pod 1. It also syncs local entitlements from Pod 1, Pod 2, and Pod 3.

End users can view all the desktops and applications to which they are entitled, whether through global entitlements or local entitlements, in the Workspace ONE Access Workspace ONE portal. When a user launches a desktop or application, if it is part of a global entitlement, the launch request goes to the external or internal global load balancer, URL EG or URL IG, based on the network range of the user. If the resource is from a local entitlement, the launch request goes to the internal or external load balancer of the pod on which the resource is deployed, based on the network range of the user. For example, for a resource on Pod 2, the request goes to URL I2 or URL E2.