Page tree
Skip to end of metadata
Go to start of metadata


You can apply application policies to individual iOS and Android apps in your Apperian organization. For an overview of the application policies feature, see Managing Application Policies. For instructions on applying policies, see Apply Policies to an Application

Apperian Policies
Blue Cedar Networks MAP Policies

These policies use Blue Cedar Networks Mobile App Protection (MAP) and are not part of the base product:

If MAP policies are currently disabled for your organization and you are interested in using them, contact your Apperian Account Manager at sales@apperian.com.

Note that the Secure Microtunnel and Client Certificates policies require that you also have the Blue Cedar Networks Atlas Platform (purchased from Blue Cedar Networks) set up in your environment.

"Blue Cedar Networks" was previously called "Mocana."

 

You may want to apply policies to an app that will be distributed to users who are not registered with Apperian and do not need the App Catalog on their device. This includes users who install an app through a Direct Install link, a custom-built catalog, or another external system. Not all of the policies listed below are supported with unregistered users. For more information, see Using Policies with Unregistered Users.

App Usage

The App Usage Policy helps you monitor the adoption and popularity of your enterprise apps. When an app is wrapped with this policy, Apperian tracks each time a user opens the app, brings the app from the background to the foreground, or returns to the app from the lock screen. Usage is counted only once per minute for a particular device. That is, if a user launches or reopens an app multiple times within a minute on the same device, it counts as one use only. If multiple users (on different devices) launch or reopen the same app within a minute, it counts once for each user/device.

You can view app usage information two ways:

  • On the Analytics page: On the Analytics page of an app wrapped with this policy, Apperian displays the Launch Rate of the app. Launch Rate is the percentage of assigned users (users in groups with access to the app) who opened the current version of the app at least once. In the following example, there are 61 users assigned to the current version of the app. Of those users, 3.3% (2 users) have launched the app.



    For instructions on using the Analytics tab, see View Application Analytics.
      

  • App Usage report: The App Usage report lists the usage information tracked for all apps wrapped with the App Usage policy. The report includes the name and ID of the app, date and time of use, and details about the user and device.

For more information on viewing usage information, see Track Application Usage.

The User Experience

This policy does not impact the App Catalog user's experience.

Collect Crash Reports

The Collect Crash Reports policy helps you assess the quality of an iOS or Android application through its crash reports. When an application crashes, a crash report is stored on the device. The report describes the conditions under which the application terminated, and is useful for debugging issues in the application. When an app that is wrapped with the Collect Crash Reports policy crashes, Apperian collects the crash report from the device. (With Android, this happens at the time of the crash; with iOS, it happens the next time the app is opened.) Apperian lists all the reports it has collected for an app on the Crash Reports tab of the app’s details page. From that list, you can view reports and export reports to send to developers for further analysis.

The User Experience

This policy does not impact the App Catalog user's experience. If an app crashes, the user is not notified that a crash report was captured.

Enterprise SSO

The Enterprise SSO policy restricts access to the app using the same authentication method configured for the Admin Portal (either built-in authentication or Single Sign-On). This policy is useful when, for example, an employee's device falls into the wrong hands; the unauthorized individual will not have credentials to log in to Apperian and will therefore be blocked from using the app. Also, if you delete a user's account from Apperian, that user will no longer be able to log in or use any apps protected with the Enterprise SSO policy.
 

The authentication timeout period is configurable and controls Enterprise SSO, Self Updating App, and App Catalog authentication. The default setting is 10 minutes. If you want to modify the authentication timeout period setting for your organization, contact Apperian Customer Support at support@apperian.com.

The User Experience

When the user attempts to open an app that is wrapped with this policy, Apperian prompts the user to authenticate the same way he/she authenticates with the App Catalog. Enterprise SSO uses the same authentication timeout period used for App Catalog authentication. Note that the app must be stopped before the clock for the timeout period starts; if the app is running in the background, the timeout period will not expire and the user will not be prompted to authenticate.

If a user is prompted with Apperian's built-in authentication and enables the Remember Me? option when logging in to the App Catalog, Apperian will remember the user's password during authentication and not prompt the user to re-authenticate when opening an app that is wrapped with the Enterprise SSO policy. Note that if your organization is configured for Single Sign-On, then an option to remember a password will be available only if that option is available through your company's authentication server.

 

Self Updating App

The Self Updating App policy allows an app to "self-update" at launch time by checking for a new version and prompting the user to install it when one is available. If the user is not already authenticated through the App Catalog, Apperian prompts the user to log in before installing the update. When an app is wrapped with the Self Update App policy and you make an update mandatory using Application Update Settings, then users will not be able to open the app until they install the update.
 

 Click here to learn how this policy relates to push notifications and Application Update Settings.

When you update an app through the Admin Portal, you can choose to have users notified of the update with a push notification to their devices. A push notification performs two tasks:

  • Flags the App Catalog icon on the user's Home screen with a notification badge that identifies the number of updates available.
  • Lists the updated app on the Updates tab in the user's App Catalog.

You can also use Application Update Settings to make the update mandatory when users log in to the App Catalog the next time or by a certain date; when an update is mandatory, users cannot use the App Catalog until they install the update.

In the following example, the administrator has chosen to notify users with a push notification and require users to install the update "today" (that is, the next time the user logs in to the App Catalog).

With push notifications and application update settings, Apperian prompts the user to update after launching the App Catalog. The Self Updating App policy is different in that it notifies the user of the update when launching the app, and provides an option to immediately install the update.

The User Experience

When a user opens an app that is wrapped with the Self Updating App policy, Apperian checks if there is a more recent version of the app available. If there is, it prompts the user to install the update. At that point, the user experience differs depending on whether the update is marked as mandatory or optional with Application Update Settings.

Mandatory UpdateOptional Update

When an update is mandatory, the user must either install the update or exit the app.

After launching the app, the user is prompted to install the mandatory update. The user taps Yes and then Install to install the update.

(If the user is not already authenticated through the App Catalog, Apperian prompts the user to log in before installing the update.)

If the user taps Exit, the user is prompted again the next time he/she launches the app. The user cannot use the app until the update is installed.

When an update is optional, or when the date for a mandatory update has not yet been reached, the user can choose whether to install the update. If the user does not install the update, the user can continue to use the currently installed version.

After launching the app, the user is prompted to install the update. The user taps Yes and then Install to install the update.

(If the user is not already authenticated through the App Catalog, Apperian prompts the user to log in before installing the update.)

If the user taps No when prompted to install the update, the app opens normally and the user can continue to use the currently installed version. The Self Updating App policy will prompt a user to install an update only once per day. If the user chooses not to install the update, Apperian will not display the "Update available" prompt again until the user opens the app the next day.

Data Wipe

The Data Wipe policy enables an administrator to delete all user data from an application on a selected device. By applying this policy to an app, you can rest assured that when a device is misplaced or stolen, or in the hands of a user no longer with your organization, you can easily and remotely remove proprietary data from the device.

Data Deleted from an iOS DeviceData Deleted from an Android Device

When Apperian deletes application data from an iOS device, it quits the app (which clears any in-memory data associated with the app) and permanently deletes the following data from local storage on disk. Apperian does not delete application data from external storage, such as an SD card.

  • Preferences stored in the user defaults system
  • Keychain items associated with the app
  • HTTP cookies associated with the app
  • Contents of the Documents folder for the app
  • The Cache folder for the app

When Apperian deletes application data from an Android device, it quits the app (which clears any in-memory data associated with the app) and permanently deletes the following data from local storage on disk. Apperian does not delete application data from external storage, such as an SD card.

  • Contents of the application's directory
  • Shared preferences associated with the app
  • Databases created for the app
  • The Cache folder for the app
     
Apperian does not delete Native Development Kit (NDK) linkage files. Note that most users are not aware of these files.

The User Experience

When an administrator marks application data to be cleared from a user's device, Apperian will delete the data the next time it evaluates policies for the app. Apperian evaluates policies when a user:

  • Opens an app
  • Brings an app from the background to the foreground
  • Returns to an app from the lock screen

When Apperian deletes the application data from the device, it displays the following message and quits the app.

The user can reopen the app and continue to use it, but will no longer have access to any previously saved data.

Runtime Integrity Check

The Runtime Integrity Check policy verifies the integrity of the application by calculating its checksum at runtime and comparing it with the checksum stored in the Apperian database. Apperian calculates a checksum each time a new version of an app is added to Apperian. If the checksums do not match during the Runtime Integrity Check, the app will not open and Apperian will display a message advising the user to reinstall the app because it may not be safe to run. This ensures that a user cannot run an app that was downloaded or installed incorrectly, or compromised in some way after it was installed.

To calculate an application's checksum, Apperian uses the SHA-256 cryptographic hash function.

The User Experience

When a user attempts to open an app that is wrapped with the Runtime Integrity Check policy, Apperian calculates its checksum and compares it with the checksum stored in the database for that same version of the app. If the checksums match, the app opens (as long as opening is not blocked due to any other policy checks). If the checksums do not match, Apperian displays the following message advising the user to reinstall the app:

Data Protection Enforcement (for iOS apps only)

This policy works only on devices running iOS 8 or higher.

The Data Protection Enforcement policy ensures that an application can be used on a device only when its content is secured using Apple's iOS Data Protection. iOS Data Protection is a built-in capability that encrypts data stored on an iOS device whenever the device is locked. The encrypted data is automatically decrypted when the device is unlocked, making the process seamless for both the application and the user. Note that iOS uses an AES (Advanced Encryption Standard) 256-bit crypto engine, which has been validated for compliance with U.S. Federal Information Processing Standards (FIPS) 140-2 Level 1.  

In order for built-in iOS Data Protection to work, the device must be running iOS 8 or higher and have a passcode enabled. In addition, apps using this policy need to have the Data Protection entitlement enabled. Note that you can still use this policy even if your app was not not built with the Data Protection entitlement enabled. When you sign the app with the Admin Portal it automatically enables the Data Protection entitlement in the app as long as you sign with a distribution provisioning profile that has the Data Protection (Complete Protection) entitlement enabled.

Even if an app was built with the Data Protection entitlement enabled, you must still sign it with a provisioning profile that has the Data Protection (Complete Protection) entitlement enabled. This is a standard iOS requirement: apps must be signed with provisioning profiles that have entitlements that match the app, otherwise users will not be able to install the app onto their devices.

When an app is wrapped with this policy, the user is blocked from running the app unless all the following conditions are met: 

  • The app and the distribution provisioning profile it was signed with have the Data Protection (Complete Protection) entitlement enabled.
  • The device is running iOS 8 or higher. 
  • A passcode is enabled on the device. 
      
 Click here here for more information on enabling the Data Protection entitlement...

An entitlement is a single right granted to an app that gives it additional permissions beyond what it would ordinarily have. There are different terms used to enable entitlements depending on where you are working. When building an app in Xcode, a developer turns capabilities ON or OFF to grant entitlements. When creating an App ID in the Apple Developer Portal, you enable app services to identify the entitlements for the app or apps associated with that App ID. Some app services are enabled by default for an explicit App ID that exactly matches the bundle ID. When you create a distribution provisioning profile, you associate it with an App ID; this is what determines which entitlements (or app services) are enabled for the provisioning profile. For more information on adding capabilities in Xcode, see the iOS Developer Library. For more information on enabling app services when creating an App ID, see Manage App Identifiers.

When an app is wrapped with the Data Protection Enforcement policy, it is important that it is signed with a provisioning profile associated with an App ID that has the Data Protection (with Complete Protection Sharing and Permissions) service enabled.  

For more information on entitlements, see App Extensions and Entitlements.

Even if data encryption is not a requirement for an app, you can apply this policy simply to ensure that users run the app only on devices that are secured with a passcode.

The User Experience

When a user attempts to open an iOS app that is wrapped with the Data Protection Enforcement policy, Apperian checks that the app and its distribution provisioning profile have the Data Protection (Complete Protection) entitlement enabled, the device is running iOS 8 or higher, and a passcode is enabled on the device. If all these conditions are met, the app opens. If any of these conditions are not met, Apperian displays the following message and the app closes:

Jailbreak/Root Protection

The Jailbreak/Root Protection policy blocks a user from running an app when the user's device has been compromised by jailbreaking (iOS) or rooting (Android). Jailbreaking/rooting exposes a device to security breaches; malicious software can take advantage of this exposure, leaving any app on the device vulnerable to viruses and rogue apps.

The User Experience

When the user attempts to launch the app, Apperian checks if the device has been jailbroken/rooted. If it has been, an error message displays and the app closes. If the device has not been jailbroken/rooted, the app launches normally. 

App Expiration

The App Expiration policy allows you to define a range of dates within which users can use an application. For example, if you hire a contractor for 30 days, you can use this policy to set a 30-day expiration date on each of the apps provisioned to that contractor; when the contract terminates, so does the contractor's ability to use your company's enterprise apps. A user will be able to use the app from 12:00:01 AM UTC on the start date until 11:59:59 PM UTC on the end date.

The User Experience

When a user attempts to launch the app within the access period, the app opens normally. When the user attempts to launch the app before the start date or after the end date of the access period, a message appears and the app closes.

The message shown in the image above is the default message displayed when a user attempts to launch an app outside of the application access period. You can modify this message on the Policies tab when you apply the policy to an app. If you modify the message and want the default user message to be displayed again, click the Revert to Default Message link.

Open Web Page

The Open Web Page policy opens a browser window to a specified web page after the user opens the app a predefined number of times. Use this policy, for example, to administer a survey to collect feedback about an app after a user has opened it 10 times. 

Opening an app includes launching the app from the home screen, bringing it from the background to the foreground, or returning to it from the lock screen. Note, however, that Apperian evaluates this policy only once per minute for a particular device. Therefore, if a user launches or reopens an app multiple times within a minute on the same device, it will count as opening the app only once. 

The User Experience

After the user opens the app the predefined number of times, Apperian automatically opens a browser window to the specified web page. When the user taps the X button, it closes the browser window, and the user can continue working in the app. 

Apple On-Demand VPN Policy (for iOS apps only)

This policy is not available by default. If you are interested in applying it to any of your iOS applications, contact support@apperian.com.

This policy works only on devices running iOS 8 or higher.

You cannot wrap an app with both this and the Pulse Secure VPN or Secure Microtunnel policy.

The Apple On-Demand VPN policy ensures that an app is used on a secure network by adding a VPN configuration on the device that only that app will use, and then requiring the user to log in to that VPN in order to use the app. When the user closes the app or sends it to the background, the VPN disconnects and the user is not prompted to reconnect until the app is opened again or brought to the foreground.

When you wrap an app with this policy, you define the VPN configuration profile for that specific app, and can therefore use different VPN profiles depending on the app. For convenience, you can set up a default VPN configuration on the Policies page so that if you want to use the same VPN configuration profile with multiple apps, you will not need to enter the profile information when you wrap each of those apps with the Apple On-Demand VPN policy.

The first time a user opens an app wrapped with this policy, the app uses Apple's Personal VPN technology to add a VPN configuration to the device. The user is prompted for permission to add the VPN configuration, as shown in The User Experience below. Once added, the VPN configuration is listed on the Settings->General->VPN page of the device. In the following example, the user has installed two apps that are wrapped with the Apple On-Demand VPN policy (Actions and Directory); each app has a separate Personal VPN configuration listed on the VPN page. When either the Actions or Directory app is in use, the status of that app's Personal VPN changes to Connected. 


In order for the Apple On-Demand VPN policy to work, the device must be running iOS 8 or higher. In addition, apps using this policy need to have the Personal VPN entitlement enabled. Note that you can still use this policy even if your app was not not built with the Personal VPN enabled. When you sign the app with EASE it automatically enables the Personal VPN entitlement in the app as long as you sign it with a distribution provisioning profile that has the Personal VPN entitlement enabled.

Even if an app was built with the Personal VPN entitlement enabled, you must still sign it with a provisioning profile that has the Personal VPN entitlement enabled. This is a standard iOS requirement: apps must be signed with provisioning profiles that have entitlements that match the app, otherwise users will not be able to install the app onto their devices.

 

 Click here here for more information on enabling the Personal VPN entitlement for a provisioning profile...

An entitlement is a single right granted to an app that gives it additional permissions beyond what it would ordinarily have. There are different terms used to enable entitlements depending on where you are working. When creating an App ID in the Apple Developer Portal, you enable app services to identify the entitlements for the app or apps associated with that App ID. Some app services are enabled by default for an explicit App ID that exactly matches the bundle ID. When you create a distribution provisioning profile, you associate it with an App ID; this is what determines which entitlements (or app services) are enabled for the provisioning profile. For more information on enabling app services when creating an App ID, see Manage App Identifiers.

When an app is wrapped with the Apple On-Demand VPN policy, it is important that it is signed with a provisioning profile associated with an App ID that has the Personal VPN service enabled. Note that it must be an explicit App ID; Apple does not allow you to enable the Personal VPN service for a wildcard App ID.

For more information on entitlements, see App Extensions and Entitlements.

The User Experience

If a user attempts to open an app wrapped with the Apple On-Demand VPN policy on a device running iOS 7, Apperian displays the following message and the app closes:

The first time a user attempts to open an app wrapped with the Apple On-Demand VPN policy on a device running iOS 8 or higher, the user is prompted to allow the app to add a VPN configuration. If the user taps Don't Allow, the app closes. If the user taps Allow, the user is then prompted to:

  1. (If a passcode is enabled on the device) Enter the device passcode or Touch ID.
  2. Enter valid VPN credentials to authenticate the user. 

Once the user has entered valid VPN credentials and connected to the VPN, the app opens. Adding the VPN configuration occurs the first time the app is opened only. After that, the user is immediately prompted to enter VPN credentials whenever he/she launches the app or brings it to the foreground. 

Pulse Secure VPN (for iOS apps only)

This policy is not available by default. If you are interested in applying it to any of your iOS applications, contact support@apperian.com.

This policy works on devices running iOS 8 or higher.

The Pulse Secure VPN policy establishes a pre-configured Pulse Secure® VPN connection when the user opens the application. Use this policy to provide apps with access to resources in your secure corporate network. 

To use this policy, you need access to a Pulse Connect Secure VPN gateway. Optionally, you can configure a default VPN connection URL for the policy on the Policies page. When you apply the policy to a specific app you can use the default VPN connection URL (if you configured one) or specify a different URL; this enables you to direct users to different VPN gateways for different applications as needed.

Using This Policy With Other Application Policies

You cannot combine this policy with the Apple On-Demand VPN policy or Secure Microtunnel VPN policy.

If you apply this policy along with any of the following Apperian policies, you should configure your Pulse Connect Secure VPN gateway to allow access to the EASE web server:
 

  • App Usage
  • Collect Crash Reports
  • Enterprise SSO
  • Self Updating App
  • Data Wipe
  • App Expiration
  • Open Web Page
  • App Password
     

If your VPN gateway cannot access the Apperian server, the policy wrapper will communicate with the server only when the application is not connected to the VPN—that is, when the application is first opened or when it is re-opened after the user forced quit out of it. When the policy wrapper cannot connect to the server, it uses whatever policy settings were last retrieved. This means that if an administrator makes a dynamic change to the application's policies, such as modifying the access period for the App Expiration policy or adding/removing a policy, those changes will not be applied until Apperian is able to again connect to the server (that is, when the app is re-opened after the user had forced quit out of it).

For instructions on configuring your VPN gateway, see Configure Pulse Connect Secure VPN Access to the Apperian Server.

The User Experience

If a user attempts to open an app wrapped with the Pulse Secure VPN policy on a device running iOS 7, Apperian displays the following message and the app closes:

When an app that is wrapped with the Pulse Secure VPN policy, the experience for connecting with the VPN will vary depending on how the Pulse Connect Secure VPN gateway is configured. In the following example, the user is prompted to enter VPN login credentials. Once the user has entered those credentials, the VPN connection is established and the app opens. 

App Password

This policy can be used only on devices running iOS 8 or higher.

The App Password policy protects the app by requiring the user to enter a user-set password before opening the app. The user's password is securely stored on the device, and is not transmitted back to the server. When you apply the policy, you can set password requirements to define the minimum number of characters and other complexity criteria. Note that if you make changes to the password requirements, those changes will not affect users who have already installed an app with this policy applied unless they update the app and attempt to change their password.

The User Experience

The first time the user launches the app, the user is prompted to define a password that meets the criteria that you established when setting the policy requirements. Anytime the app is re-opened or brought to the foreground, the user will be prompted by the Password Verification screen and required to re-enter the password. From the Password Verification screen, users also have the option to change their password by tapping the Change Password button.

If a user enters the wrong password, they will see the message below and the app will close.

If a user forgets the app password, he or she can uninstall and reinstall the application to reset the password.

Check Location Services (for iOS apps only)

The Check Location Services policy checks that Location Services are activated under the device's privacy controls, and also that the application is set to allow access to the device's location. If Location Services for the device is turned Off and/or Location Access for the app is set to Never, an alert appears when a user opens the app and prompts them to enable location services. 

Apply this policy to applications that use location services to ensure that your users have the optimal user experience and can take full advantage of the application's functionality.

You may not want to apply this policy to an app that is already programmed to prompt the user to enable location services as this will result in the user seeing two separate alerts.

The following options are available:

  • Mandatory: The alert appears every time a user opens the app, and users can't use the app until they enable location services on their device.
  • Voluntary: The alert appears, but users can continue using the app without enabling location services. You can set the number of minutes that should elapse before displaying the alert again after a user dismisses it. If you enter 0, the alert appears every time a user opens the app. 
  • No Alert: The alert never appears, but location services data is recorded for the Location Services Status report.

The Location Services Status report lists each check performed by the Check Location Services policy where the status is different than the previous status. For more information, see Running Reports.

The User Experience

If Location Services are not enabled for the device and/or Location Access is not allowed for the app, the following messages appear when the user opens the app:

Mandatory

Voluntary

Users can tap Settings to enable the necessary iOS options, tap Later to continue using the app without changing any settings, or close the app and then open iOS Settings manually. For more information about enabling Location Services on a user's device, see Apple's Turn Location Services and GPS on or off on your iPhone, iPad, or iPod touch support article.

Secure Microtunnel

This policy relies on a connection with an Atlas gateway, and you must therefore have the Blue Cedar Networks Atlas Platform (purchased from Blue Cedar Networks) set up in your environment. For more information on the Atlas Platform, see the Blue Cedar Networks web site.

The Secure Microtunnel policy establishes a secure VPN connection between the application and your enterprise Atlas gateway. Only the wrapped app has access to the connection, thus preventing rogue apps and malware from spreading from the user's device to the rest of your corporate network. 

Secure Microtunnel is different from traditional mobile VPNs that are limited to one connection per device. Secure Microtunnel establishes a connection on a per-app basis and has no per-device limits. For example, on the same device, a user can run one app that connects with one Atlas gateway and another app that connects with a different Atlas gateway—at the same time.

The User Experience

When users launch the app for the first time, they are prompted to enter their Atlas gateway credentials (one-time certificate enrollment). 

The user experience is also impacted by these settings that you can configure when you create a VPN connection :

  • Offline Mode: When you create a VPN connection for the Secure Microtunnel policy, you can select the Allow app to run offline after initial enrollment option to enable Offline Mode. Offline mode allows users to access apps with this policy applied to them even when their devices cannot connect to the Atlas gateway.

     Click here for more on Offline Mode...

    When Offline Mode is enabled with the Secure Microtunnel policy, users can run the app even when they cannot connect to the Atlas gateway (for example when there is no cellular or wi-fi coverage, or when a device is in Airplane Mode). When Offline Mode is not enabled, users can run the app only when they can connect to the gateway. For details on the user's experience with and without this setting enabled, see the following table.

    When Offline Mode Is Enabled
    If the app...Then the app...
    Cannot connect to the Atlas gateway, and the user has not previously enrolled with Atlas.Terminates.
    Cannot connect to the Atlas gateway, but the user has previously enrolled with Atlas.Continues to run and attempts to connect to Atlas in the background.
    Connects to the Atlas gateway, but then loses connectivity.Continues to run and attempts to connect to Atlas in the background.
    When Offline Mode Is NOT Enabled
    If the app...Then the app...
    Cannot connect to the Atlas gateway (regardless of whether the user previously enrolled with Atlas).Terminates.
    Connects to the Atlas gateway, but then loses connectivity.The app continually tries to reconnect, and cannot be used in the meantime.

     

  • Authentication Group: When you create a VPN connection, you can optionally enter the name of a specific Atlas-defined authentication group that is configured on the Atlas gateway. Users who attempt to connect and are not part of the group will see an "unable to connect" message. For more on configuring authentication groups, see your Atlas documentation.

Local App Authentication

The Local App Authentication policy protects the app by requiring the user to enter a passphrase or provide a fingerprint when launching the app. The user's passphrase is securely stored on the device, and is not transmitted back to the server. Passphrase options allow you to define the criteria of the user-set passphrase. For example, you can specify minimum characters and complexity, and require the user to change the passphrase after a set interval of time. You can also specify whether the user is required to re-authenticate after a set number of minutes of inactivity. For a list of the passphrase criteria and options, see Local App Authentication Policy Options.

Local App Authentication using a passphrase is supported on all platforms supported by Blue Cedar Networks MAP (see Supported Platforms). Authentication using a fingerprint is supported only on devices that allow for fingerprint scanning.

The User Experience

The first time the user launches the app, the user is prompted to define a passcode that meets the criteria that you established by setting the policy options. On subsequent attempts to open the app after it was closed or inactive for the amount of time set for expiration timeout, the user is prompted to re-authenticate to open the app. If fingerprint authentication was enabled for the policy, then the user is prompted to either provide a valid fingerprint or tap Cancel to then enter the valid passcode. If fingerprint authentication fails three times in a row, the Enter Your Passcode screen displays. If fingerprint authentication is not enabled or supported on the device, the user is taken directly to the Enter Your Passcode screen. 

There is no limit to the number of failed authentication attempts, but the user will be unable to open the app until either a valid fingerprint or passcode is provided.

Encrypted Data at Rest

The Encrypted DAR policy encrypts each piece of application data before saving it on the mobile device, and then decrypts it when it is needed by the app. This policy helps to shield application data from malware, rogue apps, and hackers who attack the device memory.

The User Experience

If a user creates a file with the wrapped app and then tries to open that file in another app, the file will either not open or will open and display unreadable encrypted data.

App Installations and Updates: Special Use Cases

When the Encrypted Data at Rest policy is applied to an application, application data may be removed from the user's device in certain app installation and update use cases. 

Use CaseWhat happens to the app's data?
User uninstalls the appAll data associated with the app is deleted from the device.

User replaces a protected version of an app with an unprotected version

 

When a user replaces an app that uses the Encrypted Data at Rest policy with a version of the app that does not, the app's data that is stored on the device is still encrypted but the encryption key is deleted and there is no way to decrypt the app's data. Users should sync their encrypted app data before upgrading to an unprotected version of an app.

User replaced an unprotected version of an app with a protected version

When a user replaces an app that did not use the Encrypted Data at Rest policy with a version that does, all new data generated by the app will be encrypted and existing data will remain unencrypted.
User replaces a protected version of an app with another protected versionWhen a user replaces an app that uses the Encrypted Data at Rest policy with a new version of that app that also uses the policy, all existing data is preserved and can still be decrypted.
User updates a protected version of an Android app that previously saved files to the device's SD card

When a user replaces an Android app that uses the Encrypted Data at Rest policy with a new version, all files stored on the SD card are unreadable.

If you plan to update from an unprotected app to a protected app, or a protected app to an unprotected app, Apperian recommends that you ask your users to delete the old version before installing the update. This avoids data loss or unexpected behavior resulting from a mix of encrypted and un-encrypted data files.

Data Sharing

The Data Sharing policy prevents corporate data leakage by prohibiting the user from copying and pasting data between an app protected with this policy and other apps that are not protected with this policy.

The User Experience

When users copy text, images, or other data in an app wrapped with the Data Sharing policy, they can paste this data only into other apps wrapped with the Data Sharing policy. The reverse is also true: when users copy data from apps that are not wrapped with the Data Sharing policy, they cannot paste that data into apps that are wrapped with Data Sharing.

When a user attempts to perform a paste function that is blocked, nothing happens; no data is pasted and no error appears. 

Client Certificates

This policy requires that you have the Blue Cedar Networks Atlas Platform (purchased from Blue Cedar Networks) set up in your environment. For more information on the Atlas Platform, see the Blue Cedar Networks web site.

If you have an application that accesses sites that require the user to authenticate, you can use this policy to eliminate all or some of those additional logins. The Client Certificates policy works with the Blue Cedar Networks Atlas Platform to provide a client certificate from your Atlas Gateway server and store it on the user's device. The application can then present this certificate to sites it needs to access, thereby allowing the user to skip additional authentication steps and have a smoother mobile experience.

When you configure the policy, you can specify a White List and White List Exceptions to define which sites are presented with client certificates and which are not. If a site is not whitelisted but does require authentication, the user will still be prompted to re-authenticate.

Server Certificates

The Server Certificates policy lets you upload one or more trusted SSL (X.509) certificates that the app can then use when establishing an SSL connection with the servers it needs to access. Similar to how browsers have a pre-installed list of trusted SSL certificates, this policy lets you pre-install a list of certificates on a per-app basis. 

When you configure this policy on the Policies settings page, you should upload all the root certificates and intermediate CA certificates your apps will need to trust accessed site(s). Then when you apply the policy to a specific app, you can select from the list of uploaded certificates whichever certificates will be needed by that app.

The User Experience

This policy impacts the user experience by eliminating the need for the user to individually trust sites that the wrapped app needs to access. 

The User Experience

This policy impacts the user experience by eliminating the need for the user to authenticate again with all or some of the sites that the wrapped app needs to access. 

  • No labels