Skip to content

Configuring and Testing Access Control in a Cloud Foundry Environment

This procedure allows you to verify that the client has permission to access a Mobile Service application in Cloud Foundry.

The basic steps for configuring the application environment:

  1. In the SAP Cloud Platform Mobile Services cockpit, set up Access Control for the application.

  2. In the SAP Cloud Platform cockpit, set up Role Collections and map to IDP groups.

  3. Set up the user and related groups in IDP, then log in to SAP Cloud Platform Mobile Services to get the Access Token.

  4. Send a request to the application to test that the access rule is satisfied via the 200 OK or 403 Forbidden responses.

The step-by-step procedure for configuring and testing the application environment:

  1. In the SAP Cloud Platform Mobile Services cockpit, set up Access Control for the application:

    1. Log in to the SAP Cloud Platform Mobile Services Cockpit.

    2. Select an existing application or create a new one.

    3. On the Security tab, you can set up the Access Control properties, including Application Versioning and Role Settings.

    4. Click Edit in Application Versioning to enable Application Versioning. When Versioning is enabled, you need to add one or more Application Versioning items (v1.0 and V1.1, for example, where v1.1 is the active version) and click Save to save the configuration.

    5. Click Edit in Role Settings to enable role settings and add roles. Add role1, role2, role3, etc.

  2. In the SAP Cloud Platform cockpit, set up the Role Collections and map to IDP groups:

    1. From the Security menu in the target tenant setting page, select Role Collections, and click New Role Collection to create a new Role Collection for the application.

    2. Fill in the required fields, including a role collection name (i.e. role_collection_app1), and click Save. The Role Collection is created.

    3. Click the link for the Role Collection name to open the Role Collections page. To add a role, click Add Role.

    4. In the Add Role dialog, select the Application Identifier (the XSUAA client ID listed on the Application Detail page.
    5. For Role Template, select role1.
    6. For Role, enter role1 and click Save.
    7. Repeat the previous three steps for role2 and role3.
    8. Return to the Security menu and choose Trust Configuration to set up mapping between the Role Collection and the Group in IDP configuration.
    9. Click the link in the Name column (xsuaa-monitoring-idp, for example).
    10. Click Role Collection Mappings to set up the mappings.
    11. Click Edit to create a new Role Collection Mapping.
    12. Choose the name of the Role Collection you created (role_collection_app1, for example) and enter the group name in the value field (group1, for example). The group name must already exist in the IDP settings.
    13. Click Save.
    14. Set up the user and related groups in IDP, then log in to Mobile Services to get the Access Token:

    15. Use a utility such as SoapUI to verify Access Control checking. Firstly, send a specific request to the Mock IDP xsuaa-monitoring-idp to generate a specific Access Token. Set username to testuser and group to group1. Also set the related URLs and Client ID.

    16. Generate the Access Token.

      The Access Token is generated and it includes role1, role2, and role3.

    17. Change the group to group2 and generate a new Access Token.

      The Access Token is generated and it does not include role1, role2, and role3.

  3. Send a request to the application to test that the access rule is satisfied via the 200 OK or 403 Forbidden responses:

    1. On the Native/Hybrid page, disable the Application Versioning check and leave the Role Settings check enabled.

    2. Send a request to the application using the Access Token that includes any of role1, role2, and role3.

      The response code is 201 OK, indicating that the request passed the Access Control check and the app can be onboarded successfully.

    3. Send a request to the application using the Access Token that does not include any of role1, role2, and role3.

      The response code is 403 Forbidden, indicating that the request was rejected by the Access Control check.

    4. On the Native/Hybrid page, enable the Application Versioning check and disable the Role Settings check.

    5. Set the header X-APP-VERSION value to a valid Application Version (i.e. the active version of the app, v1.1) and send the request

      The response code is 200 OK, indicating that the request passed the Access Control check.

    6. Set the header X-APP-VERSION value to an invalid Application Version (i.e. the inactive version of the app, v1.0) and send the request.

      The response code is 403 Forbidden, indicating that the request was rejected by the Access Control check.

    7. On the Native/Hybrid page, disable both the Application Versioning check and the Role Settings check.

    8. Send a request without any roles, and also with an invalid Application Version (i.e. the inactive version of the app, v1.0), and send the request to the application.

      The response code is 200 OK, indicating that no version or role check was performed and the request passed the Access Control check.

Configuring App Security

Configure security at the application level for the Cloud Foundry environment.

When you define a new application in the Cloud Foundry environment, an OAuth client is created automatically by the server. A non-null default value is set for client ID and the redirect URL once the application is created.

If you select OAuth or SAML for app security authentication, API Key is not enabled. If API Key is configured as part of SDK bootstrapping, services such as setting exchange, log upload, and usage upload are accessed before Mobile Services authentication.

If you select API Key Only for app security authentication, and enable API Key, anonymous access is used. This is similar to the no authorization option that is available in the Neo landscape. This combination also provides access to client resources. If you select API Key Only, you must enable API Key.

  1. In Mobile Services cockpit, select Mobile Applications > Native/Hybrid.

  2. Select an application, and Security.

  3. (Optional) Lock the application so others can't make changes to the same application.

  4. Under Application Settings, view or edit settings.

    1. In Edit Application Settings, select XSUAA Service to create an XSUAA default service instance for the application, or select an existing service.

    If you select the default, you can select OAuth Settings.

    Using an existing XSUAA instance is useful if you already have a Cloud Foundry application deployed and want to connect from Mobile Services to this application. In this case it can be handy to re-use an existing XSUAA instance. Please stick to the default instance for other scenarios.

    1. (Web applications only) In Edit Application Settings, select CSRF Protection to enable cross-site request forgery protection. When this option is selected, all services, such as registration, are protected with CSRF tokens. Proxied endpoints aren't protected, since they are likely to be protected on the back end.

    2. For Security Configuration, select a security option:

      • API Key Only ‒ uses an API key for authentication. The key is generated or you can select additional keys in a later step. No other authentication method can be used with this choice.

      • Basic ‒ enables stand-alone basic authentication either with or without Cloud Connector. You must download and import a Trust Configuration into your cloud subaccount as described in Configuring Trust for Basic Authentication.

      • Basic with SAP ID Service ‒ authentication delegates to the SAP ID service. If your SAP Cloud Platform account uses a different identity provider, this choice fails.

      • OAuth ‒ an open protocol for securely authorizing applications using a standard method. SAP Cloud Platform must be the authorization server. This is the default option, and the OAuth client is generated automatically. You can use API keys with this choice.

      • SAML ‒ uses SAML 2.0 supplied by SAP Cloud Platform (the SAP ID service authenticates users against both SAP user accounts and SAP Community Network (SCN) accounts). You can use API keys with this choice.

    3. If you select OAuth (the default), select the edit icon to configure.

      Under OAuth Settings

      Field Description
      Token Lifetime Enter the lifetime for a token in number of days, hours, or minutes (12 hours is the default). The entry is subject to any limitations imposed by the server.
      Refresh Token Lifetime Enter the lifetime for a refresh token in number of days, hours, or minutes (30 days is the default). The entry is subject to any limitations imposed by the server.
      Auto Approve Whether the user needs to approve the token scope, or whether it can be approved automatically.
      Approved Providers Indicate the approved identity providers for the application:
      • All (default) ‒ all identity providers are approved for the app.
      • Selected Providers ‒ enter one or more approved identity providers for the app (hit Enter after each entry).

      Note: Since Mobile Services cockpit cannot validate the identity provider entries, it is very important to enter them correctly. Otherwise, users will not be able to log in successfully.

      The Selected Providers option enables you to be specific about the identity providers for the app, especially if you have multiple providers configured for the subaccount. For example, say you have two identity providers configured for the subaccount ‒ ldap (origin of default identity provider SAP ID Service) and hanamobile_sci. Assume you have two mobile applications, and one application needs to be protected by the SAP ID Service, and another one by hanamobile_sci. You can configure ldap as the approved provider for the first application, and hanamobile_sci for second application.

      Under OAuth Clients, click the add icon, and add an OAuth client.

      Field Description
      Client ID To regenerate the client ID, select an ID and then Regenerate. The ID is automatically generated, and identifies the application client to the authorization server.
      Redirect URL The redirect URL for the OAuth client.
    4. If you select Basic with SAP ID Service, Basic, or SAML instead of OAuth, you are notified that the change affects the application availability for the device user, and that an application restart is required to update the application’s configuration. Select OK.

      If you select Basic, provide the Basic Settings, and select OK. The Mobile Connectivity feature is assigned automatically to the application to provide a proxy service, and cannot be removed (navigate to the Info tab to verify that Mobile Connectivity appears under Assigned Features).

      Basic Settings

      Field Description
      URL The URL to use for basic authentication. The URL entered here must return a 401 (Unauthorized) response message when random username and password are sent as Authorization: Basic header according to RFC 2617 (as described in: https://tools.ietf.org/html/rfc2617).
      Use Cloud Connector Enables you to use cloud connector.
      Cloud Connector Location ID (Optional) The cloud connector identifier to use.
  5. Under Application Versioning, select Enable Application Versioning to manage versions for this application. Once enabled, you can view and edit versions.

    1. Click the add icon to add a version.

    2. Modify the application version settings:

      Version Settings

      Field Description
      Version Application version
      Active Whether the application version is active or available for use
      Description Application version description
      Actions Actions you can perform, such as edit or delete
    3. Click OK to save, or Cancel. If you make any changes, you must restart the application.

  6. Under Role Settings, view or edit settings. In Edit Role Settings, select Enable Role Settings to use roles.

    Once enabled, you can specify one or more roles, such as Admin or Developer, and click OK. If you make any changes, you must restart the application.

  7. Under API Key, if you selected OAuth, SAML, or API Key Only as the Security Configuration, you can view or edit API keys. If you selected API Key Only, an API key is created using the current date and time. You must have at least one API key or you receive a warning. Select add to add or delete keys.

    Under Anonymous Access, view or edit settings. In Anonymous Access, select Allow Anonymous Access to enable the client-side applications to use API keys as credentials.

    1. To edit, click the add icon to add an API key.

    2. Add one or more valid API keys for the application.

      API Key Settings

      Field Description
      API Key When implemented, at least one API key is required.
      Creation Date The server generates the creation date once the API key is created.
      Actions Select delete to delete an API Key.
    3. Click OK to save, or Cancel. The API keys and their creation dates appear. If you make any changes, you must restart the application.

  8. If you locked the application while making changes, select Unlock to release it.

Configuring Trust For Basic Authentication

Configure trust at the space level between Mobile Services and your SAP Cloud Platform sub-account. This is required for applications using Basic Authentication in the Cloud Foundry environment.

Default and custom trust configuration must already be established in SAP Cloud Platform cockpit. For information about establishing trust, see Establish Trust and Federation with UAA Using Any SAML Identity Provider.

Importing trust configuration metadata into your cloud sub-account enables Mobile Services to generate user authentication tokens for users that are identified as using Basic Authentication or an API key. Importing the trust configuration only needs to be done once.

Once the metadata is imported, any mobile application or micro app for some regions (such as WeChat) in the space that is configured to use Basic security, can use the trust settings.

Note

If all configured applications only use OAuth or SAML authentication, this step is not required.

  1. In Mobile Services cockpit, select Settings > Security.

  2. Select MetaData Download to download the trust configuration from SAP Cloud Platform into your cloud sub-account (SAMLMetadata.xml). This only needs to be done once. If you do not see the MetaData Download button, this means that no standalone proxy service instance exists. SAMLMetadata.xml has been imported into the sub-account, or does not effect the Trust test result.

  3. Select Test to make sure the metadata has been established successfully as a trusted provider.

    If the trust configuration is not established correctly, you may see a message like SAML metadata might not have been imported as trusted identity provider.

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 Cloud Platform 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 Mobile Services cockpit, select Mobile Applications > Native/Hybrid 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.
    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 Lock and Wipe Policy

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

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 Mobile Services 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.

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 Mobile Services cockpit, select Mobile Applications > Native/Hybrid 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. 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. If wiped, the application remains, but the data is deleted.
  5. Select Save.


Last update: November 19, 2020