Securing and managing the app using the AppConnect library
An Ivanti 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:
• AppConnect passcode and Touch ID/Face ID policy
•Configuration specific to the app
•Certificate authentication to enterprise services
•Data loss prevention policies
Additionally, the AppConnect library uses encryption to protect AppConnect-related data, as described in Data protection. However, this protection requires no additional Ivanti server configuration besides requiring an AppConnect passcode or device passcode.
The following steps show the flow of information from the Ivanti server to your app:
- The Ivanti server administrator decides which app-related settings to apply to a device or set of devices.
- The Ivanti server sends the information to the Ivanti client app.
- The Ivanti client app passes the information to the AppConnect library, which is part of the AppConnect Cordova Plugin. The Ivanti client app and the AppConnect library enforce the AppConnect passcode policy. The AppConnect library enforces tunneling.
- Using the AppConnect for iOS Cordova Plugin APIs, your app can find out the current settings and receive events about changes.
Your app is responsible for:
•enforcing authorization
•handling the data loss prevention policies
•using the configuration specific to the app.
Authorization
The Ivanti 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 Ivanti client app reports device information to the Ivanti server. The server then determines whether to change the user to unauthorized based on security policies on the server.
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.
Your app uses the AppConnect for iOS Cordova Plugin to get the user’s authorization status for using the app and to be notified of changes. For more information, see Authorization API details.
AppConnect passcode and Touch ID/Face ID policy
The Ivanti 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 time for the AppConnect passcode or Touch ID/Face ID.
The AppConnect library and the Ivanti client app enforce an AppConnect passcode as follows:
•The Ivanti server notifies the Ivanti client app when the server administrator has enabled an AppConnect passcode or Touch ID/Face ID. The Ivanti client app prompts the user to set the passcode the next time that the device user launches or switches to a secure enterprise app.
•The Ivanti client app prompts the user to enter the passcode or Touch ID/Face ID when the user subsequently launches or switches to a secure enterprise app but the inactivity timeout has expired.
•The Ivanti client app prompts the user to enter the passcode or Touch ID/Face ID when the auto-lock time expires while the user is running a secure enterprise app.
•The Ivanti client app prompts the user to set the passcode the next time the device user launches or switches to a secure enterprise app after the Ivanti server has notified the Ivanti client app that the passcode’s complexity rules have changed.
Your app does not handle the AppConnect passcode or Touch ID/Face ID at all. The AppConnect library and the Ivanti client app enforce the passcode or Touch ID/Face ID, and auto-lock time.
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. An Ivanti server administrator specifies the key-value pairs for each app on the Ivanti 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.
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 Ivanti 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 for iOS Cordova Plugin 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 Ivanti'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. An Standalone Sentry is necessary to support AppTunnel with HTTP/S tunneling. The Ivanti server administrator handles all AppTunnel configuration on the server. Once the administrator has configured tunneling for the app on the server, the AppConnect library, the Ivanti client app, and Standalone Sentry handle tunneling for the app.
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 Ivanti server administrator uses AppConnect’s app-specific configuration to specify the enterprise server URL that the app uses. See Configuration specific to the app.
If your app requires locally cached URL responses, it must take a special action. See Caching tunneled URL responses.
Supported APIs
AppTunnel with HTTP/S tunneling supports typical JavaScript network APIs, such as XMLHttpRequest or jQuery calls. More generally, AppTunnel with HTTP/S tunneling supports any network API that Cordova binds to the Objective-C APIs NSURLConnection or NSURLSession (although NSURLSession in a background session is not supported). If you use a Cordova plugin that uses other Objective-C APIs, including WKWebView, or accesses sockets directly, AppTunnel with HTTP/S tunneling is not supported.
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 Ivanti server administrator configures Advanced AppTunnel, including installing 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 Ivanti 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), drag and drop, and print capabilities. An Ivanti 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 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 this policy. Your app provides no code to support this policy.
•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. Your app provides no code to support this policy.
The administrator applies the appropriate policies to a set of devices. Sometimes more than one set of policies exists on the Ivanti server for an app if different users require different policies.
Your app uses the AppConnect for iOS Cordova Plugin 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:
•Pasteboard policy API details
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 Ivanti 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.
Data protection
The Ivanti 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 Ivanti client app and the AppConnect library provide this data protection.