Everyone likes the idea of Device Compliance checks. It allows us to differentiate between Company-issues, BYOD-enrolled, private and totally foreign devices, assess their security posture and execute access decisions based on this vital data, expanding our Conditional Access options. It is also extremely easy to use, just like that (VIDM Admin Console):
Right?
Wrong! Try it yourself and see if it works. In this post we will discuss some of the less obvious, but perfectly logical restrictions that Device Compliance imposes on your selection of authentication methods.
What’s wrong?
At the first sight the device compliance check seems to be working. Try it from a non-compliant device and you see this:
This seems to be just what we need. But wait – try this from a compliant device …and you will see the same!
Why is that happening?
Well, if you are to assess the device compliance, you need to know which device it is, right? How are you going to learn that when a device comes via browser in Incognito mode, for example?
One could argue that we could use fingerprinting techniques, cookies, MAC/IP address and other tools, which are proven to be not 100% reliable and often interfering with privacy regulations in many countries. Additionally, we need to ensure that the device ID cannot be forged, spoofed or otherwise altered (we’re talking Security after all, aren’t we?)
This limits us to methods, where we are in 100% control of the authentication credentials that will be passed to vIDM. The only way to be in 100% control is to issue the authentication token ourselves. We could use a dedicated authenticator app for that, but this is inconvenient. What better way is there?
What should I do?
The answer is simple: use a certificate and the derivative certificate-based authentication methods, such as Mobile SSO.
When WorkspaceONE UEM (AirWatch) issues a certificate via a corresponding Profile payload (Credentials or SSO), it adds the UDID (Unique Device ID) parameter into the cert, making it extremely easy for VIDM to look up that device in the UEM and query compliance. We can also be sure that this cert is not altered, spoofed or transferred to another device, assuring the authenticity of the “user+device” combination.
So, which methods work with compliance. According to the current docs they are:
- Certificate
- Mobile SSO for Android
- Mobile SSO for iOS
This doesn’t seem like much, but it enables both greater convenience and greater security over the traditional passwords, and if it’s not enough for you, you can supplement it with 2FA using VMware Verify or any external 2FA method. (By the way, 2FA-based methods also have own requirements, such as user ID, which is why using 2FA w/o a primary method to identify user will not work). So why go for worse methods, when you have better? 🙂
Summary
- Device compliance requires device ID
- Device ID can be reliably/securely transmitted only with certificate-based authentication methods: Certificate and Mobile SSO (Android/iOS)
- Any of these methods offer better security and user convenience than traditional password methods. UEM takes care of most cert-based work, you can use external CA or the one already present in AirWatch.
- Yes, it would be nicer if the VIDM UI was a bit user-friendlier and warned about the combinations that do not work 🙂
Reading list: SSO for Android, iOS and Desktops (generic Cert) (looks scarier than the actual implementation).
What are your thoughts? Are you using certificate-based auth yourself? (I have moved most of my environments to Cert-based SSO just because it’s so much faster and I don’t need to remember passwords anymore 🙂 ) Let me know your thoughts!
Arsen Bandurian: Technical Blog 