Overview
VMware Workspace ONE Access (WS1 Access), formerly known as VMware Identity Manager (vIDM), enables the Single Sign-on (SSO) and 3rd party identity provider (iDP) integration capabilities for Horizon Cloud Service on Microsoft Azure (HCS on Azure).
The another reason to use the WS1 Access with HCS on Azure is to allow the users to access the desktops/Apps resources through a single FQDN even there are multiple PODs exist in the environment.
As of the date of writing this blog post, HCS on Azure does not have CPA (Cloud POD Architecture) feature like you have in Horizon7 Enterprise. A single HCS on Azure POD (Single Azure Subscription) has the limitation of 2000 VMs. For the big organizations who need more than 2000 desktops/sessions will have the option to deploy the multiple PODs for the scaling. Each HCS on Azure POD will have it’s own/unique FQDN to allow users to access the desktops/apps resources.
It is always a challenge to the administrator, who has multiple PODs, for allowing all the users within organization to access the HCS on Azure desktop/apps through a single FQDN. WS1 Access greatly helps here by providing the single FQDN capability to access multi PODs. By placing a WS1 Access infront of HCS on Azure PODs, user access can be summarised into a single FQDN. End users then will be able to access the HCS desktops/apps with WS1 Access FQDN, “https://corp.vmwareidenity.com” in below diagram. At first, the users will be authenticated from WS1 Access, then gets redirected to the respective POD (FQDN) which is associated with the desktop/apps that the user is accessing to.
[Note:Universal Brokering feature is available in HCS on Azure from 3.1 release].
Let us look, what kind of architecture can be achieved with HCS on Azure and WS1 Access. Depending on the use-cases and requirements, the architecture design may vary but basically we can think of below 3 architecture options.
Option#1, Standalone vIDM connector on each POD
In this option, each POD will have a single dedicated vIDM connector. Users will be authenticated with the dedicated connector. If the connector goes down, it brings a whole POD down. This option is good for proof of concept but not ideal for the production environment.
Option#2, Standalone vIDM connector on each POD + Azure vNET peering between the PODs
In this option, each POD will have a dedicated vIDM connector and each connector will have the line of site to the SmartNode in different POD via vNET peering. If the connector in POD#1 goes down for some reason users associated with POD#1 will still be authenticated through the connector in POD#2 and vice verca. This architecture enables the HA capability without any adding any addition component in option#1. Just need to add is Azure vNET peering between the PODs.
Option#3, Deploy the vIDM connectors in HUB vNET
Unlike option#1 and #2, vIDM connectors will be hosted in HUB vNET in this option. All the HCS on Azure PODs (SPOKE) will be connected to HUB vNET through Azure vNET peering. The users will be authenticated with the connector/s which is associated with the POD while configuring the “Virtual App Collection” in WS1 admin console.
In this architecture, it is not necessarily need to deploy connector for each POD. A single connector can be leveraged for multiple HCS on Azure PODs but atleast 2 connectors for the HA purpose. Number of the connectors is depends on the number of the total user`s sessions rather than the number of PODs. Refer to the doc.vmware.com for the vIDM connector sizing information. This architecture eases the integration, scaling and administration as well as reduce the Azure cost of vIDM connector VM.
