Single Sign On: The VDI Challenge
by Curtis Brown
Authentication can be quite a complex beast, with different applications using their own authentication methods. As more and more applications become used by a business, the more authentication turns into a headache for both support and end users. Of course, as a key security mechanism, authentication is something of a necessary evil.
Fortunately, there are mechanisms that, when implemented, allow for the exchange of security tokens. SAML (Security Assertion Markup Language) is an XML-based open-standard that provides such a mechanism. It works on the principle of three roles:
- The Principal – usually the user credentials
- Identity Provider (IdP) – an identity source
- Service Provider (SP) – a service requiring authentication
One Single Sign On (SSO) solution is VMware Identity Manager (vIDM) which serves as a central point of authentication.
On one hand, it is configured with authentication sources. This could be a basic password sign on or a more advanced solution, for instance, a two-factor token solution such as SecurID or other RADIUS solutions. The relationship between the authenticator and vIDM may vary, for example, password authentication against Active Directory uses either a service account or the membership of the vIDM appliance in Active Directory.
On the other hand, integration is configured with applications to be served by the SSO solution. SAML is used to provide the configuration and the trust relationship. vIDM serves as the IdP, with the applications as Service Providers.
In between this, vIDM leverages a configured directory that maps users (or groups) to entitled applications. vIDM provides a workspace portal that can present these entitled applications to authenticated user sessions.
One of these applications is Horizon View; where both remote applications and desktops can be presented to users via vIDM’s workspace.
Authentication between vIDM and Horizon View
Horizon View uses a SAML relationship for authentication via vIDM. Horizon is the SP and vIDM is the IdP. During the Directory configuration of vIDM in particular, the distinguished Name attribute needs to be included, as this is required for the Horizon SAML token exchange. Setting up the relationship occurs on both sides. In brief:
In VMware Identity Manager’s Administration console (Under Catalog>Manage Desktop Applications>View Application) View Pools must be enabled, with the appropriate connection settings and credentials entered – oh, and remember to accept the Certificates if they aren’t already trusted!
In Horizon View Administrator, you will need to set up an Authenticator on a connection server. If you choose the setting ‘Required’, it will only accept authentication from vIDM, however by choosing ‘Allowed’as your setting, you will retain the ability to log on directly to View.
This establishes the two-way connectivity, at which point a synchronization should be carried out on the vIDM side. This pulls in a list of applications and their entitlements from View into vIDM. It would be beneficial to set a regular schedule for this. Note that Horizon View resources are entitled and managed by View and are only presented via vIDM – hence the need to synchronize.
Once the entitlements are synchronized from Horizon View, a user can log into vIDM and select a Horizon View resource. This action generates a SAML token that passes on to Horizon View, authenticating into View automatically, which in turn establishes the desktop or application session.
Where TrueSSO fits in…
Unfortunately, not all authenticators are built equally. In the simplest scenario, where the authenticator is a simple Active Directory user name and password, the SAML token passes from the vIDM session to the Horizon View Connection server, complete with all the required user attributes including the password.
However, for some third party IdPs, the user can be authenticated at the third party, with the resultant session established with vIDM via the trust mechanism with the IdP – with no user password passing through. From a security perspective, this is a good thing however, there is an issue with respect to Horizon View. In this scenario, if a user clicks on a View resource, say a desktop, the user will be prompted for a password. This is because the token from the vIDM session to Horizon View needs a password that vIDM doesn’t have. The user password is required not by View itself (as the SAML token itself is trusted) but for the guest Operating System of the published desktop. Of course, this request rather defeats the point of Single Sign-On.
However, all is not lost! In VMware Horizon View 7, an additional feature was added – TrueSSO. In a nutshell, TrueSSO intervenes in areas such as a password-less login process, by providing a trusted session certificate to the Desktop Host during the Windows logon in lieu of the password.
TrueSSO is based around three elements:
- Horizon View Connection Servers – these still handle the logon and authentication process, even when handed off from vIDM. If the vIDM token lacks a password, it checks the requested domain and passes the request to…
- Enrollment Servers – these compile a request from the Horizon Solution for a session based certificate that is passed to…
- Certificate Authority – an Active Directory based certificate authority is configured with an authentication (SmartCard) template. The Enrollment Server requests the creation of a certificate from the template, which is then used during the logon sequence onto the View desktop instead of a password.
Multiple Enrollment servers can be used for resilience and load balancing, configured as Active/Passive or Active/Active. The Enrolment Server application can be installed on the CA if this is desirable too. The VMware Horizon View 7 documentation has a particularly nice diagram describing this architecture.
Don’t forget (as I did the first time) to enable “Supress Password Popup” in the vIDM Admin page for View Pools!
The net result is that a user in a configured domain can log on, regardless of identity source, to a Horizon View resource via vIDM.
And in the real world …
I recently worked on an engagement where the customer wanted to use an Azure Active Directory solution as an SSO solution, but leverage VMware Identity Manager for publishing Horizon View based applications. Azure was configured using Active Directory Federated Services to federate with the existing on-premise Active Directory (into which the Horizon View solution was deployed). The purpose of using Azure was to provide both Smartphone based two-factor authentication for external users as well as providing access into SharePoint and other applications. All rather slick.
Unfortunately, while Azure could be used as a SAML IdP allowing Single Sign On into VMware Identity Manager, the user session SAML token didn’t contain a password. By configuring TrueSSO to request certificates from the customer’s Domain CA, we could provide an end-to-end single sign-on to desktop from an Azure log on.
If you’re interested in finding out more about how Xtravirt can assist with deploying a VDI solution, please contact us and we’d be happy to use our wealth of knowledge and experience to assist you.
About the Author
Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2016.
kyleclements
