Have you ever thought it'd be extremely useful to know if a user is using a device or application managed by Enterprise Mobility Management (EMM) when requesting access to an enterprise resource? Well, you're in luck.
We've been in discussions with leading EMM providers on how to differentiate between applications and devices that are managed by an EMM and those that aren't. This obviously impacts policy for the authentication and authorization of the user. Knowing that something is managed by an EMM (and is compliant with the enterprise's policies for device security) can provide valuable input into the enterprise's decisions as to which mechanisms are used to authenticate the user and what they're allowed to do once in the application.
For Ping to query an EMM for the posture of a particular device (allowing authentication and authorization policy to be changed appropriately), we need some way to identify that device. This presumes that:
The device has an identifier that the EMM will recognize when presented on the query.
The identifier can be first presented from the device to a Ping component so that it can be used on the posture query to the EMM.
For identifying a device, an X.509 certificate is the primary authentication mechanism we've been discussing with EMM providers. This is a certificate that was previously provisioned down to the device by the EMM.
Because the cert has been provisioned by the EMM, it will be able to recognize it (or some GUID within it) and will be able to look up the posture of the corresponding device. This meets the first requirement listed above.
For the second requirement, the cert must be used during an authentication to a Ping server (i.e., in a client-authn SSL authentication). This demands that the cert is available to the browser window where the user authenticates to the enterprise.
The fact that an EMM-provisioned cert must be indirectly available to the native app to indicate that it's managed (i.e., available to the browser that a native app uses for authentication) has important consequences.
On Android, any cert provisioned into the managed profile will only be accessible to managed apps. As a result, the cert being presented to PingFederate during authentication is a reliable indicator that the initiating app is managed by that EMM (once that cert is validated as having been issued by the EMM).
On iOS, however, there's only a single store of provisioned certificates--both EMM-managed apps and others can indirectly access those certs. As a result, the cert being presented to PingFederate during authentication is NOT a reliable indicator that the initiating app is managed by that EMM. It does indicate that the device is managed, but not necessarily any particular app (not all apps on a managed device will necessarily be managed).
Knowing that a particular app is installed on a managed device provides less assurance than knowing that the app itself is managed (i.e., provisioned by the EMM). Consequently, on iOS, using a cert as the device identifier doesn't specify enough. To further determine posture, there could be value in basing a 'managed or unmanaged' decision on some other identifier that would provide the desired level of granularity on both Android and iOS.
Ping and Google have discussed the potential for leveraging the Proof Key for Code Exchange (PKCE) and AppConfig mechanisms together to meet the requirement. A PKCE verifier could be provisioned to specific applications via AppConfig, which makes it only available to actively managed apps.
PKCE mitigates attacks that public native OAuth clients are vulnerable to. Such clients don't use secrets when authenticating to their OAuth Authorization Server (AS) because they're typically distributed through public app stores. So, if a malicious app on the device is able to grab the OAuth authorization code, it would be able to trade the code for the more fundamental OAuth tokens, and then access business or private data. The PKCE mechanism effectively allows such native clients to generate for themselves a one-time secret and use that when interacting with the AS, which prevents the attack.
The AppConfig effort normalizes a set of best practices by which EMMs can provision configuration information down to the native managed applications on a particular device. The AppConfig model leverages the increasing device and app management capabilities of the mobile OS as an alternative to those EMM mechanisms that require the apps to be wrapped or use proprietary SDKs.
Let's take a look at a high-level sequence for using PKCE and AppConfig to determine whether a particular native application is under EMM management at the time the user signs on to it:
The EMM provisions a PKCE code_verifier to the application via AppConfig.
At sign-on, the app hashes the code and sends it as a PKCE code_challenge to the enterprise OAuth AS.
The enterprise AS uses the code_challenge to query an EMM device posture API and asks if the app under management.
The EMM looks up the code_challenge to determine if the app is under management.
The EMM confirms back to enterprise that the initiating app is under management.
If all's good, the enterprise AS returns an OAuth authorization code to the app (to the configured claimed URI). If all's not good, the enterprise can either deny the request or take steps to mitigate.
The app presents the code and the code_verifier to the enterprise AS token endpoint.
The enterprise AS returns OAuth tokens to the app.
The app uses the access token on API calls.
Whenever the app uses its refresh token to get new access tokens, the AS can check the current device posture with the EMM.
This ensures that the enterprise delivers OAuth tokens only to:
Valid apps (because the code is sent to the previously configured custom scheme URI).
The same application that initiated the authentication flow.
Managed apps (because of the code_verifier check against the EMM).
It's important to note that the above model would give the same assurances on both iOS and Android devices, which is unlike the current reality for certificate-based checks.
For native applications running on devices, the enterprise has two fundamental security questions. Each of these answers could impact authentication and authorization policy:
Is the app known/valid/authentic/compromised?
Is there an MITM?
Is the device known/valid/authentic/compromised?
Is it jailbroken?
Is there malware?
To help us answer these two questions, we have a variety of security mechanisms available. This post focused on using PKCE and AppConfig, but there are other 'arrows in the quiver' as they say. Check out Proof of Possession Tokens, Token Binding and Attestation models like Android's SafetyNet. We'll explore how those fit into the mold in future posts.