Workspace ONE Access Horizon Args

I had an interesting customer use case last week that called for some ingenuity with how we establish Horizon app launch URIs in Workspace ONE Access. In short, a 3rd party agency required management access to retail location IoT devices on a closed network. These contractors were road warriors of sorts; sometimes onsite, but more often than not, out in the field servicing other customers of their own. We call this the “managed aisle” use case in my world, referencing a common retail arrangement where 3rd party vendors manage certain retail product aisles in a store (i.e. beverages).

The customer was already using Workspace ONE as the unified app catalog for their enterprise and third party MSPs, publishing an assortment of management and enterprise tools that could only be accessed when on the intranet. They also had an existing Horizon RDS farm deployed with the same management suite for badged resources to perform similar functions on company-owned equipment. So the question became, how could we breadcrumb the user experience in such a way that a contractor could continue consuming applications from the catalog while offsite, but in a natural workflow that abstracted the decision point of when to consume native vs. RDS? Enter: Horizon arguments


Horizon argument URIs have been around for a while, but what is less commonly known is that Workspace ONE Access will pass these arguments through to a WS1 mode initiated launch (limited support). This, combined with some custom failure messaging and access policies, is what we use to dynamically breadcrumb the user from a native app launch to one that was secured by Horizon RDS.


  1. You have a fully functional Horizon and Workspace ONE Access environment
  2. You’ve published a web browser application from a Horizon RDS farm (I’m using Google Chrome for this post)
  3. You have configured Workspace ONE mode for the Horizon Pod
  4. Bonus: TrueSSO configured between Workspace ONE Access and Horizon

All of the below configuration is defined in the Workspace ONE Access admin UI.

App Configuration

To demonstrate the capability, let’s use NSX Manager as the application we want to dynamically secure. NSX Manager lives on a closed management network in my lab and makes for a great example of this functionality (I’m always on the road).

First, we need to create a web app link (or SAML/OIDC app). Remember, the underlying resource to be consumed is a web app, not specifically a published app:

Access Policy

This is the configuration item that drives the dynamics. We’ll assume for the design that the condition which dictates the consumption medium (native v. Horizon) is “Network Range”. That seems suitable given intranet access from the client wouldn’t warrant the need for a published app.

Define a “Network Range” that is inclusive of your intranet source IPs (for SaaS WS1 Access, this is your intranet SNATs; for on-prem WS1 Access, this is likely a subset of RFC1918 blocks):

Create a new access policy and assign it to the application you created above:

In the “Configuration” section, let’s define the first three rules:

  1. iOS devices from any source IP – Deny Access
  2. Android devices from any source IP – Deny Access
  3. Any device type from the “Network Range” you defined above – Allow Access

This renders an effective policy that mobile devices will not be allowed access to the sensitive application (may or may not suit your use case), but workstation form factors (including browsers) on the intranet will be conditionally allowed upon satisfying the authentication methods you define.

Lastly, we need a fourth rule to serve as a “catch all” for the remote workstations attempting to access the web app. This is where we will tailor the failure presentation so that the user can breadcrumb to the app via Horizon RDS.

First, let’s define the rule so that all device types from all source IPs will be denied access:

Then, expand the “Advanced Properties” section and define a custom error message and link details:

In my example, I chose:

You are attempting to access a resource that is only available on the intranet. Please click the launch link below to gain access to NSX Manager.

This is straight forward language to sign-post the user to the link presented below the text. The finished access policy:

Save the access policy, then test a launch from a remote IP address. If configured correctly, you’ll be presented with a screen similar to the below:

Selecting the launch link will auto-launch the published browser, supply the URL of the web app you defined in the custom link URL, and potentially SSO if said application is federated with Workspace ONE Access.

The Launch Link

Let’s breakdown the structure of the “Custom Error Link URL” that we defined above. First, the link as a whole:

WS1 Access Tenant – https://{tenant}

This is nothing more than the Workspace ONE Access tenant front door. Replace {tenant} with your WS1 Access subdomain.

Chrome Published App URI – /SAAS/API/1.0/GET/apps/launch/app/fa9fac43-4ed4-4ecd-a8ec-f3a0e7e74e3c

This is the GUID of the Google Chrome browser published app from Horizon. Navigating to this link directly would launch Google Chrome in either the HTML5 or Win32 Horizon client (based on user preferences in WS1 Access):

Published App Argument – ?args=https%3A%2F%2F{subdomain}

This is the hex encoded argument that Workspace ONE Access will pass through to published Chrome upon launch. The user will obviously notice a slight delay in launch since we are setting up an RDS session behind the scenes vs. natively launching an app in the local browser. However, the published browser will automatically navigate to the originally requested app, and if federated with Workspace ONE, automatically SSO!


As documented here, this functionality isn’t limited to a managed web application, but rather universal to Horizon as a whole. For example, you could extend this capability to Win32 published apps as well. Overall, consumer simple and enterprise secure!

Tags: , , , , , ,