Best practices using the AppConnect for iOS Cordova Plugin
The following are best practices for developing secure enterprise apps:
•Display authorization status in the home screen
•Allow the user to enter credentials manually
•Limit the size of configuration data from the Ivanti server
•Consider limitations when using the iOS simulator
•Enable the AppConnect library to blur screens when the app becomes inactive
•Do not put secure data in the app bundle
•Indicate to the user that the app is initializing
•Provide documentation about your app to the Ivanti server administrator
Display authorization status in the home screen
When an app becomes unauthorized or retires, the AppConnect Cordova Plugin AppConnectCordova.authState() method returns UNAUTHORIZED or RETIRED. Additionally, the AppConnectCordova.authMessage() method returns a string that explains to the device user why the app is unauthorized or retired. The string sometimes also explains what the device user can do to make the app authorized again.
The app should display the AppConnectCordova.authMessage() string. However, consider that since the app is now unauthorized or retired, the app must exit its secure functionality. Therefore, the best user experience is to display the string in a home view that never contains secure information.
The following alternatives for displaying the AppConnectCordova.authMessage() string are not recommended:
•Do not display the string on top of the current view. Beneath the message, the current view can still have secure information visible.
•Do not use the AppConnectCordova.displayMessage() method. This method does not match the look of your app.
•Do not exit the app without displaying the string.
Allow the user to enter credentials manually
Always provide a way for a user to enter login credentials manually in your app. Provide this user interface even if you are receiving login credentials in app-specific configuration information from the AppConnect library.
As described in Configuration specific to the app, an Ivanti server administrator can set up configuration information for your app on the server. Your app receives the information using the AppConnect Cordova interfaces. This information can include authentication credentials, such as username, password and certificates, for a corporate service. Because the app receives the information, the device user does not have to enter the information.
However, if the credentials change, the amount of time for the change to reach your application can vary. Some variables that impact this notification include:
•the app checkin interval that the administrator configured on the Ivanti server. This value is the maximum number of minutes until devices running AppConnect apps receive updates of their AppConnect policies and app-specific configurations.
•whether the device has network coverage.
Therefore, providing changes to devices is not a real-time process and can take up to several hours. Therefore, if the corporate service rejects the credentials, provide a way for the user to enter the credentials manually.
Limit the size of configuration data from the Ivanti server
Do not design your app to use large amounts of configuration data from the Ivanti server.
As described in Configuration specific to the app, a server administrator can set up configuration information for your app on the server. Your app receives the information using the AppConnect Cordova Plugin. Use this capability only for short strings and options, such as server addresses, authentication credentials, and certificates.
Do not use it for larger data items, such as documents, large blocks of HTML, or images. For large data items, use a web service to deliver the items. Use AppConnect configuration only to provide the URL for the web service.
Although no precise upper limit is defined for an item configured on the Ivanti server, a large item can impact server performance. It can also slow connectivity between the Ivanti server and the Ivanti client app for iOS app. A very large item can possibly cause the communication protocol between the Ivanti server and the Ivanti client app to fail entirely.
Consider limitations when using the iOS simulator
To fully test an AppConnect app, debug on a tethered device using Xcode, as you would for any other app. On a device, your testing includes the Ivanti client app app, which is necessary for the complete flow of data from the Ivanti server to your app.
You can do initial functionality testing in the iOS simulator in Xcode. However, when using the AppConnect Cordova Plugin in the iOS simulator, the plugin interfaces behave as follows:
•AppConnectCordova.authState() returns AUTHORIZED
•AppConnectCordova.config() returns no entries
•AppConnectCordova.pasteboard() returns AUTHORIZED
•AppConnectCordova.openInPolicy() returns AUTHORIZED
•AppConnectCordova.printPolicy() returns AUTHORIZED
This behavior is necessary because no simulator version of the Ivanti client app is available, and the Ivanti client app is necessary for your app to receive AppConnect Cordova Plugin events. Without the events, the app’s authorization status cannot change to AUTHORIZED, and your app cannot execute its logic that accesses its secure data and functionality. The AppConnect Cordova Plugin’s special simulator behavior solves this problem, allowing you to use the iOS simulator to test your app’s functionality. You cannot, however, use the simulator to test handling events from the AppConnect Cordova Plugin.
Enable the AppConnect library to blur screens when the app becomes inactive
AppConnect 4.0 for iOS added support for blurring screens when the app becomes inactive. Use this capability of the AppConnect library, as described in Enable screen blurring. If your app provided its own screen blurring, remove that code. By using the AppConnect library’s screen blurring capability, all AppConnect apps behave consistently.
Do not put secure data in the app bundle
Files that you package in your app bundle are not encrypted files. Also, files packaged with an app cannot be modified at runtime. Therefore, these files are not secure. Therefore, include only non-sensitive data in the app bundle.
Indicate to the user that the app is initializing
Indicate in the user interface that the app is initializing if the app requires the AppConnectCordova JavaScript interfaces to determine what to do. For example, use an activity indicator (spinner). Remove the activity indicator after the app receives the 'appconnect.isReady' event.
One reason this indication is important involves when to display sensitive data. Do not show any sensitive data until the AppConnect library is ready, because until that time, the app cannot determine whether it is authorized. Only an authorized app should show sensitive data.
Disallow custom keyboard use
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. This behavior has potential for harmful data loss. Therefore, code your app to not allow custom keyboard use. Ivanti server administrators can control whether your app can use a custom keyboard by specifying a key-value pair (MI_AC_IOS_ALLOW_CUSTOM_KEYBOARDS) on your app’s configuration. Your app can control whether custom keyboards are allowed if the server administrator has enabled the key-value pair.
Provide documentation about your app to the Ivanti server administrator
Whether your app is an in-house app or is available from the Apple App Store, an Ivanti server administrator configures the server with information about your app. Provide the server administrator documentation that specifies:
•whether your app enforces the print policy.
The server administrator needs to know whether allowing or not allowing your app to use print capabilities has impact on your app’s behavior.
•whether your app handles the pasteboard policy.
The server administrator needs to know whether allowing or not allowing your app to copy content to the pasteboard has impact on your app’s behavior.
Although the AppConnect library enforces the pasteboard policy, inform the Ivanti server administrator if your app enables or disables any special user interfaces depending on the policy status. This documentation allows the administrator to better understand your app’s expected behavior.
•whether your app handles the Open In policy.
Although the AppConnect library enforces the Open In policy, inform the Ivanti server administrator if your app enables or disables any special user interfaces depending on the policy status. This documentation allows the administrator to better understand your app’s expected behavior.
Also, if you have a recommended list of whitelisted apps, document their bundle IDs.
•the app-specific configuration key-value pairs.
Provide a list of the key-value pairs that your app expects to receive through the AppConnect API. Provide each key’s default value if it has one. Specify if the value should default to the device’s user’s LDAP user ID or password.
•AppTunnel information
If your app expects to interact with internal servers using AppTunnel, specify whether your app expects to work with AppConnect with HTTP/S tunneling, or whether it requires AppConnect with TCP tunneling.
Also, provide information about the internal servers.
For example:
| - | Explain the type of servers your app interacts with, such as, for example, SharePoint servers. |
| - | Specify if your app expects to receive internal servers’ host names using the app-specific configuration API. |
| - | Specify if your app expects to be able to interact with all internal servers. |
| - | If you are an in-house app developer, provide the host names of the internal servers that your app interacts with. Also, provide the port number on each internal server that the app connects to. |
•HTTPS connections that your app makes that use certificate authentication to an enterprise service.
For in-house app developers, provide the URLs of the enterprise services that use certificate authentication.
If your app receives these URLs through app-specific configuration, make sure you listed the URLs in the app-specific configuration key-value pair documentation.
•If your app is a dual-mode app, provide dual-mode app behavior.
| - | Provide expected behavior and features in AppConnect mode versus non-AppConnect mode. |
| - | If your app allows the device user to switch between AppConnect mode and non-AppConnect mode, document what the device user must do. |
• Whether your app uses the AppConnect-provided screen blurring capability
Server administrators need to know whether your app will be impacted if they disable screen blurring for your app.
•Whether your app includes the MI_AC_DISABLE_SCHEME_BLOCKING key set to YES in its Info.plist.