SaFi Bank Space : Offboard user - deny login

Epic: SM-1816 - IAM: Offboard user Resolved

JIRA: SM-1839 - Offboard user - deny login Done

Priority:

Effort estimate:

Review status: in preparation/ready to review/approved

As a Customer I want to get my access denied as I am no longer customer so that I cannot use app functionality

Role: Customer

Objective:

Reason:

Functional requirements:

Customer data is stored indefinitely.

Customer cannot login using credentials that are stored and tagged as off-board, risky?, blacklisted?

Account lock/unlock mechanism – Customer service is responsible for locking and unlocking account. This decision is driven by another team e.g. Transactions. When account is locked Customer is restricted to take any actions within app, but it will be available in read-only view. Account disablement /closure is not part of MVP

UI requirements:

Process flow:

Execution steps:

Internal dependencies:

External dependencies: 3rd party prerequisites

Alternative scenarios: what would happen if not done (optional)

Acceptance criteria:

• Pre-condition: BOFE or Slacker (Risk engine) initiate the offboarding procedure

• Customer is unable to access the app using credentials, passcode or device biometry

• Customer is (re)directed to the first time login page

Links to wireframes/UI:

Technical Assessment

VIDA supports the /api/v1/device/unregister-device endpoint that makes the credential ID inactive.

Note that the VIDA API does not support to reactivate the credential ID later.

Note that currently only the IN_PROGRESS state is used (COMPLETED is not used) that is why lock/unlock is transitioning between LOCKED and IN_PROGRESS.

Implementation details:

• irrevocably revoke a credential (key): create a new endpoint for iam-manager:
  POST credential/revoke-by-customer/{customerId}:

  • calls the VIDA endpoint above

  • updates in the local database the status of the customer ID - credential ID pair to REVOKED

  • should be secured for service2service call only

• lock a credential (key): create a new endpoint for iam-manager:
  POST credential/lock-by-customer/{customerId}

  • updates in the local database the status of the customer ID - credential ID pair to LOCKED only if the status is IN_PROGRESS

  • should be secured for service2service call only

• unlock a credential (key): create a new endpoint for iam-manager:
  POST credential/unlock-by-customer/{customerId}

  • updates in the local database the status of the customer ID - credential ID pair to IN_PROGRESS only if the status is LOCKED

  • should be secured for service2service call only

• update iam-auth-lib functionality to handle the new statuses above (where needed)

• (increase the API version - no breaking changes, no depreciations)

Sequence Diagram

This describes the flow for locking, unlocking and revoking credentials.

The following diagram shows the changes needed in the interceptor to check for the credentials state before further proceeding with the main authentication logic.

State Diagram

The diagram below illustrates the state transitions for the current and target flows:

Negative Scenarios

I. Timeouts or Service Crash During Unregister Call to VIDA

Solution A. Perform a status synch to VIDA when the credential state is IN_PROGRESS

Solution B. Continue revocation of credentials if VIDA http errors are encountered

In this solution, we will maintain our internal credential state as the source of truth. Thus, any unexpected technical errors encountered during call to VIDA to unregister the credentials won’t affect the revocation call. In this case, we will continue with tagging the credential as revoked in our database and just log the error. If needed, this may require at some point a synch between our internal credential states vs those of VIDA’s.

Solution C. Use Temporal to properly handle state management

Not needed to use temporal since this is only a simple workflow.