Introduction

Background

The AppConfig Community’s initiative is to define a collection of  best practices 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 the AppConfig Community’s guidance, app developers can build a single application that works across all EMM vendors. The developer can enable their apps with enterprise and user experience enhancing features such as automatic configuration of settings, app tunneling, single sign-on, and various security policies. This is all accomplished by leveraging native APIs and capabilities that are built into modern mobile operating systems, and made available to EMM vendors by the operating systems themselves.

By leveraging the information provided by the AppConfig Community, customers benefit with seamless and secure access to business apps, app developers benefit with increased enterprise adoption and uniform EMM support, and EMM vendors can integrate with a much broader ecosystem of mobile applications.

 

Capabilities

The AppConfig Community defines the following capabilities described in this document:

  • App Configuration
  • Security Policies
  • App Tunnel
  • Single Sign-On

App Configuration

Use Case

Many enterprise 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 the native APIs recommended by the AppConfig Community, these configurations can be automatically set remotely by the EMM server. This simplifies the setup process for end users, and alleviates the help desk and documentation burden. 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: server URL, port, use SSL, group/tenant code
  • User configuration: username, email, domain

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

Implementation: Apple iOS 7+

How it Works

Requirements

  • iOS 7+ device enrolled with Apple’s mobile device management protocol
  • App is developed with iOS managed configuration capabilities built in
  • Distribute app via an EMM vendor that supports “Managed Configuration”

Process Flow

  • App developer adds “Managed Configuration” capability into the app
  • App developer creates XML definition file (See Appendix) documenting the configurations that the app supports
  • App developer makes the app available to the organization. The application can be a public app in the iTunes store, or may be an internally developed app signed for enterprise distribution.
  • 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 Sample Code

Since the release of iOS 7, MDMs have the ability to write to the NSUserDefaults of a managed application. An enterprise developers responsibility is to now build their applications to read these values and implement logic to handle the values received. In order to do this, additional code is needed to read the NSUserDefaults dictionary.

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

Step 1: Implement code to read the NSUserDefaults com.apple.configuration.managed dictionary

AppConfig.org GitHub link: Coming Soon
Apple Developer References:
https://developer.apple.com/library/ios/samplecode/sc2279/Introduction/Intro.htm Snapshot of sample code for convenience:

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

Step 2: Create an XML definition file to document the configurations your app supports

This XML files creates a standard scheme to document the accepted configs and values that your app supports. Many EMM vendors support automatically parsing these files in the EMM admin console.

Developer reference: Visit Appendix
Contact your EMM vendor of choice for additional assistance

Step 3: Make your app available

Follow the instructions on the AppConfig.org site to submit your app to be verified and listed online.

The application can be a public app in the iTunes store, or may be an internally developed app signed for enterprise distribution.

Note: The app must be distributed as a “managed” application via the EMM provider per the Apple MDM protocol. The EMM provider has direct access via Apple’s MDM protocol to send configurations to the NSUserDefaults managed configuration dictionary.

Note:
Sensitive information such as passwords or certificates should not be sent to the device using this approach.

  • 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.

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

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:

            
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)
            
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

 AndroidManifest

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.

Implementation: Apple iOS 7+

Technical Approach

ACE leverages the per-App VPN protocol available in iOS 7+ 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.

            
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/ 

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

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

            
Supported per-app VPN Vendors :
Sample Code
  • No code changes needed, network calls originating from the Cocoa framework will automatically be routed through the per-app VPN
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

Implementation: Android 5.0+ (Lollipop)

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.

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

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

Supported VPN Vendors :

  • AirWatch Tunnel
  • F5 APM
  • Pulse Secure (previously Juniper – Junos Pulse)
  • Palo Alto Networks – GlobalProtect

Sample Code

  • No code changes needed

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 Security & Access as well as single sign on into the application.

Implementation: Apple iOS 7+

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 iOS 7, 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.
    • 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.
            
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: Certificate configuration profile documentation

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

            

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.
    • 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.

Implementation: Android 5.0+ (Lollipop)

Technical Approach

Certificate authentication using Android L “managed keystore”

  • 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.
    • 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.

Implementation: Apple iOS 7+

Technical Approach

Two approaches are available for iOS 7+ devices for Security & Access.

  1. On iOS, Security & Access 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 Security & Access 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 iOS 7+

Apple iOS 7+ 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 iOS 7.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:

            
UIPasteboard *pb = [UIPasteboard generalPasteboard];
NSArray *pbtypes = [pb pasteboardTypes];

if (pbtypes.count)
{
for (NSString *pbtype in pbtypes)
{
[pb setValue:@"" forPasteboardType:pbtype];
}

}
            

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 “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.

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

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

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

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

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

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
  • Security & Access (iOS & Android): Build in iOS Security & Access 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