The blog post contains the business view (the ‘Why?’), how it works technology-wise, application type dependent flavours, what app developers need to do, how is the user experience and how to configure it in VMware Workspace ONE UEM endpoint management solution.
Introduction – Business requirement
Employees want to have simple access to applications on mobile devices like iOS and Android. Corporate IT want to make this happen but also need to secure the access to those corporate applications. Using traditional app authentication and authorization methods like Kerberos is a commodity for the last two decades.
Companies now have to add or shift towards new modern methods wether they like it or not. This is enforced by must-have applications (Office 365, Salesforce, ServiceNow, …) that are typically in the cloud and use modern AuthN/AuthZ processes like OpenID Connect/SAML/oAuth. Once these new must-have SaaS applications are established in daily operations, many companies promote these new modern standards to be used for existing or new on-premises (self-developed) applications.
The new modern authentication options allow to adopt new modern security approaches which are often referenced to Zero-Trust strategies. Once adopted companies usually start to get rid of Kerberos-based applications for the following reasons: A) Architectural security problems that cannot be fixed (simply google ‘golden ticket’) and B) it requires access to AD domain controller and corporate network connectivity thus it is not Internet capable by design.
In today’s Zero-Trust strategies checking constantly the risk and compliance state of a user or device is an important pillar. Modern Identity & Access solutions allow you to cross check various security signals and define granular access policies for each application the user wants to access. Amongst many security signals, most companies using Microsoft Azure AD Conditional Access engine require to check the device compliance state when an end-user accesses a corporate application. This device compliant state is or usually becomes one of the key requirements as part of a Zero-Trust strategy at most companies.
Checking the user’s device compliant state using Microsoft Conditional Access on a Windows desktop that is managed by a Non-Microsoft Endpoint Management tool is available for a couple of years. Doing the same for native iOS and Android apps is relatively new and can be a challenge. If you use native iOS + Android applications that implemented the Microsoft Authentication Library (MSAL) like Office 365 apps then the effort for IT is moderate. But if you have Non-MSAL iOS and Android apps like Salesforce or use the native Safari or Chrome browser for app logins, then this becomes more complex.
So the goal of this blog post is to show you on IT admin level:
- What are the requirements to enable iOS + Android apps for Azure AD Conditional Access device compliance checks during a user’s authentication process
- Within the application itself
- On the OS level
- On the device management level for MDM-managed devices
- How to configure this with VMware Workspace ONE UEM
- How to optimize the user experience as best as possible
Index & Version Info
### Index
# iOS + Android apps contain Microsoft Authentication Library (MSAL)
# Non-MSAL Apps - Overview
# Non-MSAL Apps - Check server or SaaS portal configuration
# Non-MSAL Apps - WS1 UEM config for iOS
# Non-MSAL Apps - WS1 UEM config for Android
# What if device compliance cannot be used?
# Dos and Don'ts
# Helpful URLs
### Version Info
# none yet
### About the Author
# Author Oliver Kluenter - Vita URL here - Contact me to discuss on LinkedIn here
# Credits to Chris Brumm for cross checking - LinkedIn here Scenario + Requirements
### Scenario
- Azure AD as primary IDP + Conditional Access
- VMware Workspace ONE UEM (AirWatch) MDM-managed devices
- Office 365 iOS + Android apps with MSAL to AuthN against Azure AD
- Salesforce iOS + Android apps withOUT MSAL to AuthN against Azure AD
### Requirements
# Device is already MDM-managed
# Device is already Azure AD registered and linked to WS1 UEM
- See my blog post Azure AD Conditional Access with 3rd-party MDM solutions
# Microsoft Conditional Access policies
# Microsoft Authenticator for iOS + Android
- VMware WS1 UEM: is already deployed + pre-configured when devices get AAD registerediOS + Android apps contain Microsoft Authentication Library (MSAL)
How does this work?
If your native iOS or Android application integrated the MSAL library properly (e.g. most of Office 365 apps or Microsoft Edge browser) then everything is ready to go. When the user/app wants to authenticate against the Azure AD, the ‘MSAL capable app’ reaches out to the ‘Microsoft Anchor/Broker App’ (here Microsoft Authenticator) to get a required token. Amongst other stuff that token includes the Azure AD device id of the user’s device in a secured way. Once received, that trusted device info will now be passed from the app to Azure AD and can be used for device compliance checks during a Conditional Access process.
What is the user + admin experience?
The user experience is good and no extra manual steps needs to be done by the end user. The user may have to enter his Azure AD login name/UPN depending on the SSO capabilities you implemented – but SSO is a different topics not covered by this blog post. The following 4 ish minutes video shows the following use cases and processes for Microsoft OneDrive as an MSAL app:
- User login on compliant iOS device
- Make Android device non-compliant
- User login on NON-compliant device >>> Prove that CA policy takes effect
- Shows the relevant AAD User Sign-in logs
- Make Android device compliant
- User login on compliant device
While the video contains the AAD user sign-in logs for a NON-compliant device getting blocked from OneDrive, please see below the screenshots for a successful sign-in:
How many apps do support this method?
Beside Office 365 apps, the Microsoft Edge browser supports MSAL. I’m not aware about a list of Non-Microsoft iOS and Android applications that have the MSAL integrated. I was told that any application that interacts with “Office 365” apps should have implemented MSAL to make integration and user authentication easy. As an example I was referred to Kypass which is a Password Management tool that has an integration with OneDrive and is used at some companies.
Within Microsoft MEM / Intune you can easily look a lot ot third party apps supporting the ‘Intune App Protection SDK’ – but that’s a different use case for a different security level.
What do I need to tell the developer to use this method?
### What do I need to tell the developer to use this method?
# Overview of the Microsoft Authentication Library (MSAL)
https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview
# Migrate applications to MSAL for iOS and macOS
https://docs.microsoft.com/en-us/azure/active-directory/develop/migrate-objc-adal-msalIf you develop an application with tight Office 365 or Azure AD integration, then it’s a good thing to use the Microsoft Authentication Library (MSAL). It simplifies a lot any Azure AD authentication interaction including the device compliance check process. This approach provides a good user experience and a high user adoption success rate with low efforts for a company roll-out.
In the past app developers often used the AD Authentication Library (ADAL). Microsoft recommends to migrate to MSAL. In regards to “who can sign-in”, these are the differences between ADAL and MSAL capabilities:
- ADAL only supports work and school accounts – also known as Azure AD accounts.
- MSAL supports personal Microsoft accounts (MSA accounts) such as Hotmail.com and others
- MSAL supports work and school accounts, and Azure AD B2C accounts.
What do I need to do as an Endpoint Management admin?
This is the nice part about applications using the MSAL: Nothing special related to the authentication process running including the device compliance check. So this is easier compared to NON-MSAL applications described in the next blog chapter.
Non-MSAL Apps – Overview
How does this work?
First of all: It works! In the end it’s a different method for an iOS and Android app to get the required token that includes the Azure AD device ID in order to execute against the Azure AAD authentication process.
### Important: All the additional steps and efforts described below are independent of the Endpoint Management solution that you use.
### If you are impatient :) You will find all required VMware Workspace ONE UEM device management configuration details further below. Jump for iOS here. Jump for Android here. Keep in mind that you may need to adjust application settings on the server side or SaaS portal as well.To make this work for an iOS and Android app it’s a combination of a few puzzle pieces that I tested successfully with the native Salesforce app, but it’s the same for any other Non-MSAL app:
- On the server side / In the SaaS portal: You may need to adjust a setting for iOS + Android authentication
- The native app: Uses the iOS Safari or Android Chrome Browser for authentication process
- iOS: In Workspace ONE UEM you need to configure “broker settings” so that the Safari browser knows how to interact with Microsoft Authenticator to get the token with the included trusted device ID
- Android: The user needs to add a Microsoft Authenticator certificate in a manual 2-steps process to build the trust between Chrome Browser and Azure AD / Microsoft Login.
The same principles apply if a user uses Safari or Chrome browser to access a web portal that supports modern authentication and requires to prove their device compliance.
Browser features required for Non-MSAL apps:
- iOS: The native app must use the SafariViewController component.
- Android: The native app needs to support Chrome Custom Tabs feature.
How the browsers know how to talk with Microsoft Authenticator app:
- iOS: The Endpoint Management admin creates a SSO extension profile so that Safari communicates with the Microsoft Authenticator during authentication process. The Microsoft Authenticator itself has an integrated Apple SSO extension that communicates with the Safari browser.
- Android: A certificate issued by Microsoft Authenticator app has to be added manually by the end-user one-time on their device. At the end of the process the user-based certificate is placed in the Android OS certificate store. As a matter of interest this certificate might be used for authentication processes for VPN connections .
What is the first time User Experience on iOS?
On iOS this is a pretty good user experience. The user opens the app first time and it works. So your adaption / success rate will be high. The user is happy, the Service Desk is happy, the App or Product Owner is happy.
In the video we configured Salesforce in a way that a corporate login button (‘Zaq Global Inc’) can be selected by the user. The username/password section was not yet disabled in the Salesforce admin portal to improve user experience. Depending on the application options, the user may have to enter his Azure AD login name/UPN. Additionally you can utilize the SSO capabilities of your primary IDP (in this case Azure AD) to provide the best user experience – but Azure AD SSO is a different topic not covered by this blog post.
Find below the Azure AD User sign-in logs. Here you see that Salesforce is the application detected, but that the iOS Safari browser is the ‘client app’ that processing the authentication (see also the ‘User agent’ listed). Screenshot 3 show that the device compliance was checked by the CA policy.
Finally you test if the Conditional Access device compliance is working. For example you enforce the device to get non-compliant by installing a blacklisted application.
What is the first time User Experience on Android?
This needs to become more user friendly to increase the adoption success rate during the project roll-out. With the current approach the end-user itself needs to do a two manual steps on the device:
- Within Microsoft Authenticator > user triggers “Enable Browser Access” > no automatic guidance
- Manually confirms the certificate in browser during first time authentication process > easy step
Once done, all Azure AD authentication processes for all Non-MSAL apps using the Chrome browser should work immediately without user interruption – see video 2m:07s on-wards. The ‘non-compliant device user experience’ is similar to iOS video above.
Android work-around: Use Microsoft Edge browser as an alternative?
You might think about the Microsoft Edge browser instead of the Chrome browser to achieve a good user experience. The reason is that Microsoft Edge browser already includes the Microsoft Authentication Library (MSAL). The drawback is that you must uninstall Chrome Browser from the device – disabling is not sufficient from what I have being told. You might also have unwanted side-effect – e.g. Android PlayStore Webclips only work with Chrome browser on the device. I’m currently investigating on both approaches how this can be achieved with VMware Workspace ONE but for the time being it is as it is.
Non-MSAL Apps – Check server or SaaS portal configuration
# Salesforce - Customize Your My Domain Login Page for Mobile Auth Methods
https://help.salesforce.com/articleView?id=domain_name_login_mobile_auth_methods.htm&type=5The assumption is that any native iOS and Android app that is using the native iOS Safari or Android Chrome browser can use the ‘Non-MSAL’ method. You need to check with the application provider if the iOS and Android app is using the iOS SafariViewController or Android Chrome Custom Tab for authentication by default. Otherwise you have to configure something special on the server side or in the web portal.
In case of Salesforce you must do a change in the admin portal that is described in Customize Your My Domain Login Page for Mobile Auth Methods . In a nutshell:
- Go to Setup/Settings > in the Quick Find box, enter and select MY DOMAIN
- Under Authentication Configuration, click Edit.
- Select “Use the native browser for user authentication” on iOS and Android
Non-MSAL Apps – WS1 UEM config for iOS
Step 1: Salesforce app pre-configuration [recommended]
If you want to make the user experience as best as possible, you want to pre-configure the Salesforce target domain name using the iOS app configuration feature. By doing this you avoid the user has to manually enter the Salesforce ‘custom domain URL’ name. This applies if you don’t have yet fully automated the authentication process yet, e.g. by Single Sign-On (SSO). Add an app config settings with configuration key = “AppServiceHosts”, value type = “String” and configuration value = your Salesforce target URL.
Step 2: Configure iOS SSO extension payload
This requires iOS 13+ on the devices. The iOS SSO extension payload contains a list of Microsoft URLs that are typically called for an authentication process. You may not need the full list of URLs mentioned in https://docs.microsoft.com/en-us/azure/active-directory/develop/apple-sso-plugin#enable-the-sso-plug-in-with-mobile-device-management-mdm . Please find below the list from 2021-01 for easy copy/paste:
SSO Extension Type: Generic
SSO Type: Redirect
Extension ID: com.microsoft.azureauthenticator.ssoextension
Team ID: (this field is not needed for iOS)
URLs:
https://login.microsoftonline.com
https://login.microsoft.com
https://sts.windows.net
https://login.partner.microsoftonline.cn
https://login.chinacloudapi.cn
https://login.microsoftonline.de
https://login.microsoftonline.us
https://login.usgovcloudapi.net
https://login-us.microsoftonline.com
Non-MSAL Apps – WS1 UEM config for Android
Step 1: Salesforce app pre-configuration [recommended]
The same as for iOS: If you want to make the user experience as best as possible, you want to pre-configure the Salesforce target domain name using the iOS app configuration feature. By doing this you avoid the user has to manually enter the Salesforce ‘custom domain URL’ name. This applies if you don’t have yet fully automated the authentication process yet, e.g. by Single Sign-On (SSO). Add an app config settings with configuration key = “AppServiceHosts”, value type = “String” and configuration value = your Salesforce target URL.
Step 2: Not required by Administrator but …
… the user has to take the burden to execute a two manual steps process – see here.
What if device compliance cannot be used for an app?
If your iOS or Android app does not support the above (Non-)MSAL approaches, then you have a couple of options to check for security signals in a Conditional Access policy during user sign-in. Conditional Access allows you to apply different policies for each application. Amongst others you may decide to use:
- Named location (trusted IP address approach) for devices using VPN or corporate Wi-Fi
- Use Multi-Factor Authentication (MFA) during app authentication process
- Other Conditional Access signals like user risk, sign-in risk, …
- Don’t allow this app to be used anymore ; Substitute with an alternative app
If you already use Microsoft Cloud App Security or an alternative CASB solution, you have a different solution approaches that you can apply on that level to secure access to an application.
Dos and Don’ts
Currently none.
Helpful URLs
### Helpful URLs
# Azure AD Conditional Access with 3rd-party MDM solutions
https://bit.ly/39PpHxp
# Overview of the Microsoft Authentication Library (MSAL)
https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview
# Migrate applications to MSAL for iOS and macOS
https://docs.microsoft.com/en-us/azure/active-directory/develop/migrate-objc-adal-msal
# Salesforce - Customize Your My Domain Login Page for Mobile Auth Methods
https://help.salesforce.com/articleView?id=domain_name_login_mobile_auth_methods.htm&type=5
# Microsoft Enterprise SSO plug-in for Apple devices
https://docs.microsoft.com/en-us/azure/active-directory/develop/apple-sso-plugin#enable-the-sso-plug-in-with-mobile-device-management-mdm