Adding FIDO2 + Windows Hello fingerprint auth to Workspace ONE

This will be a short “recipe” type of post on how to showcase a new feature that was introduced in latest Workspace ONE Access SaaS release (sorry, no news for on prem now): FIDO2 auth. The video shows Yubikey, which I don’t have, so I will be using Windows Hello (which in turn will use my fingerprint reader). Similar setup would work with TouchID on macOS. Let’s Go!

What is FIDO2?

I will not write anything about it here – there’s been TONS of blogs and videos about it. But basically it’s a new flashy and a more secure way of logging in w/o having to transmit usernames or password, establish SAML trusts or investing into PKI.

What is important for us is this intro video and a chart on VMWare Docs, that shows what is currently supported (since every browser is a little different). I have played with Chrome, Firefox and Egde in Incognito and “normal” modes, and always have seen different results. For example Chrome on my Win10 2004 only offers Fingerprint auth in proper, (non-incognito) mode, and Firefox does not offer it at all.

Setting it up in Workspace ONE Access – the plan.

Enough talking, let’s set it up so that we can have a simple demo scenario w/o any extra hardware. We need to go through three steps:

1. Enable and configure the FIDO2 authentication methodin WS1 Access
2. Create a rule that allows FIDO2 authenticator registration in Default Access Policy
3. Create a rule that leverages FIDO2 auth (in a default or app-specific access policy)
4. PROFIT

That’s it. We will also look at how you can see/manage the enrolled FIDO2 authenticators for the user. Let’s go!

1. Enable and configure the FIDO2 authentication method in WS1 Access

Please note that currently FIDO2 is available only in SaaS (cloud) tenants. Enable it just as any other auth method. For Windows Hello or TouchID to function, the Attestation Conveyance Preference parameter must be set to none! This is also mentioned in the docs, but in context of TouchID only. Here is a screenshot of my setup:

The next step would be to ensure the adapter is enabled in the Identity Providers section for the correct user directories. In my case I have a default Built-In identity provider that has everything enabled for all possible directories 🙂

Now the new FIDO2 authentication method will be available for use in access policies.

2. Create a rule that allows FIDO2 authenticator registration in Default Access Policy

Before someone can authenticate with FIDO2, they need to be able to register an authenticator (similarly to how you first need to enroll your MFA device/token before using MFA). For this, you need to have some other auth method, right? In order to facilitate this, WS1 Access offers a new toggle only available in Default Access Policy (!)

Aside from switching this Token, on there is nothing special. Here’s how it looks in my setup.

You can add this rule anywhere in your default access policy, since if will only be triggered during FIDO2 registration and no other rules will apply anyway. With the registration rule in place, we can begin registering authenticators, but instead, let’s finish our setup and add a proper FIDO2 access policy.

3. Create a rule that leverages FIDO2 auth (in a default or app-specific access policy)

For the purposes of the demo I have created a separate access policy called FIDO2 and assigned it to a demo app (BTW, if you are not familiar with https://sptest.iamshowcase.com/ – check it out!)

For demo purposes, assign policy to a subset of applications

The policy has one straightforward rule

Now we are ready to try it out!

Trying it out!

This is what the user sees when accessing the app using a FIDO2 auth method

Upon clicking Register (in my case Windows Hello is configured for Fingerprint, but you may use PIN or USB Key):

After successful registration

Now we can try to sign in!

And that’s it – now we’re logged into the application!

Adding FIDO2 auth to Workspace ONE is easy (at least at the demo level, now security experts will come and put 100500 requirements in – feel free to add comments)!

Managing FIDO2 authenticators in WS1 Access

You can also view and edit the existing authenticators for a user in WS1 Access admin UI. Just go to Users and Groups, choose the user and go to the Two Factor Authentication tab:

Closing thoughts

Adding FIDO2 support to Workspace ONE is pretty straightforward and falls in line with existing practices of managing auth methods, access policies and users. Business as usual. How useful the FIDO2 is – time will tell. So far it’s all the hype, and authenticating with a Fingerprint is always welcome (if you can’t deploy a fully seamless SSO experience that is).

So far, the biggest hurdle I see is non-uniform support across browsers and lack of documentation. The Windows Hello itself seems to be triggered differently depending on the browser and whether the browser is in incognito/private mode. Same applies to various WebAuthn demo sites – some of them work seamlessly, while others throw obscure error messages or refuse to work with fingerprint reader.

I will keep this post updates as FIDO2 develops, as the potential is there.

What do you think of FIDO2? Leave a comment or join the discussion on LinkedIn!