Greetings everyone!

So… most of us have learned a few things about Android in the enterprise environment especially in regulated environments:

1. It’s a major pain in the ass
2. The business users that use it have high expectations
3. It’s impossible to manage

Ironically, in my career usually like 5% of our users actually use it and they are more vocal than the 95% of iOS users. So what do you do?

I tend to follow a few ground rules:

1. I lock it down to a few OEMs
2. No internal access
3. I require very specific OS versions

I’m sure Jason Bayton will criticize me for it and that’s okay. I’m glad that people in Europe are more progressive when it comes to technology. Eurasia typically have geo-economic concerns and focuses that make them a bit more flexible. Most CIOs or CISOs that I know have basically said “Yeah we allow it, but I wish we never did.” It’s the whole adage of not being able to unring the bell or whatever.

Anyways, I’ve always looked at Android (and yes I’ve owned a few over the years) as mitigation. The focus of this article is about VMWare Workspace ONE’s hidden gem: Mobile SSO. So why do I love this so much? Because, pretty much no one offers mobile SSO that is fully seamless. I know a few of the vendors like Ping and Okta do something “similar” but it’s just not seamless enough. Let’s get started!

Android SSO Infrastructure

We want to make sure you understand how it “actually”  works since I can guarantee your security department will ask you. Below is a nice diagram you will find in the VMWare public documentation found here.

Simply without getting too crazy, this is what happens: (Ignore the numbers in the diagram as I will make it much simpler)

1. Device goes to the application
2. Application redirects you to VIDM over HTTPs/443
3. The VMWare Tunnel will instruct your device to open a tunnel over port 5262 to perform the certificate actions for the SSL tunnel and validating certificates
4. The certificate is extracted and stored locally to validate and certify access
5. Once completed and successfully authentication, the SAML token is provided back to the application and access is granted

Now that you know the basics on how the “magic happens”, we can move onto how to actually make it happen!

How to Achieve Android SSO in VIDM

In Android SSO in VIDM, we have a few key players:

1. Workspace ONE Tunnel Android Application
2. Certificates
3. Workspace ONE Tunnel Configuration
4. Per App VPN
5. VIDM Android SSO Endpoint

We will cover these different items and how they work together to deliver seamless experiences. The focus on this article will focus on a specific basic use case (Android SSO for a public SaaS application like O365/WebEx/etc) because its simpler and it would take a lot more time to dig deep into how to make it work for internal applications.

Workspace ONE Tunnel Application

The Tunnel application’s role is pretty basic. The tunnel is basically the taco shell for the whole thing. The tunnel will provide the certificates/universal identifier and “tunnel” between your device and the SSO endpoint mentioned later on.

You will literally just deploy the Tunnel application to your devices after enrollment preferably with Android Enterprise (which is the model I’m that fond of, I know its my OPINION!). It will install during your enrollment and you will be prompted to enable it by your device. Pretty simple outside of that.

Certificates

Your VMWare Tunnel has two different certificates that you can deploy to further the security of the model, which is always recommended. You have the SSL certificate and the device-specific certificates.

As you can see below, you set it up during the VMWare Tunnel configuration. You leverage your DCOM/SCEP setup in Workspace ONE UEM and specify all of it. You “could” just use the AirWatch self-signed certificates, but it is recommended to use a 3rd party certificate for SSL and internal CA certificates for user authentication.

The big key is to avoid COMODO as Android doesn’t trust all of their intermediate certificates anymore, which can be problematic. I think the goal is to be cautious and ensure you handle things appropriately.

Another best practice that I would recommend is deploying a single certificate for WiFi and Android SSO to efficiently manage your certificate footprint on devices.

Workspace ONE Tunnel Configuration

You will need to configure your Tunnel settings in Workspace ONE UEM even though you don’t need to deploy Tunnel itself. Remember, it’s a taco!

First, you set the hostname to a dummy value like this below:

Next, specify the public certificate you bought:

Third, you specify the internal CA information I mentioned earlier. Let’s cover the requirements real quick for the template (there’s a few different ways to do this, but I find this to be the most organic):

After you finish that, just accept the rest of the default and save your configuration. Now, we are onto the network rules!

Workspace ONE Tunnel Network Rules

Now, we setup the Per-App VPN rules to ensure the right apps can use Android SSO. First we setup the tunneling rules. Don’t forget that you have to setup a rule per application you want to enable for SSO:

The Web Proxy URL for SaaS VIDM is: certproxy.vmwareidentity.com:5262

Second, you add in the bypass to make sure it works as expected:

Per App VPN Setup in UEM Console

You will want to go into your profiles and create a VPN profile next. It will default to the VMWare Tunnel and you just deploy it out. Literally, couldn’t be any easier!

The next part is super easy too. You just go into the assignment for each application and setup VPN tunneling for the Tunnel App with the profile you just created:

VIDM Android SSO Endpoint

Now you’re finally ready to turn it all on! You can go into VIDM –> Identity & Access Management –> Authentication Methods and edit the Android Mobile SSO authentication method.

You just enable it, upload the root/intermediate certificates, and most importantly select the user identifier search order to use upn | subject, which I have found works the best and allows you to use a single certificate for all certificate functions (WiFi/VPN/SSO).

There are additional things you can configure for your OCSP/CRL integrations, but that is entirely up to you.

One frequently overlooked item, is the authentication failure message, which I strongly recommend seeing. Remember, this is all about the user experience!

Once completed, you can enable Android Mobile SSO in your Built-in Identity Provider:

The final part will be incorporating Android SSO into your policy. The biggest mistake that people make here is forgetting to rank their mobile SSO policies above their standard web browser policy. I typically put iOS SSO first, Android SSO first, etc:

In Closing

Hopefully this has been helpful for some of you! What I have learned is that the documentation is not super clear and sometimes people struggle a bit with understanding how some of it is achieved. As I always say, by working together we can achieve great things!

Now it’s time for you to implement this for your Android devices and see how amazing it is.  In my opinion, there is no better experience for delivering Android SSO than this. Certificate-based authentication is by far my favorite way to authenticate. It doesn’t care about the platform or anything else. It just works!