Skip to content

Understanding Flow Capabilities

The onboarding and restore flows handle a significant amount of complex logic for you. In this topic, we explain some of the details of this logic.

Passcode Policy Management

Passcode policy is one of the important security features for the mobile app. Usually in an enterprise, the administrator will define the passcode policy from the cockpit, then every onboarding user must respect this policy and create the passcode to protect the mobile app.

Here is how the onboarding and restore flows manage the passcode policy.

Create Passcode

During the onboarding flow, right after the user is authenticated, the flows component will retrieve the passcode policy from 'SAP Mobile Services', so a passcode can be created according to the policy.

The administrator can choose to disable the passcode policy, but this will be used mostly for testing apps. When the passcode policy is disabled at the server side for single-user mode apps, there will be no passcode creation steps following the authentication step. But for multiple-user mode apps, even if the passcode policy is disabled, a default one will be created, and the passcode must be created for this onboarding user.

If the passcode policy is enabled when a user is onboarded for a single-user mode app, after the passcode is created a step to enable biometrics may follow if the passcode policy also enables the 'Biometric Authentication Allowed' property. For multiple-user mode apps, there will be no biometric creation step even this property is enabled.

Passcode Retrieval Failure

During the onboarding flow, there may be occasions when the retrieval of the passcode policy fails. When this happens, the flows component will prompt the user with a dialog so that the user can choose to retry or continue. If the user clicks Retry, the API will be called again.

If the user clicks Continue in a single-user mode app, there will be no passcode creation steps and the user can invoke the change passcode flow to create the passcode. But for multiple-user mode apps, a default passcode policy will be used to create the passcode.

For the forgot passcode flow, the logic is a little different after the user clicks Continue because the user already has an effective passcode policy, so the current policy will be used to create the new passcode.

Passcode Policy Update

After the restore flow, the flows component will also call the API to retrieve the passcode policy from the server side, then try to notify the user to update the passcode, if necessary.

Whether the flows component notifies the user to update the passcode depends on whether the current passcode meets the requirement of the policy or not.

If the user unlocks the app with the passcode, the flows component will verify the passcode against the new policy. If it does not meet the requirements, a notification will be sent to the user, who can then click on the notification to change the passcode immediately, or change the passcode later without interrupting the current workflow.

When a change passcode notification is received and the user invokes the change passcode flow explicitly, the new passcode policy will be used. After the passcode is updated, the user will not be forced to change passcode for the next login.

However, if the user forgets to change the passcode, then the next time the app is unlocked, the change passcode steps will automatically be appended after the Sign-In screen, forcing the user to change the passcode.

For single-user mode apps, if the user unlocks the app using their fingerprint, there will be no notification to update the passcode. But if the current passcode is going to expire in 3 hours, there will be a notification. After the passcode expires, the change passcode steps will also automatically be appended after the Sign-In screen.

Passcode Policy Downgrade

There may also be cases where the administrator chooses to downgrade the passcode policy at the server side, for example, the enabled passcode policy may be disabled. In this case, the change will affect the newly onboarding users. For a user who was already onboarded with the enabled passcode policy, there is no opportunity for the user to remove the passcode on the secure store.

Usage data collection and crash report upload both require user consent to be enabled. This is handled by UsageService and CrashService, respectively.

When the onboarding flow starts, the flows component will automatically insert the corresponding user consent screen for the service that was initialized using SDKInitializer. The service will only be started when the user clicks the Allow button, and the user consent status will also be saved to the user's secure store.

When the user next unlocks the app, the consent status will be retrieved from the database, the corresponding service will be started automatically by the flows component if the user provided consent during the onboarding flow, and the consent status will also be notified to the client code with the onConsentStatusChange callback function of FlowStateListener.

The client code can also review the user consent status at a later time and change the consent if necessary. When revoking user consent, the client code may not need to provide the user interface to allow the user to click the Disagree button, but you must ensure that the updated user consent status is written back into the user secure database using the updateConsentStatus API in UserSecureStoreDelegate.

The app generated by the SAP BTP SDK Wizard for Android provides detailed sample code for this topic.


Last update: May 28, 2021