Securing and managing the app using the AppConnect library

A MobileIron server administrator configures how mobile device users can use secure enterprise applications. The administrator sets the following app-related settings that impact your app’s behavior:

Additionally, the AppConnect library provides the following capabilities for your app:

The following steps show the flow of information from the MobileIron server to your app:

  1. The MobileIron server administrator decides which app-related settings to apply to a device or set of devices.
  2. The MobileIron server sends the information to the MobileIron client app.
  3. The MobileIron client app passes the information to the AppConnect library. The MobileIron client app and the AppConnect library enforce the AppConnect passcode policy. The AppConnect library enforces tunneling.
  4. Using the AppConnect for iOS API, your app can find out the current settings and receive notifications of changes.

Your app is responsible for:

  • enforcing authorization
  • handling the data loss prevention policies
  • using the configuration specific to the app.
  • protecting the app’s data independent of device level encryption by using the AppConnect secure file I/O APIs
  • logging messages to the console using the AppConnect logging APIs
  • preserving the app’s state when control switches to the MobileIron client app and then back to the app due to the AppConnect app check-in interval or auto-lock time expiring.

Authorization

Your app uses the AppConnect library to get the user’s authorization status for using the app and to be notified of changes. For more information, see Authorization API details.

The MobileIron server administrator determines:

  • whether or not each device user is authorized to use each secure enterprise app.

    If the user is not authorized, the app should not allow the user to access any secure data or functionality. If the app handles only secure data and functionality, then the app does nothing more than display a message that the user is not authorized to use the app.

  • the situations that cause an authorized device user to become unauthorized.

    These situations include, for example, when the device OS is compromised. the MobileIron client app reports device information to the MobileIron server. The server then determines whether to change the user to unauthorized based on security policies on Core.

    When a user becomes unauthorized, the app should stop allowing the user access to any secure data or functionality.

  • the situations that retire the app.

    Retiring an app means that the user is not authorized to use it, and the app removes all secure data associated with the app.

When an app is retired, you remove all its secure data. When a user is unauthorized but the app is not retired, you do not allow the user to access the data, but you do not have to remove it. The reason is that an unauthorized user can become authorized again, and therefore the secure data should become available again.

AppConnect passcode and Touch ID/Face ID policy

The AppConnect library and the MobileIron client app enforce the passcode or Touch ID/Face ID, and the auto-lock timeout. The only task for your app is to include Privacy - Face ID Usage Description in your app’s info.plist. Beyond that plist addition, your app does not handle the AppConnect passcode or Touch ID/Face ID at all.

The MobileIron server administrator determines:

  • whether the AppConnect passcode or Touch ID/Face ID is required, which requires the device user to enter a passcode or Touch ID/Face ID to access any secure enterprise apps.
  • the complexity of the AppConnect passcode.
  • the auto-lock (inactivity) timeout for the AppConnect passcode or Touch ID/Face ID.

The AppConnect library and the MobileIron client app enforce an AppConnect passcode or Touch ID/Face ID as follows:

  • The MobileIron server notifies the MobileIron client app when the server administrator has enabled an AppConnect passcode or Touch ID/Face ID. The MobileIron client app prompts the user to set the passcode, if required, the next time that the device user launches or switches to a secure enterprise app.
  • The user is prompted to enter the passcode or Touch ID/Face ID when the user subsequently launches or switches to a secure enterprise app but the auto-lock timeout has expired.
  • The user is prompted to enter the passcode or Touch ID/Face ID when the auto-lock timeout expires while the user is running a secure enterprise app.
  • The MobileIron client app prompts the user to set the passcode, if required, the next time the device user launches or switches to a secure enterprise app after the MobileIron server has notified the MobileIron client app that the passcode’s complexity rules have changed.

Configuration specific to the app

Sometimes an app requires app-specific configuration. Some examples are:

  • the address of a server that the app interacts with
  • whether particular features of the app are enabled for the user
  • user-related information from LDAP, such as the user’s ID and password
  • certificates for authenticating the user to the server that the app interacts with

You determine the app-specific configuration that your app requires. Each configurable item is a key-value pair. Each key and value is a string. A MobileIron server administrator specifies the key-value pairs for each app on the server. The administrator applies the appropriate set of key-value pairs to a set of devices. Sometimes more than one set of key-value pairs exists on the server for an app if different users require different configurations. For example, the administrator can assign a different server address to users in Europe than to users in the United States.

NOTE: When the value is a certificate, the value contains the base64-encoded contents of the certificate, which is a SCEP or PKCS-12 certificate. If the certificate is password encoded, the server automatically sends another key-value pair. The key’s name is the string <name of key for certificate>_MI_CERT_PW. The value is the certificate’s password.

Your app uses the AppConnect library to get the configuration and to be notified of changes. Then your app applies the configuration according to its requirements.

For more information, see App-specific configuration API details .

AppTunnel

Using MobileIron’s AppTunnel feature, a secure enterprise app can securely tunnel HTTP and HTTPS network connections from the app to servers behind an organization’s firewall. A Standalone Sentry is necessary to support AppTunnel with HTTP/S tunneling. The MobileIron server administrator handles all HTTP/S tunneling configuration on the server. Once the administrator has configured tunneling for the app on the server, the AppConnect library, the MobileIron client app, and a Standalone Sentry handle tunneling for the app.

Your app accesses its enterprise servers as it normally would using NSURLConnection or NSURLSession. Your app typically does not take any special actions related to tunneling. Although your app uses a server address that results in tunneling, your app does not know that tunneling is occurring. Typically, the MobileIron server administrator uses AppConnect’s app-specific configuration to specify the enterprise server URL that the app uses. See Configuration specific to the app.

NOTE: Initialize the AppConnect library before registering any NSURLProtocol subclasses that your app uses. See Initialize the AppConnect library.

Consider the following information to ensure that your app can successfully tunnel network connections:

AppTunnel supports only NSURLConnection and NSURLSession

Always access servers using NSURLConnection or NSURLSession.

Note The Following:  

  • AppTunnel with HTTP/S tunneling does not support using NSURLSession in a background session. The traffic does not reach its destination
  • You can also use networking libraries that use NSURLConnection or NSURLSession. For example, apps can use AFNetworking 3.0 because it uses NSURLSession.
  • AppTunnel with HTTP/S tunneling does not support WKWebView objects.

Accessing sockets directly does not use AppTunnel

AppTunnel with HTTP/S tunneling is not supported if the app:

  • accesses sockets directly.
  • uses APIs that access sockets directly.

In these cases, the app cannot access a host behind the enterprise’s firewall using AppTunnel with HTTP/S tunneling.

For example, AppTunnel with HTTP/S tunneling is not supported with the following APIs:

  • Apple’s reachability APIs that detect network and host connectivity.
  • CFNetwork APIs
  • ASIHTTPRequest
NOTE: Network connections using sockets for TCP connections can tunnel data by using AppTunnel with TCP tunneling. See AppTunnel with TCP tunneling.

App’s responsibilities when using AppTunnel

For many apps, the app takes no special actions to use AppTunnel with HTTP/S tunneling. However, special actions are required if your app requires:

AppTunnel supports redirects and authentication requests on HTTP/S upload

When an app uses AppTunnel with HTTP/S tunneling, AppTunnel handles the following HTTP/S upload scenarios without any special actions by the app:

  • HTTP/S redirect responses from the server (HTTP/S 3XX status code).

    If a server redirects an HTTP/S upload request (tunneled or not) to another URL that the MobileIron server administrator has configured for tunneling, the request is tunneled.

  • Authentication required response from the server (HTTP/S 401 status code).

    The AppTunnel feature handles sending a second HTTP/S request with authentication credentials.

AppTunnel with TCP tunneling

AppTunnel can tunnel TCP traffic between an app and a server behind the company’s firewall. AppTunnel with TCP tunneling does not require an app to be an AppConnect app; both AppConnect apps and standard apps can use AppTunnel with TCP tunneling.The MobileIron server administrator configures AppTunnel with TCP tunneling, including installing MobileIron Tunnel (an iOS app) on the device. Your app takes no actions related to using AppTunnel with TCP tunneling.

Certificate authentication to enterprise services

Without any development, an AppConnect app can send a certificate to identify and authenticate the app user to an enterprise service when the app uses an HTTPS connection. The MobileIron server administrator configures on the server which certificate for the app to use, and which connections use it. The AppConnect library, which is part of every AppConnect app, makes sure the connection uses the certificate. Your app takes no action at all.

Supported networking methods

Certificate authentication to enterprise services is supported only if your app uses one of the following to access the enterprise service:

  • NSURLConnection
  • NSURLSession

Certificate authentication to enterprise services does not support using NSURLSession in a background session.

  • Networking libraries that use NSURLConnection or NSURLSession.
  • UIWebView

Unsupported networking methods

Certificate authentication to enterprise services using other networking methods is not supported. For example, the following are not supported:

  • accessing sockets directly

  • WKWebView and other APIs that access sockets directly

    For example, these APIs are not supported: CFNetwork, ASIHTTPRequest, and Apple's reachability APIs that detect network and host connectivity.

Data loss prevention policies

An app can leak data if it uses iOS features such as copying to the iOS pasteboard, document interaction (Open In and Open From), and print capabilities. A MobileIron server administrator specifies on the server whether each app is allowed to use each of these features.

Specifically:

  • The print policy indicates whether the app is allowed to use: AirPrint, any future iOS printing feature, any current or future third-party libraries or apps that provide printing capabilities.

    Your app enforces the print policy by enabling or disabling printing capabilities based on the print policy.

  • The pasteboard policy specifies whether your app is allowed to copy content to the iOS pasteboard. If copying content is allowed, the policy specifies whether all apps, or only AppConnect apps, can paste the copied content from the pasteboard.

    The AppConnect library enforces the pasteboard policy. Your app disables or enables any special user interfaces that allow copying.

  • The drag and drop policy specifies whether AppConnect apps can drag content to all other apps, to only other AppConnect apps, or not at all.

    The AppConnect library enforces this policy. When the policy allows dragging content to only other AppConnect apps, the AppConnect library notifies your app when the device user attempts to drag content to a non-AppConnect app. Your app can then notify the device user of the situation.

  • The Open In policy specifies the apps, including the extensions that apps provide, with which your app can share documents. The policy specifies no apps, all apps, all AppConnect apps, or a set of apps. A set of apps is called the whitelist. Whether your app can share documents with the native iOS mail app is also controlled by the Open In policy.

    The AppConnect library enforces the Open In policy. Your app disables or enables any special user interfaces that give the user the option to use Open In.

  • The Open From policy specifies the apps, including the extensions that apps provide, from which your app can receive documents when the other app uses the Open In iOS feature. The policy specifies no apps, all apps, all AppConnect apps, or a set of apps. A set of apps is called the whitelist.

    The AppConnect library enforces the Open From policy. Your app informs the user about the Open From policy if you want to.

The administrator applies the appropriate policies to a set of devices. Sometimes more than one set of policies exists on the MobileIron server for an app if different users require different policies.

Your app uses the AppConnect library to get the data loss prevention policies and to be notified of changes. Then your app handles the policies according to its requirements.

For more information, see:

Custom keyboard control

Custom keyboard extensions sometimes send data to servers when a device user enters data into an app. They send this data for assistance with word-prediction, for example. To stop this potentially harmful data loss, the MobileIron server administrator configures whether custom keyboards are allowed for an app by setting a key-value pair in the app’s configuration. The key is called MI_AC_IOS_ALLOW_CUSTOM_KEYBOARDS. The key-value pair is consumed by the AppConnect library; your app does not receive it.

When the key is present, the AppConnect library controls custom keyboard use according to the key’s value. If the value is true, the AppConnect library allows the AppConnect app to use custom keyboards. If the value is false, the AppConnect library does not allow custom keyboard use.

If the server administrator does not include the key-value pair for your app, the AppConnect library does not allow the app to use custom keyboards.

Related topics 

Reject custom keyboard control

Data protection

AppConnect-related data

The MobileIron client app and the AppConnect library work together to use encryption to protect AppConnect-related data, such as configurations and certificates, on the device.

The encryption key is not stored on the device. It is either:

  • Derived from the device user’s AppConnect passcode.
  • Protected by the device passcode if the administrator does not require an AppConnect passcode.
  • Protected by the device passcode if the device user uses Touch ID/Face ID to access AppConnect apps.

If no AppConnect passcode or device passcode exists, the data is encrypted, but the encryption key is not protected by either passcode.

Your app does not handle data protection for AppConnect-related data. the MobileIron client app and the AppConnect library provide this data protection.

App data files

You can protect the contents of your app’s data files using secure file I/O APIs provided by the AppConnect for iOS SDK. This secure file I/O capability means that data encryption for your app’s data, like the AppConnect-related data, is not dependent on the device having a device passcode.

Like the AppConnect-related data, the encryption key is not stored on the device. It is either:

  • Derived from the device user’s AppConnect passcode.
  • Protected by the device passcode if the administrator does not require an AppConnect passcode.
  • Protected by the device passcode if the device user uses Touch ID/Face ID to access AppConnect apps.

The administrator can require an AppConnect passcode, a device passcode, both passcodes, or neither. The administrator can also allow a device user to use Touch ID/Face ID to access AppConnect apps, which requires a device passcode to work. By using the secure file I/O APIs, you know that your app’s data is protected to the extent that the administrator requires. If your app instead relies on iOS data protection to protect your app’s data, data is not protected on devices that have no device passcode. Devices having no device passcode are not uncommon when employees use their own devices at work.

NOTE: When using secure file I/O APIs, the existence of a file, its file name, its path, its approximate size, its creation date, and its last modification date are not encrypted. Any of these items possibly reveal sensitive information.

The following table summarizes the protection of the data that AppConnect apps save on the device. Note that if a device user uses Touch ID/Face ID to access AppConnect apps, a device passcode is available.

 

Table 1. Data encryption of app data

 

Device passcode but no AppConnect passcode

AppConnect passcode but no device passcode

Device passcode and AppConnect passcode

Neither a device passcode or AppConnect passcode

SDK apps that enable iOS data protection (typical behavior)

App data encrypted

iOS encrypts the data, but the encryption key is not protected.

App data encrypted

 

iOS encrypts the data, but the encryption key is not protected.

SDK apps that use SDK-provided secure file I/O

App data encrypted

App data encrypted

App data encrypted

iOS encrypts the data, but the encryption key is not protected.

Some of the secure file I/O APIs also support sharing the encrypted files with other AppConnect apps. These APIs rely on an additional encryption group ID to create the encryption key. Only apps which use the same encryption group ID can read the data. If you use these APIs to share encrypted files with other apps, you provide an app-specific configuration key name to the MobileIron server administrator in your app documentation. The MobileIron server administrator then provides your app and the other apps the same encryption group ID through app-specific configuration for each app.

The SDK provides the following types of secure file I/O APIs:

  • POSIX-style APIs
  • Objective-C subclasses
  • Objective-C class categories

Before your app uses these APIs, use the AppConnect library to get the status of:

  • secure services

    Currently, the only secure service is secure file I/O.

  • secure file I/O

The AppConnect library notifies the app about changes in both statuses.

For more information, see Secure services API details.

NOTE: If your app uses custom cryptography, you can get encryption keys from the AppConnect library. For more information, see Encryption keys for custom cryptography.

Log messages

The AppConnect for iOS SDK provides APIs for your app to use to log messages to the Apple System Log facility, also known as the device’s console. The MobileIron server administrator can specify that the messages are also logged to files on the device.

You specify the log level of each message. The log levels are, from least verbose to most verbose:

  • Error
  • Warning
  • Status
  • Info
  • Verbose
  • Debug

Note The Following:  

  • Error, warning and status messages are always logged to the console.

  • Info messages are logged to the console only if that level is specified by the MobileIron server administrator in the app-specific configuration.

  • Verbose and debug messages are logged to the console only if both of the following are true:

    • The server administrator specified the level and a debug code in the app-specific configuration.

    • The device user enabled the level in the MobileIron client app using the debug code specified by the server administrator. Note that the verbose or debug levels are disabled automatically after 24 hours. The device user can manually disable them sooner.

    Because the verbose and debug levels require a debug code, you can include sensitive data in messages logged at those levels.

For details, including examples of the kinds of messages to log at each level, see Log messages API details.