Managing dynamic app policies
App security policies are business logic rules that you use to secure iOS and Android apps via the Blue Cedar integration platform. Use the integration platform to inject these policies into apps to secure them post development, before the secured apps are deployed to end users. This process is described in the integration platform documentation.
Static app policies are embedded in the Blue Cedar injectable. If you add or change a static policy, you must re-secure the app with the integration platform and re-deploy the app. See the integration platform documentation for details about these Blue Cedar-defined policies.
Dynamic app policies are managed on the gateway. These rules apply without having to re-secure the app, in response to events on the mobile device or to connections to the gateway. You define dynamic policies on the gateway as configuration profiles or as post-authentication policy rules.
- Client rules: Use configuration profiles on the gateway to define and apply policies that can dynamically modify the policies in the injectable (client). See Using configuration profiles to manage dynamic app policies for details.
Gateway rules: Use post-authentication policy rules to manage incoming connections to the gateway. See Defining policy rules for client events for details.
The following tables compare the dynamic app policy options and describe some use cases. For more details and examples, see the related links.
| Client rules | Gateway rules |
|---|---|
set aaa config-profile | set aaa post-auth-policy-match-rule |
Defined on the gateway | Defined on the gateway |
Evaluated and executed on the client | Evaluated and executed on the gateway |
| Messages displayed on the device | Messages displayed on the device |
Client must be running 3.20.0+ | Client must be running 3.14.0+ |
| Dynamically modify/override static policy options for Browser Configuration, Diagnostics, or Secure Web Stack policies (as applied via the integration platform) | Can allow/deny gateway connections |
| If you want to | Use this kind of rule | What happens |
|---|---|---|
| Block launching a secured app on specific mobile devices or OS versions. | Client must be running 3.20.0+ Define a client rule in a configuration profile on the gateway to:
| When the app starts, the rule evaluates the device type and OS. If those conditions are met, the message displays and the app exits. |
Display a reminder (non-blocking) to upgrade the app with a link to do so. | Client must be running 3.20.0+ Define a client rule in a configuration profile on the gateway to:
| When the app starts, the rule evaluates the app version. If the app is old, the message displays with a link to install the latest version. |
Block launching a secured app | Define a gateway rule in a configuration profile on the gateway to:
| After the connecting client has completed authentication, the gateway rule evaluates the <match> and either allows the connection or denies-with-message. (Note there is no allow-with-message.) |