When you integrate Workspace ONE Access with Horizon you can take advantage of the Unified Digital Workspace as well as the conditional access capabilities including 3rd Party IDP Integration, Risk, and Mult-Factor Authentication. In this blog, I’m going to walk through the SAML flow because it might be a little different than what you’ve typically seen before.
In this example, I’m going to assume that Azure AD is configured as a 3rd Party IDP inside of Workspace ONE Access.
At a high level, here is authentication flow:
Let’s walk through this flow in more detail:
Azure Authentication
This part of the authentication flow is pretty standard. When you go to Workspace ONE Access, the default policy will automatically trigger an HTTPS POST to https://login.microsoftonline.com
Once you authenticate on the Azure AD side, Azure will send a response back to Workspace ONE Access with the correct value in the NameID:
Depending on your mapping configuration in the 3rd Party IDP configuration, the subject will be mapped accordingly to match the user in Workspace ONE Access.
SAML from Workspace ONE Access to the Horizon Connection Server
When you access a virtual application from Workspace ONE Access, you can apply conditional access policies such as MFA or Risk before attempting to access the virtual resource. We won’t go into that specifically in this blog. For now, we’ll focus on the SAML.
When working with SAML, we typically use the HTTP Redirect or HTTP POST Bindings.
The important thing to understand with the HTTP Redirect and HTTP Post bindings is that all communication is between the client and the identity provider or the client and the service provider. There is no communication between the service provider and the identity provider.
The Workspace ONE Access and Horizon Integration uses a SAML Artifact Exchange. You rarely see SAML Artifact anymore. It was typically used for one of two reasons: 1) There is a large amount of information contained in the response 2) You are sending sensitive information in the response and you don’t want this information passed in browser headers. A SAML Artifact exchange will look something like this:
This is an important distinction because now you need to make sure that your Horizon Connection server can talk to the Workspace ONE Access service. I’ll cover outbound proxy servers later. When Workspace ONE Access Launches the Virtual Desktop, it will include a “SAMLArt” in the GET request:
GET
https://horizonserver/portal/webclient/index.html?desktopId=cn%3Dconnectorservers,ou%3Dapplications,dc%3Dvdi,dc%3Dvmware,dc%3Dint&desktopName=My%20Desktop&SAMLart=AAQAACUBQH%2BucnN6nZeiM03zpgBLxMcNbptQk3PSGzRXn2szAqtB5lxctWo%3D&user=steve&domainName=1dsavm.com&horizonId=1a3f9d62-a288-40ee-80dd-18479df96693&spID=719fc36f-3643-3c2b-9591-aecd5fbccda4
Once the Horizon Connection server receives this request, it will make an outbound call directly to the Workspace ONE Access SAML Artifact Resolver:
POST https://dsas.vmwareidentity.com/SAAS/auth/saml/artifact/resolve HTTP/1.1
You can see in the above code snippet that the SAML Artifact is included in the SOAP request sent from Horizon to Workspace ONE Access.
The response from Workspace ONE Access will be different depending on whether True SSO is enabled:
It will send the UPN in the NameID:
Along with the requested Virtual Resource:
If True SSO is not enabled, the Horizon Connection Server will require the password for the user. This password is communicated as an encrypted attribute:
Given the potential for sensitive data being sent from Workspace ONE Access to Horizon, it makes sense that the SAML Artifact Binding was chosen.
Configuring a Proxy Server in the Horizon Connection Server for Workspace ONE Access
If your Horizon Connection server requires an outbound proxy, you will need to use ADSI Edit to configure the proxy server.
- Using the Server Manager, launch ADSI Edit from the tools menu
- In the Connection Settings: Enter: “dc=vdi,dc=vmware,dc=int” for the Connection Point and “localhost:389” for the server.
- Expand “OU=Properties”
- Expand “OU=Global”
- Open “CN=Common”
- Edit the values for the entries “pae-SAMLProxyName” and “pae-SAMLProxyPort.”
- Click OK
- Restart the Connection Server
Steve The Identity Guy 
This is really great! Often there will be a Unified Access Gateway device between an external Horizon Client and the internal Connection Server, and I have struggled mightily with how to configure that UAG for SAML when the IdP is Workspace ONE Access instead of Okta and TrueSSO is involved. There is good TrueSSO documentation, good Okta/UAG SAML documentation, and good Okta/Workspace documentation, but there is no good UAG/Workspace documentation… any suggestions? Can’t seem to just substitute Workspace metadata for Okta in the Okta/UAG integration document.
LikeLike
Hi Chris, Thanks for the comment. I think the reason there is no documentation on that particular setup is because the integration between Workspace ONE Access and Horizon (via UAG) is designed with UAG in a pass through mode so UAG is not enforcing any authentication. In this configuration, Workspace ONE Access will present the Horizon Applications within Access. Now that being said, I can understand the use case which you are talking about. In fact, on my recent Fido2 WebAuthn blog I have a video (the MacOS video) which shows the flow of using a horizon client to authenticate to WS1 Access via UAG. However, in that setup, I’ve configured WS1 Access as an IDP for UAG. Is this something you would be looking for instructions on how to configure?
LikeLike
So right… we are doing this today. We have the UAGs configured in pass-through mode, which does seem to allow TrueSSO all the way into a desktop/app from WS1A. The problem I have is that, with passthrough enabled, users (if they figure out the UAG address) can authenticate at that address directly with single-factor, as opposed to the Okta MFA requirement they hit when logging in at the WS1A portal. So a savvy WS1A user who doesn’t feel like the MFA requirement (or a bad actor) could just launch a Horizon Client pointed at the UAG address and login directly there without the MFA prompt. I’ve adjusted the proxypattern so this isn’t available for web browsers (only the client), but I really need to lock it down fully.
It’s entirely possible we’ve done something wrong, but does this make sense?
LikeLike
Chris – Did you configure Workspace ONE Access as “Required” on the connection server. If you do this, it odes not allow direct access via the Horizon Client. All launches of Horizon Apps will need to be done via Workspace ONE Access (but can still open in the Horizon Client). The most restrictive option is to enable “Workspace ONE Mode”. Please make sure you validate all your use cases to make sure they still work once you’ve enabled Workspace ONE mode.
LikeLike
Ah… this may be the trick. We have one pair of internal brokers. These are used by our internal Horizon Client clients, our external Horizon Client clients via UAG, our IGEL clients, AND they are the target VIP for the UAGs dedicated to WS1A. Internal Horizon Client clients typically just Login as Current User or manually enter name/pass, which is why we have SAML auth set to “Allowed” instead of required. I also don’t think WS1A mode would work well with our IGEL clients, but not sure… need to test this.
But so, if we stand up another pair of brokers dedicated as the WS1A UAG target VIP, we could likely set those to SAML only and WS1A mode, which would prevent external single-factor logins. Right?
LikeLike