With the Horizon Suite 6.0/6.1, it’s awesome to be able to use Horizon Workspace as a ‘dashboard’ of sorts to give access to published applications (via RDSH), full desktops, and user files. Since the latest version of the Horizon Client has support for both full desktops and published applications, the use case for Workspace is in accessing other resources. One of the most impressive things that can be done with Workspace is to provide single sign-on services for external applications a business uses.
Any external application can be integrated with Workspace if you have the development muscle to make it happen. The integration is made possible by leveraging Security Assertion Markup Language (SAML), pronounced “sam-el”, to pass authentication information to the external service. But there’s a list of applications (called the ‘cloud application catalog’) that are already prepared and tested by VMware for integration with Workspace. I’m going to show how one of these applications can easily be configured to allow users already authenticated to Workspace to connect without the need to log in again. In this tutorial, I’m going to use Salesforce as the external application, because it’s a widely used platform, and is hopefully relevant to many organizations.
Preparation
This process can seem fairly intimidating if you don’t have a development background. Rest assured that although the process is somewhat complex in the background, most of the leg-work is already done by VMware and the external service. An integration with an application from the cloud application catalog can be done in 15 minutes or less, in the easier cases. There are only a few requirements to get this working:
- Administrative access to the organization’s Salesforce portal
- Administrative access to Workspace
Depending on the platform, this process may or may not be entirely self-service. Some platforms like ADP do work, but require intervention from folks at the other end. In the case of Salesforce, however, it can all be done by internal IT staff.
Prepare Workspace
This configuration will take place in three steps: prepare Workspace, configure Salesforce, and finally configure Workspace. To configure the Salesforce integration with Workspace, one first needs to add the Salesforce app from the cloud application catalog. This is done from the Administration Console of Workspace.
Choosing Salesforce from the list of tiles is all it takes to add the application. A UUID is generated for this particular application, which is for various reasons, but an important note is that this would allow connections to multple Salesforce portals from within one Workspace instance. If different departments in an enterprise have their own Salesforce platform (hopefully not!) then the UUID would allow multiple integrations to co-exist. The next step is to entitle a user or group from the Entitlements section. In my case, I’m using an AD group called ‘Salesforce_users’ to grant access. I’ve also got the Deployment mode set to Automatic, which will cause the application to appear in the users’ dashboard without needing to be added manually. Done forget to hit “Done” on the entitlements page after adding a user/group to make sure that the change is applied.
The last step before configuring the Salesforce side is to grab the SAML certificate and IdP metadata. This is the way Salesforce will know that requests to authenticate are coming from Workspace and are legitimate. Browse to the Settings tab > SAML Metadata section. You should see a ‘Signing Certificate’ in the pane on the right. Copy this into a text editor and save it as Workspace-SAML.cer. This certificate will get uploaded on the Salesforce side shortly. Also, download the IdP metadata XML file from the same screen. This will provide a URL string that is needed on the Salesforce side. Go ahead and name this IdP.xml for future reference.
Configure Salesforce SSO
Salesforce is a Behemoth of a platform, and the possibilities of what you can do with it are as varied as they are exciting. Because of it’s sheer breadth, navigating around the interface can be a bit daunting. I’m including a screenshot below to help get to the right place. Begin by clicking the ‘Setup’ link in the top right corner. Under the ‘Administer’ section, expand the Security Controls area, and select Single Sign-On Settings. Finally, click the Edit button and check the box to set “SAML Enabled.”
It’s time to configure a SAML federation with Workspace. Click on the New button, and say hello to the most daunting screen of this whole process. But have no fear, it’s really not as bad as it looks, and all of the required details can be found in information gathered earlier. I’ll walk through each field, and show a completed screenshot at the end.
- Name: Name it whatever you want.
- API Name: This should be automatically populated based on what is entered in the Name field.
- Issuer: Grab this from IdP.xml; there’s a field called ‘entityID’ on one of the first couple lines. That goes here, and it will look something like this: https://workspace.virtadmin.local/SAAS/API/1.0/GET/metadata/idp.xml
- EntityID: Enter the same URL as the Issuer field
- Identity Provider Certificate: Upload the SAML signing certificate that was downloaded called Workspace-SAML.cer
- Request Signature Method: Leave unless you know enough to know why you want to change it
![🙂]()
- Assertion Decryption Certificate: Because of the configuration, this doesn’t change
- SAML Identity Type: Leave this at the default – Assertion contains User’s salesforce.com username.
- SAML Identity Location: The default here will also work well – Identity is in the NameIdentifier element of the Subject statement
- Identity Provider Login URL: This will be /POST/sso following the Workspace API URL – mine looks like this: https://workspace.virtadmin.local/SAAS/API/1.0/POST/sso
- Identity Provider Logout URL: This is where users will be directed to when signing out of Salesforce. I sent them back to the dashboard. https://workspace.virtadmin.local/SAAS/
That’s it! The last thing to do here before heading back to Workspace is to download the Metadata XML. This can be imported on the Workspace side to simplify the configuration.
Configure Workspace
The last step in this process is to go back to Workspace and configure the Salesforce application with the endpoint we created on the Salesforce website. This would usually entail some manual configuration, but since we downloaded the metadata XML for the endpoint from Salesforce, it’s really simple. Go to Catalog > Salesforce app > Configuration in the Administration Console. Half way down the page, select the middle of three blue buttons, opting to Configure Via Meta-data XML. Once the view has flipped, paste in the contents of the XML file that was just downloaded from Salesforce.
Click Save. Click back to the User Portal and give it a shot! You should be able to click the Salesforce application and be redirected to Salesforce and logged in as your user without entering credentials. In this tutorial, it is assumed that the Salesforce login ID is the user’s e-mail address. This is the default for Salesforce. If something different is in use, the Name ID Value field will have to be modified on the Workspace side to pass the correct login information.
Hope this has been helpful in showing that SSO configuration of an external application with Workspace isn’t as painful as one might imagine. Now, configuring this with a homegrown webapp that doesn’t have support for SAML federation already… That’s a whole different ballgame.
This post was first published on VirtualizationReview.com on May 11, 2015.
https://virtualizationreview.com/articles/2015/05/11/external-applications-with-vmware-horizon-workspace-and-saml.aspx