Configuring Mobile SSO for iOS Devices in Workspace ONE

One of big differentiators we have with Workspace ONE is ability to use MobileSSO to drastically improve security and the user experience.

MobileSSO with Workspace ONE leverages certificates deployed to devices to seamlessly sign the user into the Workspace ONE Intelligent Hub and any federated SaaS services.

This solution requires both Workspace ONE UEM (to deploy and manage the lifecycle of the certificates) and Workspace ONE Access (to challenge the device for the certificate and authenticate the user). On iOS MobileSSO technically uses Kerberos by validating the certificate on the device and generating a Kerberos token the device can then present back for authentication.

In this post I'll discuss how to configure Workspace ONE Access for iOS MobileSSO and how to create a profile in Workspace ONE UEM to deploy the required certificate and approve the domains and applications that can use it.

Enabling Password (Cloud Deployment) Auth Method in Workspace ONE Access

In our current configuration, when we try to authenticate as a user in Workspace ONE Access it will probably fail. This is because we don't have an authentication method available to users that is able to authentication successfully.

The simplest way to do this is to enable Password (cloud deployment) so that our users are able to authenticate with their Active Directory credentials using the Identity Manager Connector we installed and configured. What's great about this method is that its outbound meaning that a user authentication request never comes inbound so there's no inbound firewall rules.

Let's look at how to configure this authentication method and set up our default access policy to use it.

Using Google Cloud Identity Secure LDAP with Workspace ONE

Most of my posts on my blog here have been about how to integrate other Identity Solutions with Workspace ONE.  However, the thing that all of these typically had in common was that they were synchronised with an On-Premises Active Directory.

This works well, but what happens when a customer has no On-Premises AD or is trying to get away from using one?

About a year ago, Google Announced their Cloud Identity Premium product which included a preview of LDAP connectivity. I played around with it then and it was good but for our purposes I could never get it to work - it requires the client service to use certificates to authenticate which is something that Workspace ONE doesn't support.

Recently a few customers have been asking whether there was ways to use Google Directories within Workspace ONE other than Just-In-Time provisioning and seeing that Secure LDAP from Google was now Generally Available globally it thought I'd give it another look.

Turns out I was able to get it to work! Read on to work out how, with some help from my colleagues, I was able to get it all integrated.

Federating Multiple Identity Managers for VMware Services

For those who may have wondered, yes I am still alive.

It's been a massive few months with overseas travel, new certifications and being admitted as a VMware CTO Ambassador. I'll make sure I write about all of this another time.

For background there has been a decision made by VMware recently where a lot of our Non-EUC solutions include a VMware Identity Manager licensing entitlement. What this is meant to allow is something like VMware Log Insight to be able to authenticate with Identity Manager allowing simplified SSO for administrators. This entitlement to Identity Manager is for the On-Premises version only.

So now, let's go into this scenario posed to me recently. What if that customer already has an entitlement to a SaaS Identity Manager tenant? Do they need both? Without opening a can of worms and entering the realms of licensing, the answer is "probably" and it's actually not a bad thing. Their situation was that they had some users who needed access to Log Insight that had an entitlement to a Workspace ONE SaaS license but not all of them. This meant we had to leave Log Insight federated with the On-Premises Identity Manager. If there is where we stopped everything would have worked, but the user experience would be pretty ordinary as they'd need to authenticate to both Identity Managers.

That's not how we roll at VMware! Lets make it simple!

Enhancing your Zero Trust Architecture with Okta Identity Cloud and Workspace ONE

I feel like it shows the quality and strength of a vendor's solution when we can confidently stand behind what we do and are also aware enough to partner with others to provide better experiences for our joint customers. One of the best examples of this is Okta and VMware coming together to jointly work on and promote a unique partnership where we can leverage the best of both vendor's portfolio to provide the best user experience while ensuring security for your Organisation.

Outside of being how it all works and integrates (which I'll deep dive into shortly), I am often asked what the value is for customers. Okta Identity Cloud (as the name suggests) is a cloud-based Identity and Access Management solution that enables Single Sign-On the User Lifecycle to Modern Applications and Services. According to their website, they have over 5500 out-of-the-box integrations and have been consistently called out as a leader in their field.

I have been developing with and using Okta for nearly a year now as part of the VMware and Okta partnership. I've found it very powerful and easy to manage, and it seems more and more customers in my region are finding this too. With this, they are now looking to leverage the integrations between Workspace ONE and Okta Identity Cloud to take their Digital Workspace to the next level.

At the risk of taking the wind out of this post's sails, VMware has a page dedicated to this partnership but I still seem to get asked Why is there a Partnership, What is the Value, and How does it Work? So with this post I am going to answer this.

So channelling my inner Simon Sinek, lets Start With Why?

Using Azure AD B2B Guest Accounts in VMware Identity Manager

Creating and managing the lifecycle of user accounts for users outside your organisation painful. Whether they are for contractors or external vendors, the time in creating these resetting passwords and then deprovisioning them is very time consuming - let alone the security implications if the accounts aren't removed.




A little while ago I was introduced to Azure AD Guest Accounts by a colleague. Guest Accounts are part of the Azure Active Directory Business to Business (B2B) capability where you can invite users from another Organisation's Azure Active Directory to have access to resources in yours. This means that if you have a Cloud Application federated with your Azure Tenant, you can simply invite their account and once they accept they can log in with their existing credentials and gain access.

This sounded great. But what I realised was that we were able to leverage this for using Guest Accounts in VMware Identity Manager. When using Azure Active Directory as a 3rd Party IDP in Identity Manager, you can invite a user to your Directory and they can log into Identity Manager and access the portal and any SaaS Applications you assign. You don't need to manage their account - if they forget their password its done at their Company's end, and you can even enforce additional Multifactor Authentication.

The requirements for Guest Accounts in Identity Manager are:

• Your ‘Organisation’ must be using Azure Active Directory (doesn’t require Premium).
• The ‘Guest’ account you are inviting must be an Azure AD account from another directory or be a Microsoft Account.
• The ‘Service’ you’re entitling the Guest User to must have an account with a valid SAML attribute/NameID format. You can also use JIT to provision accounts into this service as well.
• You need to have configured Azure Active Directory as a 3rd Party IDP in Identity Manager.

Let's go through how this all fits together.

Using JIT to Provision User Accounts into Workspace ONE UEM

A few days ago I mentioned in an article with the shocking news that not everyone had Active
Directory for their user accounts. I talked about Just-In-Time Provisioning into Identity Manager
using Google Cloud Identity as the IDP. Now, this is great for getting user accounts into VMware Identity Manager but without an AD/LDAP directory to sync to our Enterprise Systems Connector with Workspace ONE UEM doesn't have a way to get user accounts automatically.



Well that's not technically true.

A while ago myself and a colleague had this exact scenario - a customer only used Google Cloud Directory and needed to get accounts into  Identity Manager and Workspace ONE UEM. What we discovered was that we were able to also JIT user accounts into Workspace ONE UEM during enrollment. This meant we didn't have to manually create accounts in Identity Manager or Workspace ONE UEM because we couldn't use the Enterprise Systems Connector due to not having an LDAP source.

Here's how we did it.

Google Cloud Directory as a 3rd Party IDP in VMware Identity Manager

Believe it or not, not everyone uses Microsoft Active Directory for their User Directory. Even more shocking is that many customers are using GSuite - not Office365 - for their Productivity Apps, Google Pixelbooks as their devices, and if they're smart Google Pixel devices for their mobile devices. Obviously all managed by VMware Workspace ONE UEM.

All jokes and shameless plugs aside, I am starting to see a few customers now who live only in the Google ecosystem and don't need or want to keep other services. They only use GSuite and as a result they don't have Active Directory to sync to Identity Manager and I'm being asked by colleagues around the region on how to use all the benefits of Workspace ONE UEM while still being able to leverage their Google investment.

Below, I am going to start off by showing you how to configure Google as a 3rd Party IDP in Identity Manager. There will a follow up article to this in the coming days which will talk about how to also use this configuration with the Workspace ONE UEM (Airwatch) components to round out the full set of capabilities.

This article will show you all the steps to add Google as a 3rd Party IDP in vIDM, add users via Just-In-Time Provisioning and sign into Identity Manager.

Lets dig in.

What is Just-In-Time Provisioning?

Managing user accounts and identities is pretty a pretty tedious task.
One of the biggest benefits we talk about with Single Sign On and SAML authentication is the
ability Airwatch Workspace ONE UEM etc.) a user account needs to exist in that service for the user to sign in to.
to federate services to Identity Manager, but in order for a user to be able to sign into those services (Salesforce,

With any Identity Provider -  Identity Manager, Azure AD, Google IDP etc. -  typically those user accounts are synchronised with an On-Premises directory. If you're not synchronising those from another directory using some form of sync tool, you are manually creating those either via bulk upload, or even worse, manually typing them in.

The same requirement exists when you're using a cloud service. A user cannot log in with an account. Something somewhere is the source of truth of all user's identities, but having multiple sync tools out there syncing user accounts is not great. Wouldn't it be great if there was an easier way?

This is where Just-In-Time (JIT) provisioning comes in.

Azure Active Directory as a 3rd Party IDP in VMware Identity Manager

For my very first (technical) post I wanted to start with a bang.

As I mentioned in my introduction, I am Subject Matter Expert (herein and forever referred to as SME to save on typing) in VMware Identity Manager (vIDM) and all the things that come along with it. This along with my enjoyment of tinkering, integrating and playing with things, I talk about Identity and Authentication a lot with my customers and the one thing that keeps coming up a lot is how can they integrate vIDM with Azure Active Directory. Whether customers are actually using AAD or not is a different story, but it seems that everyone is at least looking at it. 

I'm not going to get on my soapbox about how Azure Active Directory is not a replacement for Microsoft Active Directory Domain Services (yet), but I will outline the steps required below to integrate vIDM and Azure AD and allow users to authenticate with the AAD credentials.

Why do they want to do this? There could be a few reasons:

• They want to use Microsoft Risk Based/Conditional Access Policies.
• Their SaaS Applications are federated with Azure AD and don't want to change this to vIDM.
• Because they can (just like I wanted to prove).

VMware Identity Manager is a great product and can do all kinds of things that Azure AD doesn't, but I think it's important to point out how we can use the best available for the customer's requirements.

Anyway enough justification, in the steps below I'll show you how to do it.

Adding Azure AD as a Third-Party IDP in Identity Manager

This is a straight forward process. In your Azure Portal you need to create an 'Enterprise Application' (your Identity Manager Tenant) and then add Azure AD as a third-party IDP in Identity Manager.

1. Login to your Azure Portal https://portal.azure.com and select Azure Active Directory.

2. Find 'Enterprise Applications' in the list under Manage and then 'New Application'.