Component Integration

This chapter is one of a series that make up the Omnissa Workspace ONE and Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Omnissa Workspace ONE and Omnissa Horizon solutions. This chapter provides information about integrating the separate products and components together.

Introduction

After the various Workspace ONE and Horizon products and components have been designed and deployed, some one-time integration tasks must be completed.

• Integrate Workspace ONE UEM with Workspace ONE Access, Workspace ONE Intelligence, and Workspace ONE Assist.
• Also integrate Workspace ONE Intelligence with Workspace ONE Access and Workspace ONE Trust Network.
• Integrate Horizon 8 with Workspace ONE Access.
• Integrate Horizon Cloud on Microsoft Azure – first-gen with Workspace ONE Access.

Workspace ONE UEM and Workspace ONE Access Integration

Workspace ONE Access and Workspace ONE UEM (powered by AirWatch) are built to provide tight integration between identity and device management. This integration has been simplified in recent versions to ensure that configuration is relatively straightforward. For information about the latest release, see Workspace ONE UEM Integration with Workspace ONE Access.

Although Workspace ONE Access and Workspace ONE UEM are the core components in a Workspace ONE deployment, you can also deploy a variety of other components, depending on your business use cases. As the following figure shows, you can use Unified Access Gateway for access to an on-premises Exchange server through Workspace ONE UEM Secure Email Gateway (SEG) or Per-App Tunnel through Workspace ONE Tunnel edge service to access internal resources. Refer to the various sections in the Workspace ONE UEM Documentation for descriptions of the full range of components that apply to a deployment.

Figure 1: Sample Workspace ONE Architecture

Many other enterprise components can be integrated into a Workspace ONE deployment. These components include technologies such as a Certificate Authority, Active Directory, file services, email systems, SharePoint servers, external access servers, and reverse proxies. We assume that these enterprise systems are in place and are functional if necessary.

To successfully integrate Workspace ONE UEM with Workspace ONE Access, you can use the Workspace ONE Getting Started wizards. The Identity and Access Management wizard walks you through setting up the AirWatch Cloud Connector to allow the components of Workspace ONE, Workspace ONE UEM, and Workspace ONE Access to communicate with your Active Directory. Documentation for this process is available in the Workspace ONE UEM Integration with Workspace ONE Access.

AirWatch Cloud Connector and Directory Integration Configuration Wizard

You can use the Workspace ONE wizards to set up the AirWatch Cloud Connector, Active Directory integration, and Workspace ONE Access integration.

Figure 2: Identity and Access Management Wizard

The first step in the wizard is to connect the Workspace ONE UEM instance to the Workspace ONE Access tenant.

Figure 3: Connect to Workspace ONE Access

After you enter the fully qualified domain name (FQDN) and supply authentication credentials for the Workspace ONE Access tenant, the connection can be made.

• The Workspace ONE UEM console servers must be able to reach the Workspace ONE Access tenant through port 443.
• The Workspace ONE Access tenant must be able reach the Workspace ONE UEM API service through port 443.

After the connection is made, the first step in the Identity and Access Management wizard is marked as complete.

Figure 4: Identity and Access Management Wizard – Connection to Workspace ONE Access Completed

The next step in the Identity and Access Management wizard is to install the AirWatch Cloud Connector and connect Workspace ONE UEM to Active Directory.

Figure 5: AirWatch Cloud Connector and Workspace ONE Access Connector

The AirWatch Cloud Connector provides the ability to integrate Workspace ONE UEM with an organization’s backend enterprise systems. It is enabled in the Workspace ONE UEM Console and is downloaded to a Windows Server in the enterprise to enable communication between Active Directory and the Workspace ONE service.

Figure 6: Download the AirWatch Cloud Connector

The wizard prompts you to set up a password before downloading the AirWatch Cloud Connector installer. Use this password while running the installer.

Previous versions of Workspace ONE UEM provided access to the AirWatch Cloud Connector by using the Enterprise Systems Connector installer, a bundled installer of the AirWatch Cloud Connector and Workspace ONE Access. With current versions of Workspace ONE UEM, the Workspace ONE Access connector is downloaded as a separate installer.

Active Directory Integration

The next step, after setting up the AirWatch Cloud Connector, is to enter your Active Directory and bind authentication information to integrate AD with Workspace ONE UEM. Because you are making connections from the AirWatch Cloud Connector, ensure that networking and server IPs and host names can be resolved.

Note: Ensure that the Active Directory domain name you enter in the wizard matches the name used in Workspace ONE Access. Otherwise, administrators will not be able to access some features and configurations of Workspace ONE Access from the Workspace ONE UEM Console.

Figure 7: Connect to Active Directory

The Workspace ONE Access Connector provides connectivity to synchronize Workspace ONE Access with your user directory, such as Active Directory. The Workspace ONE Access Connector also provides user authentication and integration with Horizon, along with following capabilities:

• Many authentication methods for external users, including password, RSA Adaptive Authentication, RSA SecurID, and RADIUS
• Kerberos authentication for internal users
• Access to Horizon 8 resources
• Access to Horizon Cloud Service resources
• Access to Citrix-published resources

To set up the Workspace ONE Access Connector along with directory integration, see Installing Workspace ONE Access Connector 23.09 and Directory Integration with Workspace ONE Access.

Catalog Population

The unified Workspace ONE app catalog contains many types of applications. SaaS-based SAML apps and Horizon apps and desktops are delivered through the Workspace ONE Access catalog, and native mobile apps are delivered through the Workspace ONE UEM catalog.

Table 1: Configuration Considerations for Populating the Workspace ONE Access Catalog

Device Profile Configuration and Single Sign-On

Device profiles provide key settings that are applied to devices as part of enrollment in Workspace ONE UEM. The settings include payloads, such as credentials, passcode requirements, and other parameters used to configure and secure devices. Different payloads are configured in different services, as described in this document, but SSO is a common requirement across all devices and use cases.

Table 2: Configuration Considerations for Device Profiles in Workspace ONE UEM

The Workspace ONE Access directory synchronizes user account information from Active Directory and uses it for entitling applications to users through the Workspace ONE app or browser page. For SSO and True SSO to work when integrating with Workspace ONE Access and Horizon, a number of configuration considerations must be considered.

Table 3: Configuration Considerations for Features in Workspace ONE Access

Workspace ONE UEM and Workspace ONE Intelligence Integration

Workspace ONE Intelligence offers insights into your digital workspace. It offers enterprise mobility management (EMM) planning and automation. All these components help to optimize resources, strengthen security and compliance, and enrich user experience across your environment.

Workspace ONE UEM is the minimum and main required integration point for Workspace ONE Intelligence. When Workspace ONE UEM is hosted on-premises, it requires the installation of the Workspace ONE Intelligence Connector service on the internal network.

Note: For those using cloud-based Workspace ONE UEM, there is no need to install the Workspace ONE Intelligence Connector service because it is already enabled by default.

The Workspace ONE Intelligence Connector service collects data related to devices, apps, and OS updates from your Workspace ONE UEM database and pushes this data to the cloud-based report service.

Figure 8: Integration of Workspace ONE UEM with Workspace ONE Intelligence Cloud Service

The integration consists of high-level steps:

1. Define the region where the Intelligence Connector service will sync the data. This information will be required during the installation process.
2. Ensure you have allowlisted the applicable URLs so that the connector installation process can communicate with the correct cloud-based reports service.
   For the list of URLs, see Requirements in Workspace ONE Intelligence Dashboards, Workflows, and Reports.

If you use a proxy server and want to use it with the Workspace ONE Intelligence Connector, make sure you have allowlisted specific destinations. If you do not allowlist these destinations, the installation can fail.

3. Ensure you have met the hardware, software, and network requirements outlined in see Requirements in Workspace ONE Intelligence Dashboards, Workflows, and Reports.
4. Run the Workspace ONE Intelligence Connector installer, which might ask for the Workspace ONE UEM Installation Token that can be generated through https://my.workspaceone.com.

For more information, see the Installing the Intelligence Connector Service.

After you successfully install the Intelligence Connector service and opt-in to Workspace ONE Intelligence through the Workspace ONE UEM Console, the Intelligence Connector service will perform the first import of all devices, apps, and OS update data. Subsequent synchronizations will be based on samples taken from the devices, sensors, apps, and OS updates.

For more information regarding Intelligence Connector support for high availability and disaster recovery, see High Availability and Disaster Recovery Support with the Workspace ONE Intelligence Connector.

Workspace ONE Mobile Threat Defense and Workspace ONE UEM Integration

Workspace ONE Mobile Threat Defense offers advanced mobile protection for iOS, Android, and Chrome devices managed by Workspace ONE UEM, securing devices against app, device, OS, and network-based threats.

Workspace ONE Mobile Threat Defense is powered by Lookout and uniquely integrates with Workspace ONE UEM embedding the Lookout SDK within the Intelligence Hub app to form a robust endpoint protection suite on these managed devices. This lightweight mobile app activates security via the Intelligent Hub and provides mobile security in an easy to deploy and manage way while offering integrated management of the device and the ability to provide actions on alerts and threats on the device without user interaction.

Workspace ONE UEM is the minimum and main required integration point for Workspace ONE Mobile Threat Defense (SaaS only). For more information on the requirements, see the Workspace ONE Mobile Threat Defense documentation.

The integration of Workspace ONE Mobile Threat Defense and Workspace ONE Intelligence is optional and performed through the Trust Network integration to enable advanced incident response.

The following diagram shows the main points of integration to enable Workspace ONE Mobile Threat Defense.

Figure 9: Workspace ONE Mobile Threat Defense Logical Architecture

Device Inventory and Tag Synchronization

Workspace ONE Mobile Threat Defense (MTD) and Workspace ONE UEM integrates via REST API to enable device inventory synchronization from UEM into MTD, allowing the Security Team to see the required device information when threats are displayed in the MTD Console and associate security policies to a group of devices.

Figure 10: List of Devices and respective Risk Status into Workspace ONE Mobile Threat Defense Console

This integration also enables MTD to update the device status in UEM when threats are identified. The devices in UEM will receive Tags that represent their current risk status. The tags are created in the UEM Console and associated to the respective risk status in the MTD Console.

Figure 11: List of Devices and respective Risk Status into Workspace ONE UEM Console

To learn how to perform this integration step by step, see Integrate Workspace ONE Mobile Threat Defense With Workspace ONE UEM.

Mobile Threat Defense Device activation

Workspace ONE Mobile Threat Defense must be activated on the devices. The activation process on Intelligence Hub is configured through custom SDK configuration and does not require the end-user to launch a separate app to activate MTD. This is possible because of our unique integration that brings Lookout SDK into Intelligent Hub; all the MTD protection happens in the Intelligent Hub.

Figure 12: SDK Custom Configuration required to enable MTD on Intelligent Hub

When MTD is activated, it analyzes the device information, initiates a scan process looking for threats on the device, including the operation system, network communication, and apps. MTD can identify local threats and configuration issues; it leverages the Lookout Security Graph that contains information from millions of other mobile users protected by MTD to identify additional threats.

The MTD protection capabilities enabled on the device will depend on which app (Intelligent Hub or Lookout for Work App) you deploy. When using MTD with Intelligent Hub for iOS and Android, devices are protected against device, apps, and network threats. For the following uses cases, Lookout for Work App will be required as MTD protection:

• Support to phishing and content protection
• Support for Chrome OS
• Support for Android Dual Enrollment

Note: Intelligent Hub and Lookout for Work app cannot be activated on the same device, because MTD on Hub is activated at the Organization Group (OG) level. When the Lookout for Work App is required, devices with the Lookout for Work app must be enrolled in a different OG.

Automated Remediation

An important step in the integration is the setup of automated remediation to protect access to corporate resources only from safe devices. This step ensures that devices at risk do not get access to managed corporate resources. It also requires the UEM administrator to create a smart group that contains devices tagged at risk by MTD. This smart group is then added as an exclusion to the assignment of managed resources, such profiles, and apps.

Figure 13: Workspace ONE UEM configuration to remove VPN Profile of devices tagged at Risk by MTD

In a real use case scenario, devices can have managed applications (for example, Workspace ONE Boxer, Tunnel, Content, Office 365) removed when the device is at risk (low, medium, high-risk tags), and when the device returns to a safe state, those apps are automatically reprovisioned. For more information, see Configure and Enforce Compliance.

Automated Incident Response

Workspace ONE Intelligence can be integrated with MTD via Workspace ONE Intelligence Automation to automate incident responses, such as notify IT and InfoSec about unresolved threats via the helpdesk system and other collaboration tools, such as ServiceNow, Microsoft Teams, Slack, JIRA, and so on. For more information, see Integrate with Workspace ONE Trust Network.

Figure 14: Workspace ONE Intelligence Automation example that creates a Service Now ticket for high-risk threats detected

For additional information on the Architecture and Integration of Workspace ONE Mobile Threat Defense, watch the Workspace ONE Mobile Threat Defense Architecture and Integrations video on Tech Zone.

You can also learn more with the following additional resources:

• Guide: Secure Mobile Endpoints with Threat Defense (MTD)
• Video: Workspace ONE Mobile Threat Defense Technical Overview
• Video: Workspace ONE Mobile Threat Defense in Action (Demo)

Workspace ONE Access and Workspace ONE Intelligence Integration

Workspace ONE Access can be integrated with Workspace ONE Intelligence to provide insights on user logins and application launches. The integration requires a cloud-based Workspace ONE Access tenant and a licensed tenant of Workspace ONE Intelligence.

Figure 15: Integration of Workspace ONE Intelligence Cloud Service with Workspace ONE Access

Because the integration is performed between two cloud services, there is no need to perform any on-premises configuration.

The integration consists of two high-level steps:

1. Log in to Workspace ONE Access as an administrator.
2. Register the Workspace ONE Access tenant in the Workspace ONE Intelligence Console, as outlined in Register Workspace ONE Access.

Important: Ensure your Workspace ONE Access and Workspace ONE Intelligence tenants are in the same region. A Workspace ONE Access tenant can be registered with Workspace ONE Intelligence only if both are in the same region. See the Workspace ONE SaaS Environments Mapped to Workspace ONE Intelligence Regions for mapping information.

Figure 16: Workspace ONE Intelligence Successfully Integrated with Workspace ONE Access

After integration is complete, Workspace ONE Intelligence collects user and event data about Workspace ONE logins and app loads for all the apps contained in the Workspace ONE catalog. Events are synced every second or when 50,000 events have accumulated, whichever comes first.

The integration also enables the Risk Adapter in Workspace ONE Access for risk-based conditional access. For a complete list of data collected by the integration, see Workspace ONE UEM Data Definitions.

Workspace ONE Intelligence and Trust Network Integration

Workspace ONE Trust Network includes several security solutions that can be integrated with Workspace ONE Intelligence. This integration can provide a consolidated view of all threats reported by the various security solutions, and the intelligence component helps automate remediation actions. The integration requires a licensed cloud-based Workspace ONE Trust Network partner solution tenant and a Workspace ONE Intelligence tenant.

Figure 17: Integration flow of Workspace ONE Intelligence Cloud Service with Workspace ONE Trust Network

Because the integration is performed between two cloud services, there is no need to perform any on-premises configuration. You must, however, deploy and configure an agent provided by the security solution. Otherwise, threats could not be reported to the Workspace ONE Trust Network, and Workspace ONE Intelligence would not obtain any data.

The integration consists of the following high-level steps:

1. Obtain the URL and API keys required by the Workspace ONE Trust Network partner solution.
2. Register the respective Workspace ONE Trust Network solution in the Workspace ONE Intelligence Console, under Settings > Integration.
3. Deploy the Trust Network agent on all managed devices.

Note: You can leverage Workspace ONE UEM to deploy and configure the Workspace ONE Trust Network solution agent across all of your managed devices.

To learn how to set up each of the current partner solutions that can be part of Workspace ONE Trust Network integration with Workspace ONE Intelligence, see the following topics in the Workspace ONE Trust Network section of the Workspace ONE Intelligence documentation:

• Register Carbon Black
• Register Workspace ONE Mobile Threat Defense
• Register Check Point
• Register Lookout for Work
• Register Netskope
• Register Pradeo
• Register Wandera
• Register Zimperium

Figure 18: Workspace ONE Intelligence integration setup for multiples security solutions.

After integration is complete, Workspace ONE Intelligence checks every 30 seconds for new threats reported by the Workspace ONE Trust Network solutions configured in your environment. Any new events that are identified are stored in a Workspace ONE Intelligence database. That way, any automations based on threat data that matches criteria for incoming events is immediately executed.

Workspace ONE UEM and Workspace ONE Assist Integration

Workspace ONE Assist can be integrated with Workspace ONE UEM to provide your administrators with single-sign-on capabilities into the Workspace ONE Assist Portal server. With this integration, administrators can seamlessly launch remote management sessions for your eligible devices from the Workspace ONE UEM console.

The integration with Workspace ONE UEM consists of a simple site URL configuration in the Workspace ONE UEM console, as detailed in the section that follows. Your devices will also require the Workspace ONE Assist application to be installed, which can be distributed to your managed devices using Workspace ONE UEM.

Workspace ONE UEM Configuration

The integration with Workspace ONE Assist consists of two high-level steps:

1. Log in to the Workspace ONE UEM console with an admin account that has global organization group access.
2. Navigate to the Site URLs settings under System > Advanced and configure the Workspace ONE Assist fields.

Figure 19: Workspace ONE Assist Configuration in the Workspace ONE UEM Console

See Install Workspace ONE Assist to an On-Premises Environment for detailed steps.

Configure End-User Devices

Once Workspace ONE UEM has been configured, you must install the platform-specific Workspace ONE Assist agents on your devices before they can be remotely managed. 

This process consists of the following high-level steps:

1. Locate the Workspace ONE Assist app for your desired supported platform or platforms.
2. Publish the Workspace ONE Assist app to your managed devices. For an example, see How Do You Enable Remote Control with Samsung Knox Service Plugin.
3. Determine if your platform or device requires additional supporting apps or configurations for remote management sessions. For an example, see How Do You Enable Remote View For iOS Devices

For full details, see Configure End-User Devices.

Start a Remote Management Session

Once the necessary Workspace ONE UEM and end-user device configurations have been made, your administrators can begin a remote management session by connecting to your managed devices through the Workspace ONE UEM console.

The process of starting this remote management session consists of the following high-level steps:

1. Log in to the Workspace ONE UEM console.
2. Navigate to the managed device you intend to start a remote management session with, and click Remote Management under MORE ACTIONS.

Figure 20: Start a Workspace ONE Assist Remote Management Session

See Start an Assist Session for more details.

Workspace ONE UEM Screen Capture Restriction Profiles

Workspace ONE UEM Restriction Profiles have a setting named Allow Screen Capture, which, if disabled, prevents devices from taking screen captures. Be aware that if you create a Restriction Profile that disallows screen capture, and you push that profile to a device, the profile will prevent Workspace ONE Assist from remotely viewing or controlling the device.

If you use a Restriction Profile that disables screen capturing, it is recommended to unassign this profile from any device that would utilize Workspace ONE Assist for remote screen-sharing sessions.

Workspace ONE Access and Horizon Integration

Horizon can be integrated into Workspace ONE through Workspace ONE Access to present the entitled Horizon published apps and desktops to end users in Workspace ONE Intelligent Hub. You can set up SSO for Horizon apps and desktops, ensure security with multi-factor authentication, and control conditional access.

The type of integration used depends on whether or not Horizon Universal Broker is in use.

• Horizon Universal Broker -first-gen Integration – When using Universal Broker – first-gen, direct integration can be done which allows the entitlements of all participating pods to be queried and presented to the user in Workspace ONE Access and Intelligent Hub services.
• Virtual App Collections Integration – When Universal Broker is not in use, each Horizon 8 pod or cloud pod federation can be registered as a virtual apps collection with Workspace ONE Access.

Horizon 8 Virtual Apps Collections Integration

Horizon 8 can be integrated into Workspace ONE through Workspace ONE Access using virtual apps collections.

The Horizon 8 license includes Workspace ONE Access, which supports access to Horizon apps and desktops only. Horizon can be used with other license types if access to other apps such as Horizon apps and desktops, SaaS apps, or mobile apps, is also required.

Figure 21: Integration of Horizon with Cloud-Based Workspace ONE Access

Integrating Horizon 8 with an instance of Workspace ONE Access consists of three high-level steps:

1. Complete the prerequisite steps outlined in the next section. These steps include deploying Workspace ONE Access Connectors and configuring Active Directory synchronization.
2. Configure SAML authentication in your Horizon environment, as described in Configure SAML Authentication in Horizon for Workspace ONE Access Integration.
3. Create one or more virtual apps collections, as described in Virtual Apps Collection Creation for Horizon 8 Integration.

  Prerequisites for Horizon 8 Integration

Perform the following prerequisite tasks:

• Prepare the Workspace ONE Access environment by following the instructions in Using Virtual Apps Collections in Workspace ONE Access and Providing Access to Horizon Desktops and Applications in Workspace ONE Access.
• Ensure time synchronization is set so that Workspace ONE Access, Workspace ONE Access Connectors, and Horizon Connection Servers have the same time.

  SAML Authentication Configuration for Horizon 8 Integration

Before you create a virtual apps collection for Horizon 8 in the Workspace ONE Access console, first add Workspace ONE Access as a SAML 2.0 authenticator to the Horizon Connection Servers. Repeat this process for each additional pod.

1. Open the Horizon console and navigate to Settings > Servers > Connection Servers.
2. Select one of the Connection Servers and click Edit.
3. On the Authentication tab, change Delegation of authentication to VMware Horizon (SAML 2.0 Authenticator) to either Allowed or Required.

Figure 22: Manage SAML Authentication in Horizon 8 console

4. Select Manage SAML Authenticators to add a new SAML Authenticator, and click Add.
5. Enter a label to identify the authenticator.
   1. In the Metadata URL field, change <YOUR SAML AUTHENTICATOR NAME> to the FQDN of Workspace ONE Access. Leave the other text as it is.
   2. Leave Enabled for Connection Server selected and click OK.

Figure 23: Add SAML Authenticator in Horizon 8 console

6. Although the SAML 2.0 authenticator is defined once per pod, you must enable the authenticator individually on each Connection Server that is to use SAML authentication.
   1. Use the Horizon Console to edit the configuration of each Connection Server.
   2. Select the Authentication tab and change Delegation of authentication to VMware Horizon (SAML 2.0 Authenticator) to either Allowed or Required, matching what was selected on the first Connection Server.
   3. Select Manage SAML Authenticators, select the SAML authenticator just defined, and click Edit.
   4. Select Enabled for Connection Server and click OK.

For more information see, Configure SAML Authentication in Horizon for Workspace ONE Access Integration.

    Virtual Apps Collection Creation for Horizon 8 Integration

You integrate Horizon 8 desktops and applications into Workspace ONE Access by using virtual apps collections. See Providing Access to Horizon Desktops and Applications in Workspace ONE Access.

1. Log in to the Workspace ONE Access administrative console.
2. From the Catalog drop-down menu, select Virtual Apps Collection.
3. Click NEW to add a new virtual apps collection.

Figure 24: Add New Virtual Apps Collection

4. Select Horizon as the source type to create a Horizon virtual apps collection for your Horizon pods and Cloud Pod Architecture federation. This collection will host desktop or application capacity.

A virtual apps collection can contain one or more Horizon pods. The collection defines the configuration information about your Horizon environment, Workspace ONE Access Connectors, and settings to sync resources and entitlements to Workspace ONE Access.

Figure 25: Select Horizon Virtual Apps Collection Type

5. Name the new Horizon collection and select the connectors.
   1. Give the virtual apps collection a unique name.
   2. Select the Workspace ONE Access Connectors that will perform synchronization. Reorder the connectors if required and click NEXT.

Figure 26: Name the Virtual Apps Collection and Select the Connectors

6. To add the Horizon pods, click ADD A POD.

Figure 27: Add Horizon Pods to the Virtual Apps Collection

7. Enter details for the first Horizon pod, specifying one of the Horizon Connection Servers, credentials, and whether smart card authentication or True SSO is set up in the pod, and once complete, click ADD.

Figure 28: Define the Horizon Pod Details

8. For each additional Horizon pod in your environment, click ADD A POD and repeat the process.

Figure 29: Add additional Horizon Pods to the Virtual Apps Collection

9. Configure Horizon Cloud Pod Architecture.
   1. Select the check box to indicate if Cloud Pod Architecture is enabled and then click ADD A FEDERATION.

Figure 30: Configure Federation for the Horizon Pods in the Virtual Apps Collection

2. Specify a unique federation name.
3. Complete the Client Access FQDN field. This is usually the load balancer namespace for the Horizon environment.
4. Select and add the Horizon pods that are part of this federation.
5. Click ADD.

Figure 31: Configure Federation for the Horizon Pods in the Virtual Apps Collection

10. Complete the additional configuration for the new collection.
    1. Set up a sync frequency schedule.
    2. Set Sync Duplicate Apps to No.
    3. Choose an activation policy. In most cases, leave this as the default of User-Activated, which allows the user to self-serve any Horizon resources they are entitled to from the Workspace ONE Access catalog.
    4. Choose which default client should be used for a Horizon session by selecting an item from the Default Launch Client list.
    5. Click NEXT to review the Summary page.

Figure 32: Complete the Configuration for the Virtual Apps Collection

11. After you review the Summary page, click BACK if you need to make changes, or click SAVE & CONFIGURE NETWORK RANGE. The information you entered is validated and saved.

Figure 33: Add a New Horizon Virtual Apps Collection Summary

The collection is added, and the Network Ranges page appears.

Figure 34: Edit the Network Ranges to amend the Client Access FQDNs

Note: The default configuration for network settings in Workspace ONE Access specifies a single All Ranges scope. Also consider adding additional network ranges and tailoring the client access FQDN as necessary.

12. Change the client access FQDN for the All Ranges scope so that it points to the namespace for the load balancer.
    1. Click the ALL RANGES button on the Network Ranges page.
    2. Change the Client Access FQDN entries as needed. Any Horizon pods added will, by default, use the FQDN of the Horizon Connection Server used for adding the pod. Be sure to change the FQDN to the load balancer common namespace for the Connection Servers. Click SAVE.

Figure 35: Change Client Access FQDNs for All Ranges

13. If necessary, configure different client access FQDNs for specific network ranges. For example, perhaps different FQDNs should be used for internal and external connections.
    1. Click CREATE NETWORK RANGE.

Figure 36: Create New Network Range

2. Fill in the Name, IP Ranges, and change the Client Access FQDN entries. In the example below, a new range has been defined for internal IP ranges with the associated client access FQDNs. Click SAVE.

Figure 37: Sample new Network Range with internal Client Access FQDNs

14. After you add a virtual apps collection, you might want to force a synchronization of any entitlements, rather than waiting for the sync schedule to run. From the list of Virtual Apps Collections, select the collection and click the SYNC button.

Figure 38: Manual Sync of a Virtual Apps Collection

See Configuring Horizon Pods and Pod Federations in Workspace ONE Access for more information.

  Communication Flow When Launching a Horizon Resource from Workspace ONE Access

After Horizon 8 has been integrated with Workspace ONE Access, a user can select a Horizon resource, such as a desktop or a published application, from the Workspace ONE browser page or mobile app.

Internal Client

The following figure depicts the flow of communication that takes place when an internal user selects and launches an entitled Horizon desktop or application.

Figure 39: Internal Launch of a Horizon Resource from Workspace ONE

1. After the user is authenticated to Workspace ONE Access, either in a browser or using the Workspace ONE app, the user selects and launches a Horizon resource.
2. Workspace ONE Access generates a SAML assertion and an artifact that contains the vmware-view URL. It returns this SAML artifact to the browser on the client device (vmware-view://URL SAMLArt=<saml-artifact>).
3. The default URL handler for vmware-view types (normally the Horizon Client) is launched using the URL that was returned in the artifact (XML-API request do-submit-authentication <saml-artifact>).
4. The Horizon Connection Server performs a SAML Artifact Resolve operation against Workspace ONE Access (<saml-artifact>).
5. Workspace ONE Access validates the artifact and returns a SAML Assertion to the Horizon Connection Server (<saml-assertion>).
6. The Horizon Connection Server returns successful authentication (XML-API OK response submit-authentication).
7. The remote protocol client launches the session with the parameters returned.

External Client

The following figure depicts the flow of communication that takes place when an external user selects and launches an entitled Horizon desktop or application.

Figure 40: External Launch of a Horizon Resource from Workspace ONE

1. After the user is authenticated to Workspace ONE Access, either in a browser or using the Workspace ONE app, the user selects and launches a Horizon resource.
2. Workspace ONE Access generates a SAML assertion and a SAML artifact that contains the vmware-view URL. It returns this URL to the browser on the client device (vmware-view://URL SAMLArt=<saml-artifact>).
3. The default URL handler for vmware-view types (normally the Horizon Client) is launched using the URL that was returned in the artifact (XML-API request do-submit-authentication <saml-artifact>).
4. Unified Access Gateway proxies the authentication to the Horizon Connection Server
5. The Horizon Connection Server performs a SAML resolve against Workspace ONE Access (<saml-artifact>).
6. Workspace ONE Access validates the artifact and returns an assertion to the Horizon Connection Server (<saml-assertion>).
7. The Horizon Connection Server returns successful authentication (XML-API OK response submit-authentication).
8. Unified Access Gateway returns the successful authentication to the client.
9. The remote protocol client launches the session with the parameters returned.
10. Unified Access Gateway proxies the protocol session to the Horizon Agent.

Horizon Cloud on Microsoft Azure – first-gen Virtual Apps Collections Integration

Horizon Cloud on Microsoft Azure – first-gen can be integrated into Workspace ONE through Workspace ONE Access using virtual apps collections.

The Horizon Cloud license includes the cloud-hosted version of Workspace ONE Access, which supports access to Horizon Cloud apps and desktops only. Horizon Cloud can be used with other license types if access to other apps such as Horizon apps and desktops, SaaS apps, or mobile apps, is also required.

Figure 41: Integration of Horizon Cloud on Microsoft Azure – first-gen and Workspace ONE Access

With Horizon Cloud Service on Microsoft Azure – first-gen, you can specify creation of a cloud-based Workspace ONE Access tenant during the pod deployment process. The Workspace ONE Access tenant is associated with your Horizon Cloud customer record. Pods that already exist for the same Horizon Cloud customer record can then be integrated with that tenant.

Integrating Horizon Cloud on Microsoft Azure – first-gen, with a cloud-hosted Workspace ONE Access tenant consists of three high-level steps:

1. Complete the prerequisite steps outlined in the next section. These steps include deploying Workspace ONE Access Connectors and configuring Active Directory synchronization.
2. Create one or more virtual apps collections, as described in the Virtual Apps Collection Creation for Horizon Cloud on Microsoft Azure - first-gen Integration.
3. Configure SAML authentication in your Horizon Cloud tenant, as described in SAML Authentication Configuration for Horizon Cloud on Microsoft Azure - first-gen Integration.

  Prerequisites for Horizon Cloud on Microsoft Azure – first-gen Integration

Perform the following prerequisite tasks:

• Prepare the Workspace ONE Access environment by following the instructions in Providing Access to Horizon Cloud Service Desktops and Applications in Workspace ONE Access.
• Verify that Workspace ONE Access is joined to same Active Directory domain structure as the Horizon Cloud pod.
• Ensure that time synchronization is set so that Workspace ONE Access and Horizon Cloud pod have the same time.

    Virtual Apps Collection Creation for Horizon Cloud on Microsoft Azure – first-gen Integration

You integrate Horizon Cloud on Microsoft Azure – first-gen desktops and applications into Workspace ONE Access by using virtual apps collections. See Providing Access to Horizon Cloud Service Desktops and Applications in Workspace ONE Access and A Horizon Cloud Environment with Single-Pod Brokering — Integrating the Environment’s Horizon Cloud Pods in Microsoft Azure with Workspace ONE Access.

1. Log in to the Workspace ONE Access administrative console.
2. From the Catalog drop-down menu, select Virtual Apps Collection.
3. Click NEW.

Figure 42: Add New Virtual Apps Collection

4. Select Horizon Cloud as the source type to create a Horizon Cloud virtual apps collection for the Horizon Cloud on Microsoft Azure – first-gen environments that will host desktop or application capacity.

A virtual apps collection can contain one or more Horizon Cloud tenants. The collection defines configuration information about your Horizon Cloud tenants, Workspace ONE Access Connectors, and settings to sync resources and entitlements to Workspace ONE Access.

Figure 43: Select Horizon Cloud Virtual Apps Collection Type

5. Name the new Horizon Cloud collection and select the connectors.
   1. Give the virtual apps collection a unique name.
   2. Select the Workspace ONE Access Connectors that will perform synchronization. Reorder the connectors if required and click NEXT.

Figure 44: Name the Virtual Apps Collection and select the Connectors

6. Add the Horizon Cloud tenants.
   1. Click ADD A TENANT.

Figure 45: Add Horizon Cloud Tenant to the Virtual Apps Collection

2. Enter details for the Horizon Cloud tenant:

• Host – FQDN that corresponds to the Tenant Appliance IP Address
• Credentials – Horizon Cloud tenant administrator account
• Domains to Sync
• Assertion Consumer Service URL – URL that typically contains the Horizon Cloud tenant's floating IP address or hostname, or the Unified Access Gateway URL
• True SSO – Indicates whether True SSO is set up in the pod
  3. Once complete, click ADD.

Figure 46: Define the Horizon Cloud Tenant Details

7. For each additional Horizon Cloud tenant in your environment, click ADD A TENANT and repeat the process.

Figure 47: Add additional Horizon Pods to the Virtual Apps Collection

8. Complete the Configuration page for the new collection.
   1. Set up a sync frequency schedule.
   2. Set Sync Duplicate Apps to No.
   3. Choose an activation policy. In most cases, leave this as the default of User-Activated, which allows the user to self-serve any Horizon resources they are entitled to from the Workspace ONE Access catalog.
   4. Choose which default client should be used for a Horizon session by selecting an item from the Default Launch Client list.
   5. Click NEXT to review the Summary page.

Figure 48: Complete the Configuration for the Virtual Apps Collection

9. After you review the Summary page, click BACK if you need to make changes, or click SAVE. The information you entered is validated and saved.

Figure 49: Add a New Horizon Cloud Virtual Apps Collection Summary

10. After you add a virtual apps collection, you might want to force a synchronization of any entitlements, rather than waiting for the sync schedule to run. From the list of Virtual Apps Collections, select the collection and click the SYNC button.

Figure 50: Manual Sync of a Virtual Apps Collection

For more information on configuring virtual apps collections, see Setting up Virtual Apps Collections in Workspace ONE Access.

    SAML Authentication Configuration for Horizon Cloud on Microsoft Azure – first-gen Integration

After you create a virtual apps collection for the Horizon Cloud on Microsoft Azure – first-gen tenant in the Workspace ONE Access console, you configure SAML authentication in the Horizon Cloud tenant.

You can create a new Identity Management entry for each pod in your Horizon Cloud tenant.

1. Log in to the Horizon Cloud Administrative Console.
2. From Settings, select Identity Management and click New.

The New Identity Manager window appears.

Figure 51: Define Workspace ONE Access instance in Horizon Cloud console

The Workspace ONE Access Metadata URL that you specify must be in a format similar to the following:

https://<FQDN of Workspace ONE Access>/SAAS/API/1.0/GET/metadata/idp.xml

For more information see, Configure SAML Authentication in the Horizon Cloud Tenant for Workspace ONE Access Integration.

  Communication Flow When Launching a Horizon Cloud on Microsoft Azure – first-gen Resource from Workspace ONE Access

After Horizon Cloud on Microsoft Azure – first-gen has been integrated with Workspace ONE Access, a user can select a Horizon resource, such as a desktop or a published application, from the Workspace ONE browser page or mobile app.

The following figure depicts the flow of communication that takes place when a user selects and launches an entitled Horizon desktop or application.

Figure 52: Traffic Flow on Launch of a Horizon Cloud on Microsoft Azure – first-gen Resource from Workspace ONE

1. After the user is authenticated to Workspace ONE Access, either in a browser or using the Workspace ONE app, the user selects and launches a Horizon resource.
2. Workspace ONE Access generates a SAML assertion and an artifact that contains the vmware-view URL. It returns this URL to the browser on the client device (vmware-view://URL SAMLArt=<saml-artifact>).
3. The default URL handler for vmware-view types (normally the Horizon Client) is launched using the URL that was returned in the artifact (XML-API request do-submit-authentication <saml-artifact>).
4. If in-line, Unified Access Gateway (UAG) proxies the authentication to the Horizon Cloud pod.
5. The Horizon Cloud pod performs a SAML resolve against Workspace ONE Access (<saml-artifact>).
6. Workspace ONE Access validates the artifact and returns an assertion to the Horizon Cloud pod (<saml-assertion>).
7. The Horizon Cloud pod returns successful authentication (XML-API OK response submit-authentication).
8. If in-line, Unified Access Gateway returns the successful authentication to the Horizon Client.
9. The remote protocol client launches the session with the parameters returned.
10. If in-line, Unified Access Gateway proxies the protocol session to the Horizon Agent in the virtual desktop or RDSH server (if the resource is a published application or desktop).

Horizon Universal Broker -first-gen Integration

When using Horizon Cloud Service – first-gen and the Universal Broker service, that is part of the first-gen Horizon Control Plane, you can integrate Universal Broker with Workspace ONE Access and Intelligent Hub services. This replaces the need to integrate the Virtual Apps collections as described in the previous sections.

Figure 53: Horizon Universal Broker - first-gen Integration with Workspace ONE Access

  Prerequisites for Horizon Universal Broker - first-gen Integration

Before integrating a Horizon Universal Broker – first-gen environment with Workspace ONE Access, ensure that the following requirements are met:

• Enable and configure Universal Broker for the Horizon Cloud tenant. See Setting Up Universal Broker Service for Your Horizon Control Plane Tenant and its subtopics.
  • For Horizon Cloud pods in Microsoft Azure, select Universal Broker as the brokering method and then configure Universal Broker.
  • For Horizon 8 pods, install the Universal Broker plugin and configure the Unified Access Gateway on all participating pods. Then select Universal Broker as the brokering method and configure Universal Broker.
• Update all participating pods to the latest version.
  • For Horizon Cloud pods in Microsoft Azure, update to manifest 2474.0 or later.
  • For Horizon pods on a VMware SDDC platform, update to either Connection Server 7.13, 2012 (8.1.0), or later.

  Workspace ONE Access Configuration

To support the integration, ensure that the following configuration has been carried out in Workspace ONE Access.

• Install a supported version of the Workspace ONE Access Connector, as described in Horizon Cloud with Workspace ONE Access - Configure User Attributes for Integration with a Horizon Cloud Tenant with Universal Broker Enabled. As part of this installation, the connector is paired with your Workspace ONE Access tenant.
• Configure the required settings for Workspace ONE Intelligent Hub, as described in Horizon Cloud with Workspace ONE Access - Configure Intelligent Hub for Integration with Horizon Cloud.
• Configure the mandatory user attributes for your Workspace ONE Access tenant, as described in Horizon Cloud with Workspace ONE Access - Configure User Attributes for Integration with a Horizon Cloud Tenant with Universal Broker Enabled with Horizon Cloud. Workspace ONE Access requires the configuration of these attributes to maintain consistency with Horizon Cloud users and to sync assignment entitlements.

  Horizon Cloud Services - first-gen Configuration

To complete the configuration, you integrate the Workspace ONE tenant with the Horizon Cloud tenant. The Workspace ONE tenant can either be an existing tenant or a new one can be created as part of the integration process.

Follow the guidance in Horizon Cloud Environment with Universal Broker - Integrate the Tenant with Workspace ONE Access and Intelligent Hub Services.

  Communication Flow When Launching a Horizon Resource from Intelligent Hub

After Universal Broker has been integrated with Workspace ONE Access, a user can select a Horizon resource, such as a desktop or a published application, from Workspace ONE Access Intelligent Hub.

The following figure depicts the flow of communication that takes place when an external user selects and launches an entitled Horizon 8 desktop or application. The communication flow for an internal connection will be the same but without the need for Unified Access Gateway.

Figure 54: Launch of Horizon Universal Broker - first-gen Resource from Workspace ONE Access and Hub Services

1. After the user is authenticated to Workspace ONE Access, either in a browser or using the Workspace ONE Intelligent Hub app, the user selects and launches a Horizon resource.
2. Workspace ONE Access generates a SAML assertion and a SAML artifact that contains the vmware-view URL. It returns this URL to the browser on the client device (vmware-view://URL SAMLArt=<saml-artifact>).
3. The default URL handler for vmware-view types (normally the Horizon Client) is launched using the URL for the Universal Broker that was returned in the artifact (XML-API request do-submit-authentication <saml-artifact>).
4. The Universal Broker service (a service in the Horizon Control Plane) performs a SAML resolve against Workspace ONE Access (<saml-artifact>).
5. Workspace ONE Access validates the artifact and returns an assertion to the Universal Broker service (<saml-assertion>).
6. The Universal Broker service messages Universal Broker client (running on the Horizon Cloud Connector) in target pod.
7. The Universal Broker client forwards the message to the Universal Broker plugin running on the Connection Server.
8. The Universal Broker plugin identifies the best available resource to allocate to the end user.
9. Resource launch details are passed back to the Universal Broker client in the Horizon Cloud Control Plane.
10. The Universal Broker service returns a connection response to the Horizon Client which includes the unique FQDN of the pod and the JSON Web Tokens (JWT) to use when connecting via a Unified Access Gateway.
11. The remote protocol client launches the session with the parameters returned.
12. Unified Access Gateway proxies the protocol session to the Horizon Agent.

Summary and Additional Resources

Now that you have come to the end of this integration chapter, you can return to the reference architecture landing page and use the tabs, search, or scroll to select further chapter in one of the following sections:

• Overview chapters provide understanding of business drivers, use cases, and service definitions.
• Architecture chapters give design guidance on the Omnissa products you are interested in including in your deployment, including Workspace ONE UEM, Access, Intelligence, Workspace ONE Assist, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
• Integration chapters cover the integration of products, components, and services you need to create the environment capable of delivering the services that you want to deliver to your users.
• Configuration chapters provide reference for specific tasks as you deploy your environment, such as installation, deployment, and configuration processes for Omnissa Workspace ONE, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Management, and more.

Changelog

The following updates were made to this guide:

Author and Contributors

This chapter was written by:

• Graeme Gordon, Senior Staff Architect, Omnissa.

Feedback

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.