Introduction
Horizon Cloud Service on Microsoft Azure (HCS Azure) provides two distinct brokering methods for delivering remote resources from your HCS Azure pods to end users: 1) Universal Broker and 2) single-pod broker. In this post I will explain about what the Universal Broker is and how the user authentication and protocol traffic flows while the users are accessing Horizon Cloud virtual desktops and RDSH published applications.
VMware Universal Brokering (UB) is a cloud hosted brokering solution, also known as “NEXT-GEN BROKERING”, publicly available from Horizon Cloud Service (HCS) September 2020 release. Unlike the single-pod broker, the user authentication (primary XML API) for all associated PODs happens through the UB and only protocol traffic (Blast/PCoIP) routes through the Unified access gateway (UAG).
Universal Brokering Logical Architecture
Benefits of Universal Broker
- Universal broker provides a single fully qualified domain name (FQDN) to access the resources from multiple HCS Azure PODs.
- Eliminates the requirement of 3rd party GSLB solution for scaling.
- A single assignment can be spanned across the multiple HCS PODs regardless of Azure location.
Note: As the UB is cloud hosted brokering solution, client device MUST have reachability to public internet to use the Universal Broker feature. System requirement for Universal Broker can be found here.
Users authentication and brokering flow
1. User access UB FQDN (primary protocol XML API) through internet to login with AD username and password.
2. UB forwards the Auth request to a random POD manager (aka Node Manager) with encrypted format.
3. POD manager decrypts the password and forward it to ADDS for Authentication.
4. If the user is authenticated, POD manager returns the status of auth to UB (a session object will be created here with user information).
5. UB sends the list of the entitled pool/desktops to user. If user is not authenticated, UB closes the connection with client.
6. User selects a pool/desktop icon in browser or Horizon client. UB verifies if ongoing session exists for user (floating pool). If there is no existing session for the user, UB elects a POD based on POD health, availability, homesite settings and geo detection (if applicable).
7. UB asks to POD manager to allocate the desktops for the user.
8. POD shares the desktop detail to connect + JWT (JASON Web Token) token. UAG also gets the same JWT token from POD manger. JWT token is unique for every new user session, valid for 5 minutes.
9. UB adds the POD`s FQDN on top of the detail shared by POD @ step #8 and send the info to client.
10. Client presents the desktop connection information received from UB at step #9 to UAG and establish the connection to desktop.
Note: Once the client established the protocol session with desktop, UB adds the desktops information in session object created in #4. Maximum lifetime of session object is 24 hrs.
Known Limitations
As of October 31, 2020 release, Universal Broker supports a certain subset of Horizon features. Please visit docs.vmware page for the detail information.
Conclusion
Universal broker provides a single FQDN to access the resources from multiple HCS Azure PODs. A single assignment can be spanned across the multiple HCS Azure PODs. The desktop will be allocated to user from any of the POD associated with Universal Broker based on the POD availability, home-site configuration and geo detection. This feature greatly helps to the customers who have multiple PODs under a single HCS control plane account and the customers who are looking for the disaster recovery capability on Horizon Cloud on Azure.
Hopefully this blog helps you to better understand about Universal Broker feature, user authentication and horizon protocol traffic flow.
