SSO and authentication behavior changes for AirWatch iOS and Android apps

Overview

The latest (and in some cases upcoming) versions of iOS and Android AirWatch apps include behavior changes if Authentication and SSO are enabled in the SDK settings.  This article outlines the expected behavior changes in-depth.

Contents

 

Affected Configurations for iOS

  • The following changes affect AirWatch SDK applications in environments that have App Security policies configured such that Authentication Type is set to "Passcode" or "Username and Password" and Single Sign On is set to "Enabled."  App Security Policies are configured in the AirWatch Console under Settings > Apps > Settings And Policies > Security Policies.
  • For iOS devices, no further AirWatch Console configuration is required.  The following behavior applies to all environments leveraging the above settings.

Affected iOS Apps

Review a list of the affected apps and the versions containing the new behavior change.

AirWatch Apps Version
VMware AirWatch Agent 5.4+
VMware AirWatch Container 2.4+
VMware AirWatch Browser 5.12+
VMware AirWatch Content Locker 3.12+
VMware AirWatch Inbox 2.12+
VMware AirWatch Video 1.12+
Applications using AirWatch SDK 5.9.3+

Key Behavior Changes for iOS

General

  • If an AirWatch app is terminated, the passcode or authentication session for that app expires and the user must re-enter the app passcode or TouchID regardless of an existing SSO session or a valid session in another SSO app. Apps in this state will not respond to Background App Refresh.  The app can be terminated by a crash, an end-user swiping up in the app-switcher screen, or by the operating system due to memory pressure if the app is not currently active in the foreground.
  • If the authentication timeout occurs while you are actively using an app within the SSO session, an authentication prompt will not immediately appear.  The prompt will appear the next time an app within the SSO session is launched/activated.
  • If your app uses single sign-on (SSO) with the authentication mode enabled in the SDK profile, newer apps mentioned in the affected apps table will not share a passcode session with older apps. Older apps continue to share sessions with other older apps.

Content Locker

Users will experience behavior changes when using Content Locker through extensions based on the Authentication Type

  • If authentication is enabled, Content Locker files that allow "Open In" can be accessed through extensions by 3rd party apps that simply import a file (apps that access the file through Import mode or ExportToService mode), this includes email clients or apps with read only capabilities. Apps with edit capabilities (apps that access the file through Open mode or MoveToService mode) like Word will be restricted through extensions.
  • If authentication is disabled, there are no behavioral changes around Content Locker Document Extension functionality. Content Locker can be accessed through extensions by 3rd party apps to import as well as Edit and Save back. This includes Microsoft apps, email clients and other productivity apps.

Miscellaneous / Known Issues

  • TouchID in older versions of the application will no longer authenticate a user if the user upgrades to the new versions in the table above and changes the passcode after the upgrade.
  • Updating the passcode complexity requirement in the SDK profile will not prompt the user to create a new passcode (with the new requirements) until they authenticate into the app using the passcode. TouchID entry will not trigger the passcode creation. This issue will be resolved in a future version.

 

Recommended Configuration for iOS

  • If you use authentication in your apps, enable TouchID in your SDK profile, and encourage end-users to add a fingerprint to the device.
  • If possible, enable single sign on to allow AirWatch apps to share a passcode in order to provide an improved user experience.
  • If you enable TouchID, ensure devices are on iOS 9 or higher to take advantage of additional security improvements provided by the OS.
  • For the most optimal user experience, it is highly recommended to have end-users update all applications to the versions mentioned in the matrix above and avoid using a mixture of older and newer versions of the apps.

 

Affected Configurations for Android

  • The following changes affect AirWatch SDK applications in environments that have App Security policies configured such that Authentication Type is set to "Passcode" or "Username and Password" and Single Sign On is set to "Enabled."  App Security Policies are configured in the AirWatch Console under Settings > Apps > Settings And Policies > Security Policies.
  • For Android devices enrolled through the Android Agent, these changes require AirWatch Console 9.0.1 and must be enabled by a customer.  This setting is available in Settings > Devices & Users > Android > Security.

 

Affected Android Apps

Review a list of the affected apps and the versions with the behavior changes.

AirWatch Apps Version
VMware Workspace ONE 2.2+
VMware AirWatch Agent 7.0+ 
VMware AirWatch Container 3.3+
VMware AirWatch Browser 5.12+
VMware AirWatch Content Locker 2.12+
VMware AirWatch Inbox 2.12+
VMware AirWatch Video 1.12+
Applications using AirWatch SDK 16.10+

Depending on management configurations, these changes can impact important background operations of the Android Agent. For example, updates to compliance policies or configuration profiles will be delayed until the user enters the app passcode to the Agent after a device reboot. See the "Key Behavior Changes" section below for more information.

Additionally, apps wrapped through App Wrapping Engine 5.3+ will experience the behavior changes outlined below.

Note: The VMware Boxer app has supported this authentication process since it first integrated with AirWatch (v3.9).  Boxer currently does not support SSO with other AirWatch applications and will not support SSO with these versions of the applications.  Additionally, Boxer is unaffected by the AirWatch Console configuration in AirWatch 9.0.1 (see Affected Configurations above).  However, a future version of Boxer will support SSO with the rest of the AirWatch app suite.

 

Key Behavior Changes for Android

Enabled Single Sign-On (SSO)

  • If all AirWatch apps participating in SSO are “force stopped”, then the background sync of the app is limited until the user enters the app passcode.
  • Older versions of the app prior to the versions mentioned in the affected apps table will not share a passcode session with the newer versions until admins update the Android Agent to 7.0 or above.
  • If passcode is enabled as the authentication mode upon upgrade and launch of the app, the user will be required to enter the previous app passcode and to create a new passcode. Passcode age and history counters will reset in the new version. Subsequent upgrades of other apps participating in SSO will not need to create another passcode.
  • If the device is rebooted, then the background sync of the app is limited until the user enters the app passcode in one of the SSO-enabled apps.

Disabled Single Sign-On (SSO)

  • If an AirWatch app is “force stopped”, then the background sync of that app is limited until the user enters the app passcode in the app that was force stopped.
  • If the device is rebooted, then the background sync of the app is limited until the user enters the app passcode.
  • If passcode is enabled as the authentication mode upon upgrade and launch of the app, the user will be required to enter the previous app passcode and to create a new passcode. Passcode age and history counters will reset in the new version.

Android Content Locker

  • Lock replaces the Logout feature. End users can lock their app when needed and use the authentication type enabled in the SDK profile (passcode or username / password) to log in again.
  • Users cannot set an app passcode if admins have not enabled authentication type as "passcode" in the SDK profile.
  • Users will need to clear app data if they want to change the user on Content Locker when in standalone-enrollment mode.
  • After an upgrade on standalone-enrollment mode, users will need to authenticate with their credentials to use the app.
  • Content Locker will deprecate the ability to view the app terms of use in the settings page. Users see the app terms of use when they login to the app for the first time.
  • Content Locker will not support custom branding images.

Android Inbox

  • AirWatch Inbox 2.12 leverages the device HMAC token for authentication.  If SSO is disabled for this application, the user will be prompted for their AirWatch credentials (note: these credentials may be different than a user's email credentials) one time when first launching the app.  After a successful authencation, the Inbox app will receive the HMAC token and the user should not be prompted for Authentication any further unless the SDK settings specifically permit it.  If SSO is enabled, users will receive no prompt on upgrade.
  • If Inbox was previously using an Inbox passcode as part of the email profile and the passcode is enabled in the SDK profile, then this Inbox passcode will be replaced by the SDK configurations upon upgrade of the app.
  • If Inbox was previously using an Inbox passcode as part of the email profile and the authentication type is "disabled" in the SDK profile, then this Inbox passcode will continue to be used.

Miscellaneous / Known Issues

  • Manually locking the application in one of the new versions mentioned in the table above will not lock the session in older applications.
  • If enrolled with a Container version below v3.3, reaching the maximum number of failed attempts for authentication (passcode or username / password) in another app will not trigger an enterprise wipe.
  • Passcode creation in Android AirWatch applications will now always require internet connectivity.

 

Recommended Configuration for Android

  • If your company’s security policies allow, enable single sign-on in the SDK profile. This configuration reduces the amount of redundant passcode prompts where possible.
  • Inform your end users about the new limitations with background syncs, and encourage them to enter their passcode in their apps at least once after reboot.
  • If you are using single sign-on in your SDK profile, ensure that the Agent and other apps are updated to the versions mentioned in the affected apps table.
  • For the most optimal user experience, it is highly recommended to have end-users update all applications to the versions mentioned in the matrix above and avoid using a mixture of older and newer versions of the apps once all apps are available.
Have more questions? Submit a request

0 Comments

Article is closed for comments.