This page describes the Blue Cedar Networks (BCN) policies. These policies use Blue Cedar Networks Mobile App Protection (MAP) and are not part of the base product.
The Blue Cedar Network policies are optional and are not part of the standard Apperian platform subscription. Please contact Customer Support or your Account Representative for pricing and usage information.
As of February 7, 2018, we have removed the ability for customers to configure BCN policies directly in the Apperian Admin Portal. The functionality of BCN policies is not affected. Contact Customer Support if you need to make any BCN policy configuration changes.
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 can be configured when a VPN connection is created:
Offline Mode: With 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 a VPN connection is created, 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, seeLocal App Authentication Policy Options below.
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 Case||What happens to the app's data?|
|User uninstalls the app||All 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 version||When 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.
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.
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.
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 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 authenticate again with all or some of the sites that the wrapped app needs to access.
- No labels