Skip to content

Defining Client Policies and Feature Restrictions

Mobile Services uses the Mobile Settings Exchange feature to manage and exchange general settings between a mobile client and the server. Settings include client policies, JSON storage, user registrations, and service keys.

  1. In SAP mobile service cockpit, select Mobile Applications > Native/MDK or SAP Mobile Cards.

  2. Select an application, then select Mobile Settings Exchange under Assigned Features (or add it first).

  3. On Mobile Settings Exchange, select a tab to make changes. See corresponding sections in Guides for details.

  4. Select Save.

Defining Client Password Policy

Define the client password policy used to unlock the secure store, for the selected application. Application developers must add code to enforce the policy to the secure store used by the application. An administrator enters the application password policy used to unlock the secure store during application initialization.

The client password policy applies only to the application password that unlocks the secure store during application initialization; it affects neither SAP Mobile Services security profiles nor the back-end security systems with which it integrates. Password policies for back-end security systems are administered by customer information technology departments using native security administration tools.

  1. In SAP mobile service cockpit, select Mobile Applications > Native/MDK or SAP Mobile Cards.

  2. Select an application, then select Mobile Settings Exchange under Assigned Features.

  3. On Client Configuration, under Passcode Policy, select Enable Passcode Policy, and enter:

    Property Default Description
    Expiration Time Frame Days 0 The number of days a password remains valid. The default value, 0, means the password never expires.
    Minimum Length 8 The minimum password length.
    Retry Limit 20 The number of retries allowed when entering an incorrect password. After this number of retries, the client is locked out, the secure store and all its contents are permanently deleted, the application is unusable, and encrypted application data is inaccessible.
    Minimum Unique Characters 0 The minimum number of unique characters required in the password.
    Lock Timeout 0 The number of seconds the secure store remains unlocked within an application, before the user must reenter his or her default password to continue using the application (similar to a screen-saver feature).
    No Passcode Required Disabled If enabled, a default password can be generated by the secure store; from the user's point of view, this turns off the password.

    Note that if the default passcode is set, the SDK automatically generates a default passcode to encrypt the secure store. The default passcode is encrypted by an operating system-level encryption mechanism and stored securely.
    Biometric Authentication Allowed Disabled If enabled, it allows the use of native biometric techniques to unlock the app.
    Upper Case Character Required Disabled If enabled, the password must include uppercase letters.
    Lower Case Character Required Disabled If enabled, the password must include lowercase letters.
    Special Character Required Disabled If enabled, the password must include special characters.
    Digits Required Disabled If enabled, the password must include digits.
  4. Select Save.

Defining Application Management Policies

Define application management policies from SAP mobile service cockpit for the selected app, such as whether to detect device compliance; restrict users from cutting, copying, and pasting information between apps; and restrict iOS users from restricting printing data or opening URLs. These policies can provide some additional security. By default the options are not enabled.

  1. In SAP mobile service cockpit, select Mobile Applications > Native/MDK or SAP Mobile Cards.

  2. Select an application, then select Mobile Settings Exchange under Assigned Features (or add it first).

  3. On Client Configuration, under Application Management Policies, enable or disable the policies. Note that some options may not appear for some apps in Software as a Service or Platform as a Service environments.

  4. For Device Compliance Detection, select or deselect the checkbox to enable or disable the restriction. When enabled, mobile services checks whether the device is jailbroken (iOS) or rooted (Android). The option is not enabled by default. For more information see Defining Device Compliance Policy.

  5. For Restrict Cut, Copy and Paste between Apps, select or deselect the checkbox to enable or disable the restriction. This feature defines whether users can cut, copy, and paste information between apps in SAP mobile service cockpit. When enabled, this can provide some additional security by limiting the exchange of information between apps. The option is not enabled by default.

  6. For Restrict Print Data (For iOS Only), select or deselect the checkbox to enable or disable the restriction for the iOS app. When enabled, a user is prevented from printing data from the application. This would be useful in a test scenario or when data is highly sensitive. The option is not enabled by default.

For Restrict Opening URLs (For iOS Only), select or deselect the checkbox to enable or disable the restriction for the iOS app. When enabled, a user is prevented from access certain URLs. This would be useful when an URL can only be accessed by certain roles. The option is not enabled by default.

  1. Select Save.

Defining Device Compliance Policy

Define whether mobile services should check for client device compliance. If enabled, mobile services checks whether devices have been jailbroken or rooted.

Jailbreaking is a term used for iOS devices, while rooting is a term used for Android devices. Jailbreaking or rooting a device refers to the process of removing software restrictions imposed by the manufacturer or carrier on the device, allowing the user to access the device’s file system and install unauthorized apps, among other things. However, jailbreaking or rooting a device can also make it more vulnerable to security threats and malware.

This feature provides some additional security by detecting compromised devices. The option is not enabled by default. Once enabled, mobile services checks device compliance and reports status. Status options include:

  • Compliant - the device has undergone compliance detection, and was found to be neither jailbroken or rooted.

  • Compromised - the device has undergone compliance detection, and was found to be jailbroken or rooted. The compromised device status is also reported as an Error in the Event Log (use the Mobile Device Security filter). Once the compliance problem is fixed and rechecked, the status changes.

  • Unknown - Unknown - the device has not undergone compliance detection, so its status is not yet known.

When compromised devices are detected, they are reported as a Mobile Device Security event, and appear on the User Registrations tab and in the Event Log.

  1. In SAP mobile service cockpit, select Mobile Applications > Native/MDK or SAP Mobile Cards.

  2. Select an application, then select Mobile Settings Exchange under Assigned Features (or add it first).

  3. On Client Configuration, under Compliance Policy, select Enable Compliance Detection to enable the restriction.

  4. When the policy is enabled, mobile services SDK regularly checks for the latest security policy settings. If compliance check policy is enabled, the SDK initiates the check and reports the results to the server if it fails. If a compromised device is detected, a Mobile Device Security event is created. You can:

  5. Optionally you can turn compliance detection off, if needed. -->

Defining Lock and Wipe Policy

Define the policy for locking and wiping the application running on a device.

(Native/MDK, SAP Build Apps, and SAP Mobile Cards) The app must include SDK logic to support locking and wiping policies. For example, the developer may implement locking and/or wiping for when a device is lost or stolen, or a user wants to delete data stored locally.

From SAP mobile service cockpit, the administrator can create locking and wiping policies for the app:

  • Locking refers to locking the app on the device client. Once the app is locked, the user can unlock it by connecting to the server and authenticating. All existing data (in particular the offline OData store) remains on the device. You can set the number of days before locking occurs.

  • Wiping refers to resetting the application on the device. This deletes existing data on the device. You can set the number of days before wiping occurs.

When setting locking and wiping values in the cockpit, keep in mind these validation rules:

  • When the lock or wipe policies are not enabled, the fields shows a value of zero (0).

  • When the lock or wipe policies are enabled, at least one of the fields must have a non-zero value.

  • The lock period must be less than the wipe period.

  • The number of days before wiping must be greater than the number of days before locking.

The server informs the app when the policy takes effect, and the application responds according to its SDK programming.

Note

The locking policy is not the same as the blocking policy, which prevents the application user from registering the application or receiving traffic. See Managing Apps.

  1. In SAP mobile service cockpit, select Mobile Applications > Native/MDK or SAP Mobile Cards.

  2. Select an application, then select Mobile Settings Exchange under Assigned Features.

  3. Select Client Configuration. Under Locking and Wiping Policy, select Enable Locking and Wiping Policy.

  4. Configure the locking and wiping features.

    Locking and Wiping Policy

    Policy Description
    Offline Days Before Locking Set the number of days before the application will be locked on the user device. The number of days before locking must be lower than the number of days before wiping. Zero (0) indicates locking is not enabled.

    If locked, the user must reconnect to the server and authenticate.
    Offline Days Before Wiping Set the number of days before the application is reset on the user device. The number of days before wiping must be higher than the number of days before locking. Zero (0) indicates locking is not enabled.

    If wiped, the application remains, but the data is deleted.
  5. Select Save.

Defining Feature Restriction Policy

Feature restriction policies enable you to control feature access for the selected application. Set these policies in SAP mobile service cockpit. You can add, allow, restrict, edit, or delete features.

When you edit a native or hybrid app or an app developed with the Mobile Development Kit in SAP mobile service cockpit, available feature plugins are listed on the Mobile Settings Exchange screen. Feature plugins are typically JavaScript APIs that provide access to the native APIs of the mobile device (for example, for Hybrid apps they are typically implemented as Apache Cordova plugins, such as Camera, Calendar, and Push). You can indicate features that should be restricted from the user.

When a plugin, for example, the bar code scanner plugin, is in a disabled state on the server, the application starts a settings exchange and does two things:

  • Invalidates the native side of the plugin.

  • Changes the namespace of the plugin to null.

You may later enable a plugin on the server side, and trigger a settings exchange. At that time, although the plugin is not present in the disabled list, the value of the cordova.plugins.barcodeScanner namespace remains null; this value is reset only if a page refresh occurs, and Cordova reloads the plugin namespaces.

The new feature restriction policy takes effect after you exit the application and restart it to allow Cordova to refresh all the namespaces.

Note

It is a good idea to verify that a specific feature is enabled before calling the feature in the Web application (or underlying component that consumes the application).

You can apply the feature restriction values to all users (default); or you can set feature restrictions on certain parameters to enable or disable capabilities for specific users, groups, types, and operations, and the order in which to apply them. You can specify Random Pool (A/B Testing) and choose the active / inactive percentage value.

  1. In SAP mobile service cockpit, select Mobile Applications > Native/MDK or SAP Mobile Cards.

  2. Select an application, then select Mobile Settings Exchange under Assigned Features (or add it first).

  3. Under Feature Flags, you see the current status of feature restriction policies.

    Column Description
    Name A unique feature plugin name.
    Plugin A list of feature plugins that are available with the application, such as Camera, Calendar, and Push.
    ID Unique identifier for the feature plugin.
    Active Indicates whether the feature is allowed or restricted. On indicates the feature is allowed. Off indicates the feature is not allowed. For some features inherited from a provider, you may be able to activate a feature, or may be restricted.
    Actions The actions you can take, such as edit or delete. For features inherited from a provider, you may be restricted from these actions.
  4. Select add to add a feature plugin for the selected application, or select a row to edit it, and then click OK.

    Field Description
    Name A unique feature name.
    Plugin A feature plugin that is available with the application, such as Camera, Calendar, and Push.
    Plugin Name Plugin name.
    Description A feature plugin description, such as Cordova Camera Plugin, Cordova Contacts Plugin, and SAP Push Plugin.
    JavaScript Module A comma-separated list of all JavaScript modules that are used by this plugin. The JavaScript Module value is the JavaScript API that is used to invoke the plugin.
    ID Unique identifier for the plugin. The value comes from the cordova_plugins.js file, which appears in the project after you add a plugin ("pluginId").
    Active Toggle the feature On (allowed) or Off (restricted). By default, features are allowed..
    Rule-Based Activation Indicates whether the feature is subject to any rules. Options include: (1) None - no special rules apply. The feature restriction setting applies to all app users; (2) Activation Rule - special rules apply. You can set up one or more rules that only apply to certain app users, and set up the order in which the rules apply. When you select this option, the Activation Rules section appears. Enter the rules in the appropriate order (described below); and (3) Random Pool (A/B Testing) - use for delayed roll out of new features to a smaller pool of random users, or for performing A/B testing on new back ends. The Active / Inactive Percentage property appears.
    Active Percentage If you selected the Random Pool (A/B Testing) activation rule and Active is set to Off (meaning features are restricted), this property appears. Enter the percentage of registered app users to which you want to roll out the feature. For example, enter 25 to roll out the feature to 25% of the users.
    Inactive Percentage If you selected the Random Pool (A/B Testing) activation rule and Active is set to On (meaning features are available to all users), enter the percentage of registered app users to which you want to roll out the feature. For example, enter 35 to roll out the feature to 35% of the users.

    If you selected Activation Rule, the Activation Rules section appears. Add rules in the order they should be performed.

    1. Select add to add a new rule.

    2. Assign the property values for the rule. See the Activation Rule Examples table for sample values.

      Activation Rule Properties

      Property Description
      Name Descriptive name for the activation rule, such as "allowedPolicies: OS is Android" or "allowedPolicies: Svc Group".
      Type Indicates from where to fetch information, such as from a header, a service, and so forth. The value is parsed from this source. Options include: (1) App Version, (2) OS Version, (3) Device Platform, and (4) User Group.
      Operation The operator used to compare against the configured value. (1) For App Version and OS Version, options include: Equals, Not Equal, Starts With, Ends With, and Contains. (2) For Device Platform, options include Equals, Not Equal, and Any. (3) For User Groups, options include: All and Any.
      Value The value against which the operator compares, such as these typical values: (1) App Version - 1.0.0 (single value); (2) OS Version - iOS/16.11 (single value); (3) Device Platform - iOS, Android, Windows.; and (4) User Group - Cards_Admin, kibana_user_global (multiple values supported).
      Match Indicates the on/off status.
      Actions The action to take, such as decline to rmove the rule.

      Activation Rule Examples

      Type Operator Typical Value
      App Version Equals, Not Equal, Starts With, Ends With, Contains 1.0.0 (single value)
      OS Version Equals, Not Equal, Starts With, Ends With, Contains iOS/16.11 (single value)
      Device Platform Equals, Not Equal, Any Android (single value)
      User Group All, Any Cards_Admin, kibana_user_global (multiple values supported)
    3. Position the rules in the order they should processed, from the first (highest in the list) to the last (lowest in the list). This results in a "match first" approach. To position the rules, select a rule and then navigation-up-arrow to move the rule higher up in the list, and navigation-down-arrow to move the rule lower in the list.

    4. Select OK to save. The rule is added to the list.

  5. (Providers only) Under Feature Flags for SaaS Tenants, you see the current status of device feature plugins for your tenants, or select Enable Feature Flags for SaaS Tenants to enable the feature. See Defining Feature Restriction Policy for SaaS Providers) for details. If you are not a tenant provider, this section does not appear.

  6. Select Save.

Defining Feature Restriction Policy for SaaS Providers

Describes the end-to-end process for software-as-a-service providers to set feature restriction policies for their tenants. Before you start:

  • The SaaS provider production landscape must be in configured in SAP Business Technology Platform.

  • The SAP mobile service cockpit must implement storage service.

  • The runtime application settings must contain a saasFeatureVectorPolicies node.

  • To activate or deactivate specific tenants, you need their tenant IDs. You can obtain the tenant IDs in SAP Business Technology Platform cockpit, from the list of subaccount tenants.

This feature makes it possible for software providers to make mobile application feature plugins available to tenant subscribers. The plugins can be activated for all tenants, deactivated for all tenants, or activated/deactivated for a restricted list of tenants. Depending on the settings made, the feature plugin details may be read only, or may be edited or overridden.

You can apply the feature restriction values to all users (default); or you can set feature restrictions on certain parameters to enable or disable capabilities for specific users, groups, types, and operations, and the order in which to apply them. You can specify Random Pool (A/B Testing) and choose the active / inactive percentage value.

  1. In SAP mobile service cockpit select Mobile Applications > Native/MDK or SAP Mobile Cards.

  2. Select an application, then select Mobile Settings Exchange under Assigned Features.

  3. Under Feature Flags for SaaS Tenants, select Enable Feature Flags for SaaS Tenants.

  4. When Enable Feature Flags for SaaS Tenants is enabled, you see the current status of device feature plugins for tenants.

    Column Description
    Name A unique feature plugin name.
    Plugin A list of feature plugins that are available with the application, such as Camera, Calendar, and Push.
    ID Unique identifier for the feature plugin.
    Active Indicates whether the feature is allowed or restricted for tenants. On indicates the feature is allowed for tenants. Off indicates the feature is not allowed for tenants.
    Tenant Overridable Indicates whether tenants can override this setting. For example, a tenant may decide they do not want their users to use a feature even though it is available.
    Actions The actions you can take, such as edit or delete.
  5. Select add to add a feature plugin for tenants, or select a row to edit it, and then click OK to save.

    Feature Flags for SaaS Tenants Properties

    Property Description
    Name Enter the feature name, such as Feature1 or SaaSFeature2.
    Plugin Enter the feature plugin.
    Plugin Name Enter the feature plugin name.
    Description Enter a description of the plugin.
    JavaScript Module Enter a list of features included in the plugin, such as Camera,navigator.camera,CameraPopoverOptions,CameraPopoverHandle.
    ID The plugin identifier, such as cordova-plugin.Feature1.
    Tenant Overridable Whether subscribers can override this setting. For example, a tenant may want to decide whether to make a feature available to its subscribers, or when to make it available.
    Active Whether the feature flag is active for both the provider app (tenant) and the subscriber app. This value applies to all tenants, unless you specify otherwise. Select On if the feature flag is active. When set to On, the feature is available to all tenants. The property Deactive on Tenants appears, which enables you to turn off the feature flag for specific tenants. Select Off if the feature is inactive. When set to Off, the feature is not available to any tenants. The property Active on Tenants appears, which enables you to turn on the feature flag for specific tenants. This setting determines the default value for subscribers that appear in the Feature Flag table. See Defining Feature Restriction Policy.
    Active on Tenants If Active is set to Off (meaning the feature is inactive for all tenants), you can use this property to override the flag for specific tenants. Enter one or more tenant IDs. The feature is then activated for the tenants in this list.
    Deactive on Tenants If Active is set to On (meaning the feature is active for all tenants), you can use this property to override the flag for specific tenants. Enter one or more tenant IDs. The feature is then deactivated for the tenants in this list.
    Rule-Based Activation Indicates whether the feature is subject to any rules. Options include: (1) None - no special rules apply. The feature restriction setting applies to all app users; (2) Activation Rule - special rules apply. You can set up one or more rules that only apply to certain app users, and set up the order in which the rules apply. When you select this option, the Activation Rules section appears. Enter the rules in the appropriate order (described below); and (3) Random Pool (A/B Testing) - use for delayed roll out of new features to a smaller pool of random users, or for performing A/B testing on new back ends. The Active / Inactive Percentage property appears.
    Active Percentage If you selected the Random Pool (A/B Testing) activation rule and Active is set to Off (meaning features are restricted), this property appears. Enter the percentage of registered app users to which you want to roll out the feature. For example, enter 25 to roll out the feature to 25% of the users.
    Inactive Percentage If you selected the Random Pool (A/B Testing) activation rule and Active is set to On (meaning features are available to all users), enter the percentage of registered app users to which you want to roll out the feature. For example, enter 35 to roll out the feature to 35% of the users.

    If you selected Activation Rule, the Activation Rules section appears. Add rules in the order they should be performed.

    1. Select add to add a new rule.

    2. Assign the property values for the rule. See the Activation Rule Examples table for sample values.

      Activation Rule Properties

      Property Description
      Name Descriptive name for the activation rule, such as "allowedPolicies: OS is Android" or "allowedPolicies: Svc Group".
      Type Indicates from where to fetch information, such as from a header, a service, and so forth. The value is parsed from this source. Options include: (1) App Version, (2) OS Version, (3) Device Platform, and (4) User Group.
      Operation The operator used to compare against the configured value. (1) For App Version and OS Version, options include: Equals, Not Equal, Starts With, Ends With, and Contains. (2) For Device Platform, options include: Equals, Not Equal, and Any. (3) For User Groups, options include: All and Any.
      Value The value against which the operator compares, such as these typical values: (1) App Version - 1.0.0 (single value); (2) OS Version - iOS/16.11 (single value); (3) Device Platform - iOS, Android, Windows; and (4) User Group - Cards_Admin, kibana_user_global (multiple values supported).
      Match Indicates the on/off status.
      Actions The action to take, such as decline to rmove the rule.

      Activation Rule Examples

      Type Operator Typical Value
      App Version Equals, Not Equal, Starts With, Ends With, Contains 1.0.0 (single value)
      OS Version Equals, Not Equal, Starts With, Ends With, Contains iOS/16.11 (single value)
      Device Platform Equals, Not Equal, Any Android (single value)
      User Group All, Any Cards_Admin, kibana_user_global (multiple values supported)
    3. Position the rules in the order they should processed, from the first (highest in the list) to the last (lowest in the list). This results in a "match first" approach. To position the rules, select a rule and then navigation-up-arrow to move the rule higher up in the list, and navigation-down-arrow to move the rule lower in the list.

    4. Select OK to save. The rule is added to the list.

  6. Select Save.

    Once you activate a feature for an app, it appears in the subscriber list of feature plugins. Depending on its settings, the feature may be read only, with no actions available to subscribers.

    If you make the feature tenant overridable, the tenant can decide whether to make the feature plugin available to subscribers. Depending on its settings, the feature may be read only, with no actions available to subscribers.

Defining Device Policy Profiles

Create device policy profiles for the selected app, and the conditions that trigger the policy profile. For example, you may want to apply one passcode policy to one group of users, and another policy to another group.

This feature is available:

  • Version 2 API only

  • Native/MDK apps only

  • Includes SaaS apps

This feature provides a way to divide users into different groups in SAP mobile service cockpit, and use conditions to apply different policies to each group. These policies can be applied to device profiles:

  • Pass code Policy

  • Locking and Wiping Policy

  • Network Synchronization Policy

Once the policies are created, you can use drag and drop to adjust the order of the profiles. The profile at the top of the list is applied first followed by each subsequent profile.

  1. In SAP mobile service cockpit select Mobile Applications > Native/MDK or SAP Mobile Cards.

  2. Select an application, then select Mobile Settings Exchange under Assigned Features.

  3. Select Client Configuration. Under Device Policy Profile, you can view the list of device policy profiles.

    Device Policy Profiles

    Property Device Policy Profiles
    Name Descriptive name used to identify the device policy profile.
    Description A more detailed description of the device policy profile.
    Active Whether the policy is active. Note that if you change the Active setting, be sure to select Save in the upper right corner of the page to save the change.
    Actions Actions you can take such as edit or delete.
  4. Select add to add a new profile using the New Device Policy Profile wizard, or select an existing profile to edit it.

    1. On the General Information page, enter basic information and then select Next.

      General Information

      Property Description
      Name Descriptive name to identify the device policy.
      Description (Optional) Description of the device policy with additional details.
      Active Indicates whether the policy is currently active.
    2. On the Passcode Policy page, select Enable Passcode Policy and enter policy values. See Defining Client Password Policy for details. When finished, select Next.

    3. On the Locking and Wiping Policy page, select Enable Locking and Wiping Policy and enter policy values. See Defining Lock and Wipe Policy for details. When finished, select Next.

    4. On the Network Synchronization Policy page, select Enable Network Policy and enter policy values. See Defining Network Synchronization Policy for details. When finished, select Next.

    5. On the Triggered Conditions page, enter the conditions for which the device policy profile is activated, in one or more condition groups.

      1. If necessary, select Add a Condition Group to get started.

      2. Add one or more conditions to the group.

        Condition Properties

        Property Description
        SAML Attribute Name The attribute name for the condition.
        Operator The operator to use for the condition, such as Equals or Contains.
        SAML Attribute Value The value to use.
        Actions The action to take, such as delete a condition or group, or add another condition to the condition group.
      3. Add additional groups as needed.

  5. Select Finish to save. The wizard closes, and the policy appears in the device policy profiles list.

  6. Once the policies are created, you can use drag and drop to adjust the order of the profiles. Select Save in the upper right corner of the page to save the changes.

    The profiles are applied in the order they appear, from the first in the list to the last.


Last update: January 26, 2024