Introduction

The AppConfig community streamlines the adoption and deployment of mobile enterprise apps by providing developers a standard approach to app configuration and management, building upon the extensive app security and configuration frameworks available in Android enterprise. Working together, the members of the AppConfig Community are making it simpler for developers to implement a consistent set of controls so that enterprise IT administrators can easily configure and manage apps from any participating EMM platform.

Android enterprise Capabilities Summary

Capability Capability summary of the AppConfig Community best practices
App Configuration Develop Android enterprise 5.0+ App Restrictions into the application.
App Tunnel / Per-App VPN Leverage the “Per-App VPN” capability available in most commercial VPN solutions. Available in Android enterprise 5.0+. No development required.
Single Sign-On Login Hint Provide a standardized login hint needed to implement tenant discovery for any standard single sign-on protocol, such as OAuth or OpenID Connect, and invoke the identity provider login page for that identity. Also can be used to suggest an account (or domain) login restriction for the app.
App Security – Passcode

Application specific passcodes will require a custom implementation. For app specific passcodes, use app restrictions to enable admin configuration of the passcode settings and requirements.

For Android enterprise devices, supported EMM vendors can enforce a passcode to apply only for Work Profile managed applications. Therefore, it’s recommended to enable the configuration capability to exempt Android enterprise devices from the custom app specific passcode to avoid duplicate passcode prompts.
App Security – Document Sharing Use an Android enterprise 5.0+ managed profile to enforce files to open only in managed applications. Developers should ensure apps are using Content URIs and not File URIs for both functional and security reasons. Use an Android enterprise 5.0+ managed profile to enforce files to open only in applications under the managed profile. Developers should ensure apps are using Content URIs and not File URIs for both functional and security reasons.
App Security – Prevent App Backup Any app deployed under Android enterprise 5.0+ managed profiles will not participate in any backup infrastructure. No development required. Any app deployed under Android enterprise 5.0+ managed profiles will not participate in any backup and restore infrastructure.
App Security – Disable Screen Capture Use an Android enterprise 5.0+ managed profile to prevent screenshots. No development required.
App Security – Enforce App Encryption Enroll your device and the device will be encrypted as part of the enrollment process. No development required.
App Security – Remotely Wipe App Distribute the app to the device as a managed application using the EMM tool to have the ability to remotely wipe the app from the device. No development required.
App Security – Disable Copy-Paste Use an Android enterprise 5.0+ managed profile to containerize copy and pasting to only managed applications. No development required.

App Configuration

Use Case

Many applications require users to enter URL, port, email address, and various configurations as part of a one time setup of an application. These manual configurations can impact the adoption and success of an organization’s mobile app initiatives, increase the burden on a help desk fielding calls from users, and adds the burden of maintaining documentation that needs to be updated frequently as new updates to the application are made available.

By leveraging native APIs, these configurations can be set remotely by the EMM server to simplify the setup process for end users, and alleviate the help desk and documentation burden caused by manual setup. An app developer can define a set of configuration keys it accepts from an EMM server and An IT administrator can simply set the keys and values in the EMM provider’s management console and they will be pushed into the app.

Apps commonly implement the following types of configurations – these are suggestions only:
Backend Service Configuration: server URL, port, use SSL, group/tenant code
User Configuration: username, email, domain (NOTE: for apps that support SSO, login_hint using user@domain format should be used instead of proprietary user configuration settings whenever it’s supportable).

How it Works
Requirements
  • Android enterprise 5.0+ enrolled device
  • App is developed with Android enterprise App Restrictions capabilities using RestrictionsManager
  • Distribute app via an EMM vendor that supports Android enterprise App Restrictions
Process Flow
  • App developer adds App Restrictions capability into the app
  • App developer declares the app restrictions honored by the app in an xml file referenced in the Android Enterprise Manifest xml.
  • App developer makes the app available to the organization. The application can be a public app in the Google Play store, or may be an internally developed app available on a private channel
  • Configurations are specified in the EMM admin console (contact your EMM vendor for documentation)
  • App is distributed to devices, along with the configurations specified, via the EMM
Developer Requirements

Apps installed on enrolled Android enterprise devices running Android 5.0+ can leverage the App Restrictions to retrieve configuration values sent over the air by an EMM vendor. The enterprise app developer will need to implement RestrictionsManager to read and honor these configuration values and invoke the appropriate action based on the configuration.

The following 3 steps outline instructions for a developer to implement this capability:

Step 1:

Add the list of supported app restrictions in a restrictions file and defining the restrictions file in your app manifest.

You can choose to support any custom restrictions you’d like by defining them in a restrictions file and your manifest. Create an XML file named app_restrictions.xml in the res/xml directory to house your defined app restrictions, the format for the XML can be found here: http://developer.android.com/reference/android/content/RestrictionsManager.html

After you create the XML file and have defined your restrictions within the file, declare the restrictions file in your app manifest XML.

<meta-data android:name=“android.content.APP_RESTRICTIONS” android:resource=“@xml/app_restrictions” />

Refer to the documentation link below for the full details: http://developer.android.com/training/enterprise/app-restrictions.html#define_restrictions

Step 2:

Implement RestrictionsManager and use it to read the App Restrictions.

Use RestrictionsManager and call getSystemService with RESTRICTIONS_SERVICE to get the appropriate RestrictionsManager instance. Follow with a getApplicationRestrictions call on the retrieved RestrictionsManager instance to get the app restrictions.

RestrictionsManager myRestrictionsMgr = (RestrictionsManager)getActivity().getSystemService(Context.RESTRICTIONS_SERVICE);
Bundle appRestrictions = myRestrictionsMgr.getApplicationRestrictions();

Note: You can listen to the ACTION_APPLICATION_RESTRICTIONS_CHANGED intent to be alerted when a configuration has changed so you can perform a re-query via RestrictionsManager.

Reference: https://developer.android.com/reference/android/content/RestrictionsManager.html#

Step 3:

Make your app available

Deploy your app on the Play Store or Google Private Channel. An enterprise organization’s admin can configure their EMM to define the configuration values and deploy your app to devices.

Note: Only Android 5.0+ devices can make use of this capability. The application must be provisioned and installed through EMM for the configuration values to take effect.

EMM Setup

Please contact your EMM vendor for documentation specific to their system.

App Tunnel / Per-App VPN

Use Case

An application may require access to web services residing behind a corporate firewall, which requires a secure app tunnel connection between the app on the device and the backend services. A common use case for cloud based public apps is the ability to federate authentication to an organization’s identity provider (IDP) via SAML or similar standard. Since some organizations deploy the SAML identity providers (IDP) on-premise in a way that is not publically accessible, a secure app tunnel is required to authenticate and login to the app.

Mobile operating systems have addressed this use case by enabling a capability commonly referred to as “Per-App VPN”. Several common commercial VPN providers support the Per-App VPN capabilities. Many EMM vendors offer their own Per-App VPN capability as well. Whichever your preferred Per-App VPN vendor is, the EMM provider typically will have the ability to automatically distribute and enable the Per-App VPN on devices.

How it Works

Requirements:

  • Android 5.0+
  • VPN infrastructure deployed that supports the per-app VPN capability
  • No code changes are needed in the app to support this capability

Process Flow:

  1. Organization deploys any needed VPN infrastructure (contact your VPN provider for details)
  2. EMM vendor distributes the VPN app along with a per-App VPN configuration profile
  3. The end user opens an app that requires a backend connection, and the VPN will automatically turn on
Developer Requirements

No code change is needed to your application to take advantage of this capability. The Android operating system will automatically tunnel any network calls based on the configuration profile sent from EMM.

Single Sign-On

Use Case

Organizations want to allow users to log into an application using their existing work credentials, as well as customize the security around the login experience to require various factors of authentication. Once a user has logged into one application successfully, that login process should automatically translate to other applications so users do not have to enter their credentials multiple times.

Many organizations use federated authentication to an identity provider (IdP) to accomplish this. The IdP typically supports standardized protocols (such as OAuth or OpenID Connect) that are implemented by many app developers. The single sign-on capability documented by the AppConfig community specifies the best practice for how an app developer should perform tenant discovery to invoke the IDP from the app in order to facilitate a single sign-on experience.

How it Works

Requirements:

  • Fallback to system browser works on all versions of Android. Best user experience is on Android 4.3+ with Chrome 45+ (when using Chrome Custom Tabs specifically – all Google-certified Android devices since Android 4.0 ship with Chrome)
  • App’s backend SaaS authorization service must support identity federation to an organization’s identity provider (IDP) via a standard such as SAML or OpenID Connect
  • App developer must invoke the identity provider’s login page via a Custom Tab in order to share SSO state across apps
Process Flow:
  1. Customer organization deploys any needed identity provider (IdP) infrastructure
  2. App developers build in support for standard web SSO pattern (using OAuth or OpenID Connect) into their mobile app and the SaaS backend authorization service, using Custom Tabs during user auth flows
  3. (Strongly recommended, but not required) App developer user configuration settings include a specially-named string: “login_hint” that can be set via managed configuration as described above in “App Configuration”
  4. When the app is launched, the user will see the identity provider’s login screen in a Chrome Custom Tab window
  5. If login_hint has been supplied and it resolves to a valid user account on that IdP that is not logged in, that account will be shown by the IdP above the login password request. Depending on your SSO solution implementation, EMM and/or Identity vendor may support automatically authenticating to this page without the user needing to enter his/her credentials manually, contact your EMM vendor or Identity vendor for details
  6. Once the user is authenticated, any additional apps within the Android user or managed profile that leverage the same account and identity provider using a Custom Tab will be able to repeat the pattern without further user intervention and will not need to prompt the user to login again as long as the auth state remains valid
Developer Requirements

The following steps outline instructions for a developer to implement this capability.

Step 1: Support a web SSO pattern with OAuth or equivalent standard protocol within your app’s backend SaaS authorization service

Sample code and documentation for this step in it’s entirety is outside the scope of the AppConfig Community. Contact your identity provider (IdP) of choice for recommendations on how to accomplish this step – some IdP suppliers offer specific solutions for SaaS provider authorization server integration using standardized protocols. Relevant standards documents for OAuth in the Internet Engineering Task Force (IETF) are published at

https://tools.ietf.org/wg/oauth/ and for OpenID Connect in the OpenID Foundation (OIDF) at http://openid.net/wg/connect/

OpenIDConnect

Step 2: Invoke a Custom Tab window to display the IdP authentication page.

IMPORTANT: Always use a custom tab for login, do not render the login screen within your native app UI, which can compromise security and expose SSO credentials; the intended web SSO security pattern with independent IdP flow should be maintained within the custom tab. When a login_hint is not available to your app via managed configuration (which will enable your SaaS authorization server to redirect immediately to the correct IdP), your SaaS authorization server or associated SaaS service should be prepared to render a generic login screen in the custom tab that requests the user to supply the account.

An optional client-side reference library maintained by the OpenID Foundation which implements Chrome Custom Tabs with OAuth and OpenID Connect using IETF and OIDF standards and best practices can be found at https://github.com/openid/AppAuth-Android (the iOS version using Safari View Controller is https://github.com/openid/AppAuth-iOS).

NOTE: although not strictly required when implementing login_hint, the app developer may choose to restrict application login to the account (or domain) that is set via login_hint by default, or set up a separate policy (via managed configuration) to control whether another account (or domain) can be used to log in to the app’s back-end SaaS service when login_hint is specified. Future work by appconfig.org may create standardized conventions in this area for use by developers and EMM providers.

Security Policies

Use Case

An organization requires granular security and data loss protection within enterprise applications to prevent sensitive data and documents from leaking outside company control. An app may also contain a capability that an enterprise wants to disable for security reasons, such as the ability to synchronize data with a public cloud file storage service. Some security capabilities are natively provided by the operating system and the EMM vendor without any code changes needed to the app, other capabilities require the implementation of an app configuration to enable a security capability. A summary of some of the capabilities are listed below, and an app developer can choose to implement a custom security policy as well.

Developer Requirements
App Security – Passcode Application specific passcodes will require a custom implementation. For app specific passcodes, use app restrictions to enable admin configuration of the passcode settings and requirements.

For Android N devices, supported EMM vendors can enforce a passcode to apply only for Work Profile managed applications. Therefore, it’s recommended to enable the configuration capability to exempt Android N devices from the custom app specific passcode to avoid duplicate passcode prompts.
App Security – Document Sharing Use an Android 5.0+ managed profile to enforce files to open only in managed applications. Developers should ensure apps are using Content URIs and not File URIs for both functional and security reasons.
App Security – Prevent App Backup Any app deployed under Android 5.0+ managed profiles will not participate in any backup infrastructure. No development required.
App Security – Disable Screen Capture Use an Android 5.0+ managed profile to prevent screenshots. No development required.
App Security – Enforce App Encryption Enroll your Android 5.0+ device and the device will be encrypted as part of the enrollment process. No development required.
App Security – Remotely Wipe App Distribute the app to the device as a managed application using the EMM tool to have the ability to remotely wipe the app from the device. No development required.
App Security – Disable Copy-Paste Use an Android 5.0+ restrictions profile to containerize copy and pasting to only managed applications. No development required.