March 22, 2024

Introducing Horizon Cloud Entitlement On-Ramp - New feature for Horizon

Horizon Cloud Entitlement On-Ramp enables you to burst a Horizon deployment using public cloud infrastructure capacity, with minimal change for end-users.

Bursting with Horizon 8

Sometimes you run out of capacity in your Horizon 8 deployment or have a requirement to provide resources to a large group of new users.  You may be forced to leverage a cloud-based service provider like Microsoft Azure for additional temporary capacity.  As a Horizon 8 customer, with a Horizon Universal License entitlement, you can use the Horizon Cloud service to help you. 

The new Horizon Cloud Entitlement On-Ramp feature, introduced in Horizon 8 2312, is the first step in our efforts to provide unified brokering to all Horizon users.  Horizon Entitlement On-Ramp enables you to provide resources from Microsoft Azure without any changes to your users’ Horizon Client configuration.  It presents a user’s entitled resources available in the Horizon 8 deployment and any entitled resources in a Horizon Cloud Service – next-gen deployment in the Horizon Client together.

Brokering with Horizon 

One of the main differences between Horizon 8 and Horizon Cloud Service is how each platform handles brokering.  Horizon 8 was designed to be self-contained with all of the functionality required for operating virtual desktops and applications service on a given customer’s environment. All brokering is done within a Horizon 8 pod – even with a multi-pod configuration.  The pods communicate user and capacity availability to each other to provide end-users with a single UI for all their entitled resources.

Figure 1: Basic Horizon 8 brokering example.

In Horizon Cloud Service, brokering is a part of the shared application service that we host instead of within a customer’s infrastructure.   This allows customers who are primarily leveraging public cloud services for infrastructure capacity, a reduced footprint in their public cloud deployment, resulting in a lower infrastructure cost.  Since all brokering is managed by Horizon Cloud Service, customers can deploy pods in different public cloud infrastructure locations and provide end-users with a single UI of all their entitled resources.

Figure 2: Basic Horizon Cloud Service brokering example

Let’s say you have run out of infrastructure capacity in your Horizon 8 deployment or have a requirement to provide resources to a large group of new users, forcing you to leverage a cloud-based service provider like Microsoft Azure for additional temporary capacity.  If you are a Horizon 8 customer and want to burst out to leverage a cloud service with minimal change for your end-users, you want to portray these two environments together in the same UI rather than train new users to use the new environment in Microsoft Azure.  As a Horizon 8 customer, with a Horizon Universal License entitlement, you can use a new feature called Horizon Entitlement On-Ramp along with the Horizon Cloud Service to handle this. 

Horizon Entitlement On-Ramp Explained

The idea behind On-Ramp is simple.  We have enabled the Horizon Client to ask multiple implementations of Horizon for a list of entitlements for a given user and display them in a single UI.

A user launches their Horizon Client and authenticates to the Horizon 8 Connection Server as normal.  The user’s Horizon 8 entitlements are returned to the client, along with a short-lived JSON Web Token.  That token enables the Horizon Client to communicate with the Horizon Cloud Service and authorizes the client to look up that user’s entitlements.  Since both environments are connected to the Horizon Cloud Service, and are using the same directory of record, the service is basically using the Horizon 8 Connection server as an Identity Provider to authorize the user. 

All of the entitlements from each platform are presented in the Horizon Client.  From there, the user selects the resource that they want to use and SSO and brokering happens normally based on where the resource was located.  The diagram below depicts this with the assumption that the end-user is launching a resource from Microsoft Azure infrastructure.  Note that the brokering experience for Horizon 8 and Horizon Cloud Service does not change with this new feature, only the user resource selection within the Horizon Client changes.

Figure 3: Horizon Entitlement On-Ramp feature diagram

For Horizon 8 deployments, the users are brokered to workloads via the Connection Server which is hosted in each Horizon 8 pod in your infrastructure. For more information, see the Architecture Overview section of the   Horizon 8 Reference Architecture.

For Horizon Cloud – next-gen deployments, users are brokered to workloads via a component in the Horizon Cloud Service, hosted by VMware. For more information, see the Architecture Overview section of the  Horizon Cloud – next-gen Architecture.

Prerequisites for implementing Horizon Entitlement On-Ramp

The basic prerequisites require that your Horizon 8 environment and your Horizon Cloud Environment IDP are each synchronized with your directory of record.  The Horizon 8 environment will issue Java Web Tokens to the Horizon Client that are presented to the configured IDP for Horizon Cloud Service.  This will only work if the directories used for each deployment is the same.  All of the critical prerequisites that are outlined in the product documentation

First Step on the Path to Unified Brokering

Horizon Entitlement On-Ramp is the first step for us to provide our customers with a unified brokering experience that minimizes the amount of re-configuration for your end-users. More capabilities will be available for other use cases in the coming months.  Keep an eye out in the Horizon Cloud Service – next-gen Release notes for more information.

Horizon Client with Horizon 8 and Horizon Cloud Service admin UIs

Figure 4: Example of Horizon Client showing Entitlements from Horizon 8 and Horizon Cloud Service in same UI.

 

Filter Tags

Horizon Horizon Horizon Cloud Service Blog Announcement Overview