In increasingly varied IT environments, the user’s identity is the constant. VMware Workspace ONE Access (formerly known as VMware Workspace ONE Identity Manager) provides a single point for managing several functions. It combines the user’s identity with factors such as device and network information to make intelligence-driven, conditional access decisions for applications delivered by Workspace ONE.

Workspace ONE Access enables organisations to quickly and more securely implement application and device strategies that deliver consistent, enterprise-wide access to applications and data from any device in any location.

Primarily, its main use case is to provide a Single Sign-On (SSO) service for simplifying user access while maintaining control.  It also provides a portal for the presentation of web based applications as well as VDI/remote applications published by Citrix or (unsurprisingly) VMware.

Of course, a user wishing to leverage all this goodness must first prove who they are (i.e. authenticate) prior to being granted access to the glorious bounty within.  There are many weapons of choice that can be used, both in terms of product and form-factor, to identify a user and validate them.  We could be talking about the mundane – password authentication – through to Multi-Factor Authentication (MFA) tools.

This article aims to touch upon the methods available and how they integrate into Workspace ONE Access.  I’ll break it down by how they connect to Workspace ONE Access.

How VMware Workspace ONE Access handles authentication

Fundamentally, regardless of whether you deploy on premises or the preferred SaaS based offering, VMware Workspace ONE Access has a pretty straight forward architecture.  Firstly, users (and groups) are hosted in an on-board directory and entitled to resources by the administrator.  Typically, this is synchronised from a corporate directory service, though local accounts can be provisioned manually or on a just-in-time basis.

To authenticate a given user, an authentication method is first configured, and this is applied to one or more policies that control access to both Workspace ONE Access itself (the default policy) or to defined applications.

Authentication methods come in various shapes and sizes and VMware provide various means to reach them, as appropriate to the authentication method:

  • Native Methods – configured in Workspace ONE, requiring no additional components.
  • Connector – The connector is deployed on site to provide a bridge to on-premises authentication methods.
  • Third Party Identity Providers – These are registered directly in Workspace ONE Access to offload authentication to a third-party solution.

These are discussed below.

Native authentication methods

These methods are configured directly on the Workspace ONE instance and while they require some additional configuration, can be the simplest to implement with respect to deploying services.

Authentication Methods for Built in Identity Providers

Note: the first few are related to VMware Workspace ONE UEM – this is because it can leverage its own authentication.  In this scenario, the user authenticates against UEM and using either of the above will grant single sign-on access to VMware Workspace ONE Access.

VMware Verify is included with Workspace ONE and provides an optional Cloud based MFA solution.  The Mobile SSO options again leverage Workspace ONE UEM – this time to provide Kerberos (for iOS) or Certificate based (for Android) single sign-on authentication based on the device itself.

The Workspace ONE Access Connector

The Workspace ONE Access Connector is installed within the corporate estate (typically two servers for resilience).  It is intended to offer a number of services:

  • To provide synchronisation with corporate Directory Services (such as Active Directory)
  • To provide support for VMware Horizon and Citrix integration
  • To provide integration with authentication services.

The first point is pretty self-explanatory – as stated above, Workspace ONE maintains a Directory of users.  The Connector can provide a service to synchronise users and groups from the existing corporate directory service.  In the second case, the connector accesses the VDI solution and synchronises whatever published desktops and applications are being served by the VDI solution.

Connector can integrate into a number of services

The final point is the most relevant to this post.

As can be seen above, the connector can integrate into a number of services that are traditionally located within the data centre.  The most basic, usually configured when adding a directory is password authentication, however there are more exotic offerings here:

  • RSAAAIdpAdapter and SecurIDIdpAdapter are both used for native RSA authentication solutions.
  • Kerberos passthrough authentication – where configured on the endpoint browser.
  • Certificate Authentication (where a machine signs on with a signed certificate) can be configured.
  • RADIUS based solutions.

It should be noted that all but Kerberos can be configured in Outbound mode.  This is where the authentication process is carried out at Workspace ONE which passes authentication requests to the connector via the connector’s integration rather than passing the user session direct to the connector (so you don’t need public access to the Connector).  The Kerberos context here is browser-based single sign-on for trusted devices, so typically this is only deployed in an on-premises scenario.

Once a given authentication method is enabled, it can be leveraged as part of a Policy.

Third party identity providers

Within Workspace ONE itself there is an ability to add a third-party Identity Provider (IdP).  Typically, this is established by creating a mutually trusting relationship leveraging Security Assertion Markup Language (SAML).  Where this comes in useful is where there are no native integration points or where the requirement is to offload authentication to a pre-existing solution, such as Ping Federate.  Once configured, an additional (or more, subject to the solution) authentication method is added, once again for use in Policy.

Authentication methods and policy

Policy Definition - Illustrative

VMware Identity Manager uses a policy system to manage authentication.  The default policy is used to manage access to the solution and resources.  Where specifically required, other policies can be defined and assigned to published resources as required.

A policy can be made up of numerous Policy Rules.  Policy Rules can be configured in several ways, but generally take the following form:

  • If a user’s network range is…
  • And user accessing content from… (a device type)
  • And user belongs to (a group – if nothing defined – applies to all)
  • Then perform this action (Authenticate using/Deny Access/Allow access with no authentication)
  • Then the user may authenticate using (select method – multiple methods can be added as an ‘AND)
  • If the preceding method fails or is not applicable, then (select method – again, multiple possible)
  • (Add Fallback Method for another layer)
  • Re-authenticate after X hours/minutes (default is 8 hours)

Multiple Policy Rules can be deployed within a policy, to provide support for different log on contexts within that policy.

If the authentication method is native to Workspace ONE, or it’s a method configured in outbound mode from a connector, all processing happens at Workspace ONE within its user interface.  However, where the method is via the connector, but NOT in outbound mode, the client is passed to the connector URL for the authentication (though the look-and-feel is constant).  Typically, this is only used for on-premises use of Kerberos browser SSO – outbound mode is preferred.

Where the third party IdP authentication method is used in a policy and a user requests access managed by said policy, the user will be redirected to the third-party interface to authenticate.  Once at the third party, it is subject to the third party’s configuration for authentication (it might be a password or a token for example.  Once authentication is complete, the response is passed back to Workspace ONE where the user is directed to the chosen resource.

Closing Thoughts

As you can see, VMware Workspace ONE Access can be somewhat complex due to the many forms of authentication measures it can support, however this complexity is for the administrator, not for the end user – after all, the intention is to provide a slick, easy to use solution to access unrelated systems in a single sign-on way.

And this is without touching upon upstream authentication to SaaS based application, VMware Horizon and Citrix, all of which are in a single sign-on context from VMware Workspace ONE. Phew!


Xtravirt have vast experience in deploying VMware Workspace ONE and Horizon across many different environments and bring a broad range of skills and experience to the table. 

If you are interested in moving to the next level of application delivery and single sign-on, or already have a project in-flight, contact us to see how we can help.