Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Overview:

Currently, Any user initiating a first time SSO login using an identifier that already exists in the custodian org - causes an auto migration of the account from custodian to the state tenant it can cause erroneous migration to avoid it user's acknowledgment is required.

If the user is found to match an account in the custodian org when the user tries to login via SSO for the first time, the user should be prompted about the existence of the duplicate account and asked whether the account belongs to them.

If the user stakes claim to the account, they have to prove ownership of the existing account (in custodian) by providing the password to the account. If a valid password is provided, the account in the custodian org is migrated to the state tenant. The SSO details sent by the state will apply to the new account for the user.

If the user refutes ownership of the existing account, they are provided with a new account on the state tenant as per the standard SSO workflow. The identifier is assigned to the new account in the state tenant. The old account in custodian that existed is stripped of the identifier and made inactive.

Problem statement:

Account auto-merge workflow should be handled in the portal front end and portal backend. An auto migration of the account from custodian to the state tenant it can cause erroneous migration to avoid its user's acknowledgment is required.

Approach :


                                          

Step 1: While SSO user is prompted to update email/Phone if not present already.

Step 2: An OTP is generated and the user is allowed to enter received OTP.

Step 3: For new users, if email id is already found in dupe check show user a confirmation popup to initiate account migrate. If the user denies merging deactivate the nonstate user account and create a new account.If the user allows merging goto step 4

Step 4: User is allowed to enter the password if the password is correct to initiate migration of account else allow the user to reenter the password.

Step 5: Users re-enter the password. If the password is correct initiate account migration else create a new account for the user.


Conclusions after first design discussion

  1. encrypt the user's identifier (email or phone number) and state token after it verifies the otp  and send it to keycloack and receive the same back
  2. before calling migrate api check if same user is merging or not to do this decrypt the encrypted details and validate the email address from decrypted data and token generated after sign in should have same email id.
  3. Do we really need subdomain ? if YES - logoff the other user account and create session of state user.


Question to PM?


  1. verify the message on cancel and merge screen - Rajeev discussed same will be changed by PM.
  2. is username from state and keycloack auth token is diffent what error message and screen should be shown -  Need to show error message in error message screen. 
  3. check if we can use the manual merge screens with username field already having value and user cannot edit it.

Catch in the process- ?

how mobile will login to system in case of google and normal sign as now we are passing the keyclaock token in query and allow user new state user to login to system.

Issues with mobile team-

  1. mobile team will send client_id ='android' when the sso flow starts and portal will capture and this parameter will be send to all flow.
  2. On keycloak sign in -
    1. mobile team will capture the code param given after successful sign from keycloack and store it in memory (check ) 
    2. if migrate is successful mobile will generate new session from code and login user else close the flow (check if we get update values of not) new user should be logged in as a state user  .
  3. On google sign in -
    1. Mobile closes Webview
    2. google page opens in custom tab (redirect url is passed with query params, which includes encrypted data )
    3. On successful login, the encrypted data along with generated AccessToken/RefreshToken is appended to redirect invalid URL to be captured by mobile
    4. mobile continues flow by opening another Webview with predefined URL along with data captured from step 'b'.
    5. poratl redirects to successful/erroneous redirect and mobile closes the webview.

UI Screens

Verify user via email or phone

user enters OTP




Click on the below-mentioned link for further flow.

https://projects.invisionapp.com/share/2YT9CGQNASD#/screens/376879374



  • No labels