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 portal securely. Currently only the existing user's are migrated
Flow chart:
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 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.