app configuration for enterprise ace · 2015-10-02 · saml apple . google google

App Configuration for Enterprise | v.Jan 2015 Copyright © 2015 AirWatch, LLC. All rights reserved. Proprietary & Confidential.

App Configuration for Enterprise (ACE) Standard approach for configuring app level policies and integrating native enterprise apps with EMM solutions. Version 2.6, March 2015

APP CONFIGURATION FOR ENTERPRISE (ACE) 1

INTRODUCTION 2

BACKGROUND 2 CAPABILITIES 2

APP CONFIGURATION 2

USE CASE 2 IMPLEMENTATION: APPLE IOS7+ 2 IMPLEMENTATION: ANDROID 5.0+ (LOLLIPOP) 4

APP TUNNEL 6


SINGLE SIGN ON 9


ACCESS CONTROL 11


SECURITY POLICIES 11


APPENDIX I -‐ 16

SUGGESTED APP CONFIGURATION KEY NAMES 16

APPENDIX II – SAMPLE 10 DAY PROJECT PLAN FOR APP DEVELOPERS 18

App Configuration for Enterprise | v.Mar 2015

Copyright © 2015 AirWatch, LLC. All rights reserved. Proprietary & Confidential. 2

Introduction Background The App Configuration for Enterprise (ACE) initiative defines a standard way for enterprise application developers to interpret app configurations and security policies from EMM (Enterprise Mobility Management) systems, and for EMM systems to configure and secure mobile applications.

With ACE, app developers can build a single application that works across all EMM vendors. The app developer does not need to maintain multiple copies of their application, does not need to integrate any proprietary code, and no SDK or legacy App Wrapping solutions are required. In fact, many of the capabilities specified in ACE, such as “App Tunnel”, Kerberos based “Single Sign On”, and some security settings, do not require any development effort to take advantage of. Some capabilities such as certificate based “Single Sign On”, “App Configuration”, and certain security settings do require minor development effort. This is all accomplished by leveraging standard APIs and capabilities that are built into the operating system platforms, and made available to EMM vendors to selectively enable on devices.

By leveraging ACE, Customers benefit with seamless and secure access to certified business apps, App developers benefit with increased adoption, and EMM vendors can integrate with a much broader ecosystem of mobile applications.

Capabilities ACE defines the following capabilities described in this document:

• App Configuration

• App Tunnel

• Single Sign On

• Access Control

• Security Policies

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.

As part of ACE, 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 organization administrator sets the keys and values in the EMM provider’s management console that will be pushed into the app. Apps commonly implement the following types of configurations:

• Backend service configuration: URL, port, use SSL, group/tenant code

• User configuration: username, email, domain

• Branding configuration: company name, colors, logo images

• Custom configurations: license codes, language setting

Standard configuration keys for enterprise apps are included in Appendix I of this document.

Implementation: Apple iOS7+

Technical Approach



Implementation on Apple iOS7+ devices requires the device to be enrolled per Apple’s MDM protocol, and takes advantage of the “Managed Configuration” capability. The EMM provider has direct access via Apple’s MDM protocol to send configurations to the NSUserDefaults managed configuration dictionary com.apple.configuration.managed.

The application can be a public app in the iTunes store, or may be an internally developed app signed for enterprise distribution. In either scenario, the app must be distributed as a “managed” application via the EMM provider per the Apple MDM protocol.

During distribution of the application, the EMM provider may include the managed app configurations bundled as part of the app installation command. In this scenario, the app configurations will be available to the app on first launch. Additionally, the EMM provider has the ability to update the configurations over the air at any point in the future to an existing managed application, without requiring the app itself to be re-‐installed.

Security Considerations Apple iOS provides built in validation of the EMM system writing to the managed configurations, however does not provide encryption of these configuration values. Apple iOS only allows a device to be associated with a single EMM server, and only this EMM server can write to the managed configurations section of the application. The EMM system is responsible for detecting and taking remediation action on a device that has been compromised or jailbroken that may expose the managed configurations. As a best practice, sensitive information such as passwords or certificates should not be sent to the device using this approach.

Sample Code The below code can be used to read from NSUserDefaults

NSString *keyValue = [[[NSUserDefaults standardUserDefaults] dictionaryForKey:@"com.apple.configuration.managed"] objectForKey:@"keyName"];

Reference: https://developer.apple.com/library/ios/samplecode/sc2279/Introduction/Intro.html

Best Practices

• On first launch of the application, check if the managed configuration is available. Handle the scenario should the managed configuration not be available.

• On future launch events, check if updated configurations are available in the application

AirWatch Specific Setup When adding an application in AirWatch, select the “Send Application Configuration” option to add the appropriate keys, values, and data types.

AirWatch supports the concept of “lookup values” which allows for values to be sent dynamically -‐ specific to each user or device. For example if the {EmailAddress} lookup value is used, AirWatch will send a user specific email address for the user the device belongs to as part of the configuration, as opposed to a generic hard coded value. Custom lookup values can be pulled from AD attributes as well.

Ref: Managed Configuration

https://developer.apple.com/library/ios/samplecode/sc2279/Introduction/Intro.html

Ref: Apple MDM Protocol (Requires Apple Enterprise Developer Account to access)

https://developer.apple.com/devcenter/download.action?path=/Documents/mobile_device_management_protocol/mobiledevicemanagementprotocol.pdf

Ref: Enterprise App Distribution

https://developer.apple.com/programs/ios/enterprise/

App Configuration for Enterprise | v.Mar 2015 Copyright © 2015 AirWatch, LLC. All rights reserved. Proprietary & Confidential. 4

Reference the AirWatch Mobile Application Management Guide in the myAirWatch Resource portal (resources.air-‐watch.com) for more details.

Implementation: Android 5.0+ (Lollipop)

Technical Approach Implementation on Android L devices takes advantage the “App Restrictions” capabilities, and requires the device to be enrolled with an EMM provider. App developers specify which configuration keys the app supports and listens for. EMM providers are able to detect these keys, and provide an administrator the ability to specify the values to send for each key the app supports. These restrictions are supported for both public apps on the Google Play store, as well as internally developed applications distributed directly via EMM on supported Android devices.

App restrictions are sent to the device during the initial installation of the app, and can be updated over the air at any point in the future.

To incorporate this functionality, developers must follow the below steps:

• Application must define application restrictions in AndroidManifest.xml

• Register a receiver for the ACTION_APPLICATION_RESTRICTIONS_CHANGED broadcast action

• Read and apply restrictions using UserManager.getApplicationRestrictions() immediately after first launch of the application, and whenever the restrictions change as indicated by theACTION_APPLICATION_RESTRTICTIONS_CHANGED broadcast

REF: Syntax for including app restrictions in AndroidManifest.xml

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

REF: Broadcast intent indicating restrictions have changed

http://developer.android.com/reference/android/content/Intent.html#ACTION_APPLICATION_RESTRICTIONS_CHANGED

Ref: getApplicationRestrictions API call

http://developer.android.com/reference/android/os/UserManager.html#getApplicationRestrictions(java.lang.String)

Application includes app restrictions in

AndroidManifest.xml and uploads to Play

IT admin assigns app to users in EMM console, and

includes configuration values for app restrictions

On initial launch of application – app calls

getApplicationRestriction() and registers for restrictions

changed broadcast

App applies configurations

IT admin updates restriction values in EMM console to

trigger a restrictions changed broadcast. App calls

getApplicationRestirctions()



Security Considerations Android devices provide built in validation of the EMM system sending the app restrictions, however does not provide encryption of these values. With Lollipop, Android only allows a device to be associated with a single EMM server, and only this EMM server can set restrictions for an application. The EMM system is responsible for detecting and taking remediation action on a device that has been compromised or rooted that may expose the restriction settings. As a best practice, sensitive information such as passwords or certificates should not be sent to the device using this approach.

Sample Code Register restrictions in AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?> <restrictions xmlns:android="http://schemas.android.com/apk/res/android" > <restriction android:key="keyName" android:title="Admin readable name of key" android:restrictionType= "string” android:description="Longer description of how the key is used" /> <restriction ... /> ... </restrictions>

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

Best Practices

• When the “choice” data type is used – the choice options supported are also defined in the Android manifest file by the developer. It is a best practice for EMM vendors to properly detect the use of the choice option as well as the supported choice options, and display in the app configuration UI of the EMM system the choices available to the app.

AirWatch Specific Setup When adding an application in AirWatch, select the “Send Application Configuration” option to add the appropriate keys, values, and data types.

AirWatch supports the concept of “lookup values” which allows for values to be sent dynamically -‐ specific to each user or device. For example if the {EmailAddress} lookup value is used, AirWatch will send a user specific email address for the user the device belongs to as part of the configuration, as opposed to a generic hard coded value.

Reference the AirWatch Mobile Application Management Guide in the myAirWatch Resource portal (resources.air-‐watch.com) for more details.



App Tunnel Use Case An application may require access to web services residing behind a corporate firewall and requires secure app tunnel. A common use case for cloud based public apps is the ability to federate authenticate to an organizations identity provider (IDP). Some organizations use IDP’s that reside on the internal network. As a result, secure app tunneling is required to authenticate to log into the app.

A traditional VPN solution is not adequate due to manual steps required to enable the VPN on the device, and the security exposure by allowing personal apps the same access to the VPN as corporate apps. A more secure, seamless, targeted solution is required to only allow certain applications restricted access to certain intranet endpoints. Mobile operating systems have addressed this problem by enabling a capability commonly referred to as “per-‐app VPN”. Several commercial VPN providers support the per-‐App VPN capabilities available in the mobile operating systems, and EMM providers have the ability to enable these commercial VPN providers on devices. Additionally several EMM providers offer their own per-‐App VPN implementation as an alternative.


Technical Approach ACE leverages the per-‐App VPN protocol available in iOS7+ devices to connect an application to the internal company network. Apps must be developed using the Cocoa framework to take advantage of this functionality. Several mobile app development platforms (MADP), such as PhoneGap, implement the Cocoa framework and are compatible with the per-‐app VPN technology. Some MADP providers, such as Xamarin, do not implement Cocoa by default, however have alternate networking libraries available that do implement Cocoa and can be used with per-‐app VPN.

The app must be deployed under “management” to the device by an EMM provider via Apple’s MDM protocol. During distribution of the application, the EMM provider entitles the application to be an approved user of the per-‐app VPN.

The EMM provider distributes a per-‐App-‐VPN configuration profile to the device with the approved hostnames and domains specified that will automatically initiate the per-‐App-‐VPN connection.

Supported per-‐app VPN Vendors :

• AirWatch Tunnel -‐ https://resources.air-‐watch.com/view/6bnn6dnrzqn4kf8w57vj/en , https://resources.air-‐watch.com/view/qwd2gp3k8nl5b5q77qg6/en

• F5 APM -‐ https://devcentral.f5.com/articles/solving-‐secure-‐mobile-‐access-‐with-‐f5-‐and-‐ios-‐7-‐per-‐app-‐vpn-‐part-‐1

• Pulse Secure (previously Juniper -‐ Junos Pulse)

• Palo Alto Networks GlobalProtect

Sample Code

• No code changes needed, network calls originating from the Cocoa framework will automatically be routed through the per-‐app VPN



Ref: Enterprise App Distribution

https://developer.apple.com/programs/ios/enterprise/

REF: Apple per-‐App VPN configuration Profile (implemented by EMM vendors)

https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html



Best Practices

• Leverage certificate authentication to perform single-‐sign on to the VPN for a seamless user experience

• If using a Mobile App Development Platform (MADP) to develop the application, consult the MADP provider to understand if the underlying network calls are implementing the Cocoa framework, or if alternate APIs are available from the MADP provider that do implement the Cocoa framework. For example, PhoneGap/Cordova applications implement Cocoa, however Xamarin has an alternate network library that is required to take advantage of Cocoa.

AirWatch Specific Setup

• Configure and distribute the VPN profile in Devices-‐>Profiles-‐>iOS-‐>VPN

• Specify the domains/hostnames in the profile to auto-‐trigger the VPN

Add an application, and entitle the app to “Use VPN” the per-‐App VPN on the “Deployment” tab




Technical Approach ACE leverages the per-‐App VPN protocol available in Android L devices to connect an application to the internal company network.

VPN vendors implement the Android Lollipop VPN APIs available here in a VPN client app that is typically available in the Play store, and can be distributed to an organization’s devices via EMM. Additionally, the VPN vendor may implement the App Restriction capabilities outlined in the “App Configuration” section of this document to provide EMM systems the ability to configure the VPN application automatically.

EMM systems will distribute and configure the VPN vendor’s VPN app, and include the list of approved applications as part of the configuration sent to the VPN app.

Supported VPN Vendors :

• AirWatch Tunnel

• F5 APM

• Pulse Secure (previously Juniper – Junos Pulse)

• Palo Alto Networks -‐ GlobalProtect

Sample Code

• No code changes needed

Ref: Android per-‐app VPN APIs (implemented by VPN providers)

http://developer.android.com/reference/android/net/VpnService.Builder.html#addAllowedApplication(java.lang.String)



Single Sign On Use Case For security reasons, organizations may want to restrict access to certain native enterprise applications to only run on approved compliant devices. Additionally, once access has been granted to an application, single sign-‐on is required for a seamless user experience for the end user.

Many organizations use federated authentication to a common identify provider (IDP) such as Active Directory Federation Services (ADFS), PING, Okta, or VMWare Workspace Portal. Additionally, organizations commonly use a PKI certificate infrastructure as part of a single sign-‐on strategy. ACE leverages these investments, and extends the capabilities to mobile applications for single sign-‐on.

To leverage ACE, the application developer is required to implement the SAML standard to federate authentication to an IDP. This SAML IDP must be configured to require either Kerberos authentication, or certificate authentication. The EMM solution will distribute the appropriate Kerberos credentials and/or certificates based on standard built in operating system API calls available to EMM providers. Additionally, the EMM vendor will entitle certain applications to have the rights to access these credentials. In this setup, the certificate and/or Kerberos credentials facilitate access control as well as single sign-‐on into the application.


Technical Approach Two approaches are available for iOS 7+ devices for Single Sign On that require certificates.

1. Apple MDM Kerberos based enterprise “Single Sign-‐On Account Payload” (ESSO)

Requirements for app developer

• SAML support in application

Requirements for organization

• SAML Identity provider that supports Kerberos (ADFS, VMware Workspace Portal, Ping, Okta)

• Certificate Authority

• “App Tunnel” module of ACE setup (Kerberos will require the device to have access to the domain controller, typically on the internal network)

Technical Details of Flow

• As of iOS7, Apple has enabled the capability for EMM providers to configure a Kerberos based “Single Sign-‐On Account Payload” profile on an MDM managed device – and scope the SSO to be available to only certain approved, managed apps.

• With iOS8, Apple extended this capability to include the ability to perform a certificate-‐based authentication to initiate the Kerberos session and avoid requiring the end user from needing to enter his/her username and password.

• When a network call is made from an application that has been approved by EMM to use the Kerberos SSO profile, iOS will monitor this network call at the operating system layer in case SSO is needed.

• Should the network call get a “401 Negotiate” response from a server, indicating that Kerberos is required, iOS will automatically detect the 401 and initiate the Kerberos SSO exchange with the endpoint based on the settings and certificates available in the Kerberos SSO profile sent to the device via EMM.

o Many identity providers (IDP), including VMware workspace portal, and Active Directory Federated Services (ADFS) support Kerberos based authentication.



• No code change is required by an application developer, the Kerberos SSO transaction is transparent to the application and the result of the network call once authenticated will be an HTTP 200 success.

• Should the device fall in a non-‐compliant state and access needs to be revoked, the EMM provider will revoke the certificate as well as remove the application from the device – rendering the mobile app not usable

• NOTE: Typically Kerberos requires the device to have direct access to the organizations Domain Controller (KDC). As a result – this approach is typically used in conjunction with VPN capabilities discussed in the “App Tunnel” section.

2. Certificate authentication via Safari Browser

Requirements for app developer

• SAML support in application

• Implement ACE App Configuration “RequireCertAuth” to trigger this flow

Requirements for organization

• SAML Identity provider that supports certificate authentication

• Certificate Authority

Technical Details of Flow

• EMM providers have the ability to send user/device specific certificates that are accessible by the Safari browser on iOS devices via Apple’s MDM protocol. These certificates are not directly accessible by native applications, however are accessible via Safari.

• Enterprise applications that support federating identity via SAML to an organizations IDP have two options when presenting the identity provider’s authentication page to the user: (1) embed a web view into the application, (2) redirect to the full safari browser. The full safari browser has access to certificates distributed via EMM providers, however embedded web views do not. Enterprise applications are required to build in the capability to launch the IDP authentication page in the full safari browser in order to take advantage of this capability.

o NOTE: If implemented by the app developer, the “App Configuration” capability described in this document can be used to notify an application when to present the authentication page in the full safari browser vs. an embedded web view.

• The identity provider is configured for certificate authentication, and to trust the certificate issued by the EMM provider.

• Once the App redirects to the safari browser, Safari will use the certificate distributed via the EMM provider to facilitate SSO, and the IDP is configured to redirect the user back into the native application once authenticated.


Technical Approach Certificate authentication using Android L “managed keystore”



REF: Certificate configuration profile documentation

https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html



• EMM providers have the ability to send user/device specific certificates to a “managed keystore” on Android L devices.

• The certificates distributed via an EMM provider are installed in a protected area of the Android keystore and are only accessible to apps that are distributed under management via the EMM provider.

• The EMM provider will send the certificate alias using the app restrictions API mentioned in the “App Configuration” portion of ACE using the key “ManagedAppCertAlias”

• The App will use the alias it received in the “ManagedAppCertAlias” to query the android keychain using the getPrivateKey(alias) method in the Android SDK. Alternatively, the choosePrivateKeyAlias() method can be used to bring up a UI certificate picker for the end user.

o http://developer.android.com/reference/android/security/KeyChain.html

• The certificate can be used by the application to authenticate directly to a web service that requires certificate authentication, or can be used by the application to authenticate to an embedded web view to a SAML IDP.

Access Control Use Case For security reasons, enterprises may want to prevent users from downloading approved apps directly from the iTunes or Google Play store on the personal container of their device, and allow access to the app in an unmanaged and unsecure state.


Technical Approach Two approaches are available for iOS 7+ devices for Access Control.

1. On iOS, access control can be facilitated by using the “Single Sign-‐On” capabilities outlined in this document. The Single Sign-‐On capability requires a certificate to be available to the enterprise approved application in order to login and access the application. This certificate will only be available for a compliant app on a managed device. As a result, a user downloading the application from iTunes store or Google Play store as a personal app on an unmanaged device will not be able to authenticate and log into the application.

2. A second approach to access control on iOS is to leverage the “App Tunnel” capability described in this document. An enterprise can configure the authentication page of an application to only accept connections from users who are coming through the secure App Tunnel, based on IP address. The App Tunnel capability is only available for compliant apps on managed devices. As a result, a user downloading the application from iTunes store or Google Play store as a personal application on an unmanaged device will not be able to authenticate and log into the application.

Implementation: Android 5.0+ (Lollipop) Android L devices take advantage of “App Restrictions” to configure an enterprise application and require the device to be enrolled with an EMM provider. Enterprise can leverage the app configuration key “AllowAppAccess” to allow/deny access to an application. The application will use the value it received in the “AllowAppAccess” configuration key and grant access to the application if set to true.

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 like dropbox.



Implementation: Apple iOS7+ Apple iOS7+ devices provide EMM vendors out of the box capabilities to enforce security settings on enterprise apps. For example:

• Encryption

• Managed “Open In”

• Custom Security Setting using “App Configuration”

Encryption

EMM vendors can enforce iOS “data protection” for enterprise apps by enforcing a passcode policy on the device. To learn more about iOS encryption and security, reference the following site: https://www.apple.com/business/docs/iOS_Security_Guide_Oct_2014.pdf

AirWatch Specific Setup: In AirWatch, encryption is enforced by requiring a passcode on the device. This setting is available in Device-‐>Profiles-‐>iOS-‐>Passcode. AirWatch also has the ability to track, report, and trigger compliance actions on the encryption state of the device.

Managed “Open In” In iOS7.0 and later, EMM providers using Apple’s MDM protocol can prevent the accidental movement of data in and out of trusted and untrusted applications. In iOS, an app becomes trusted if it is distributed to the device under management using the Apple MDM protocol. An app that is directly downloaded from the iTunes store is considered unmanaged or untrusted.

EMM providers have the ability to deliver a configuration profile with a restrictions payload specifying “Allow Open From Managed To Unmanaged” and “Allow Open From Unmanaged To Managed.”

By using these features, the “Open In” sheet started from within a managed app will only contain other managed apps. Likewise, unmanaged apps will only be able to share data with other unmanaged apps.



On iOS, if the corporate email configuration is sent to the native email app in iOS via the MDM protocol, the corporate email configuration will be considered a trusted and managed app and will participate in data sharing between other managed apps. Personal email accounts configured on the device manually will continue to be untrusted and unmanaged however.

AirWatch Specific Setup: In AirWatch, the Managed Open In capability is available in Device-‐>Profiles-‐>iOS-‐>Restrictions. The configuration items are “Allow documents from managed sources in unmanaged destinations” and “Allow documented from unmanaged sources in managed destinations”

Custom Security Policies using “App Configurations”

App developers can implement custom security settings and leverage the “App Configuration” capabilities described in this document to toggle these settings on or off.

For example, an app may contain the ability to sync with drop box. An enterprise may want to disable this capability from being used. The app developer can use the “App Configuration” capability in ACE to specify a configuration key, such as “allowDropBox”. When the app detects an EMM provider has set the allowDropBox value to “false”, the app developer can implement logic to disable the drop box syncing capability from within the app.

Common implementations of custom security polices include:

• Disable Public Cloud Sync – ability to disable syncing app data with public clouds like drop box

• Disable Copy/Paste – ability to disable the copy/paste capability from within the app

• App Pin Code Settings – ability to specify a pin code to enter the application, and the respective complexity requirements for the pin code

• Default Browser Settings – ability to specify an alternate browser to be used to open hyperlinks within the application

• Default Email Settings – ability to specify the default email app to be used to send emails within the app

Sample iOS code for clearing copy/paste data:



Reference the “App Configuration” section of this document for additional details on implementing these custom security policies.

Implementation: Android 5.0+ (Lollipop) Android L devices enabled with Android Work capabilities provide EMM vendors out of the box capabilities to enforce security settings on enterprise apps. For example:

• Encryption

• Copy/Paste Control

• Screenshot Control

• Managed “Open In” and Data Sharing Control

• Custom Security Setting using “App Configuration”

Encryption

EMM vendors can enforce Android encryption for enterprise apps. To learn more about Android encryption and security, reference the following site: https://source.android.com/devices/tech/security/encryption

Managed “Open In” and Data Sharing Control

In Android L devices, EMM providers are enabled directly by the operating system to separate and provide a strong boundary between personal and corporate apps. Neither personal nor corporate apps can directly access data (read or write) in the other space on the device. Android’s multi user framework provides clear segregation of data and apps processes.

Copy/Paste Control

EMM vendors can limit copy/paste clip board access to prevent cross work/personal copy/paste

Screenshot Control

EMM vendors can disable screenshot access on Android Work applications

Custom Security Policies

App developers can implement custom security settings and leverage the “App Configuration” capabilities described in this document to toggle these settings on or off.

For example, an app may contain the ability to sync with drop box. An enterprise may want to disable this capability from being used. The app developer can use the “App Configuration” capability in ACE to specify a configuration key, such as

UIPasteboard *pb = [UIPasteboard generalPasteboard]; NSArray *pbtypes = [pb pasteboardTypes]; if (pbtypes.count) {

for (NSString *pbtype in pbtypes) {

[pb setValue:@"" forPasteboardType:pbtype]; }

}



“allowDropBox”. When the app detects an EMM provider has set the allowDropBox value to “false”, the app developer can implement logic to disable the drop box syncing capability from within the app.

Common implementations of custom security polices include:

• Disable Public Cloud Sync – ability to disable syncing app data with public clouds like drop box

• App Pin Code Settings – ability to specify a pin code to enter the application, and the respective complexity requirements for the pin code

Reference the “App Configuration” section of this document for additional details on implementing these custom security policies.



APPENDIX I -‐ ACE Suggested Configurations

Suggested App Configuration Key Names The below configurations suggest the preferred key naming convention for commonly used configurations in enterprise apps. The following data types are supported on iOS and Android devices

• Integer

• String

• String[]

• Boolean

App Service Configuration allows the application to connect to the appropriate app web services for an organization.

Key Required Type Value Description

AppServiceHost N String (e.g. appserver.com)

Hostname used to communicate with the application’s primary server (e.g. myserver.com). Application should implement its own default value.

AppServiceHosts N String[] (e.g. appserver.com, appserver2.com, appserver3.com)

If multiple hosts can be configured in the application, they will be sent as a string array. The first host in the list will be used as the default.

AppServicePort N String (e.g. 443)

Port number used to communicate with the application’s primary server (e.g. 443). Application should implement its own default value.

AppServiceUseSSL N Boolean (e.g. TRUE, FALSE) Determines if the application should use SSL when communicating to the applications’ server. Application should implement a default value.

User Configuration allows the application to detect the user of the application, however does not authenticate the user.

KeyID Required Type Example Description

UserGroupCode N String (e.c. ACME) Group or tenant code used to identify an organization in the scope of a multi-‐tenant SaaS provider environment.

UserName N String (e.g. wtillman) Username of the user who is using the device. Value to be used by application to authenticate user.

UserEmail N String (e.g. [email protected])

Email address of the user who is using the application.

UserDomain N String (e.g. NADOMAIN) Domain of the user who is using the application (e.g. EMEADOMAIN)

Branding Configuration allows an application to customize the look and feel for a specific organization.




BrandingBackground N String (e.g. http://myserver/image.png)

String representing HTTP(S) URL of the image to download and display as the main wallpaper within the application. Each application could implement the visual representation differently. Images recommended to be in PNG format.

BrandingLogo N String (e.g. http://myserver/image.png)

String representing HTTP(S) URL of the image to download and display as the main wallpaper within the application. Each application could implement the visual representation differently. Images recommended to be in PNG format.

BrandingName N String (e.g. Company Name) String representing the company name which could be displayed in the application

Single Sign on and Access Control as specified in ACE uses the following keys as part of the certificate or share secret key flows.


RequireCertAuth N Boolean (e.g. True) iOS, Android

Reference the SSO and Access control section of ACE for usage details. Notifies the app if a certificate is available to perform single sign-‐on.

ManagedAppCertAlias N String Android only Alias to certificate that can be used for SSO (Android only)

AllowAppAccess N Boolean (e.g. True) Android only

Reference the Access Control section of this document for usage details. Notifies the app if user is allowed access or not.

Security Settings allows an app to enable or disable certain security features


DisableClipboardOnBackground N Boolean (e.g. False) Configuration needed on iOS only, Android has built in capability. Reference “Security Policies”

DisableFileSave N Boolean (e.g. False)

DisableFileSaveUnencrypted N Boolean (e.g. False) Android only

DisableOpenIn N Boolean (e.g. False) Disables any built in capabilities in the app to open files in other apps

DisablePrint N Boolean (e.g. False)

DisableAutoUpload N Boolean (e.g. False)

EnablePasscode N Boolean (e.g. False) To enable a pin code to access the application

PasscodeTimeout N INT (e.g. 4) Units typically in hours

Custom Configuration allows an application to define its own dictionary of keys specific to configurations needed by the app.


To be specified by app developer

N

Reference iOS and Android docs

To be specified by app developer

Custom settings such as proxy settings, tenant or group codes, logging levels, etc. can be defined by the app developer.



APPENDIX II – Sample 10 day project plan for App Developers

Day 1: Kick Off

• Kick off call with ACE organization to identity use cases and priorities

• Identify logistics and system access requirements to perform tests in phase 1 Day 2: Validate ACE capabilities that do not require development effort

• Connectivity (iOS) -‐ Validate per-‐App VPN works with networks calls in app

• Connectivity (Android) -‐ Validate per-‐App VPN works with networks calls in app

• SSO (iOS): Validate iOS Kerb SSO functions if app already supports federation

• Security (Android): Validate security settings on android work: screenshot, copy/paste, managed open in, encryption

• Security (iOS): Validate security settings on iOS -‐ encryption, managed open in Days 4 & 5: Add App Configuration Capabilities

• Configuration (iOS): Build in app config capability on iOS to simplify first time setup experience for app

• Configuration (Android): Build in app config capability on iOS to simplify first time setup experience for app

Days 5 & 6: Add Custom Security Policies using App Configurations

• Security (iOS): Build in advanced app configs for disable copy/paste, app passcode enabled, passcode timeout

• Security (Android): app passcode enabled, passcode timeout

• Access Control (iOS & Android): Build in iOS access control protocol with managed keys Days 7 & 8: Certificate based SSO capabilities

• SSO (iOS): Build in certificate SSO capability

• SSO (Android): Build in certificate SSO capability

Day 9 & 10: Integration testing and Documentation

• Coordination with ACE organization and self-‐service testing of capabilities

• Document capabilities and configurations

• Submit application to be featured on ACE website