If you create an account with email, and verify the passcode, but NOT set a password (e.g. by leaving the page), the account is left in a limbo state. This means that they're unable to log in, or perform recovery on themselves.
These affected users are left in the STAGED state within Okta, which means that they're not a “full” account (the ACTIVE state), and are left unverified. Normally a user would transition from the STAGED to the ACTIVE state by setting a password, which happens if a user inputs a password during the create account process.
For users in a non-ACTIVE state, we have programmatic remediation options for these users if they go through a “reset password” flow. For example for STAGED users [code] normally we attempt to call the Okta “Activate User” method which would create a token we could send to the user. However this fails with an error message “Password reset is not allowed in the user's current status” and the error code “E0000017”, which is why the user sees an error message. This suggests that the normal remediation option does not work for these users.
How to fix
Okta support mentioned that these users are left in a state where they’re unable to perform any recovery as they didn’t complete the flow. The way to recover these users is to deactivate these users, and then activate them again
This PR
In this PR we implement the remediation option that Okta suggested.
Essentially when a user goes through the reset password or register flow, we check what state the user is in.
Users in this limbo state will be either in the STAGED or PROVISIONED state which is determined by if they tried to recover before this PR went in.
This PR adds a check for a specific error which occurs when users are in this specific state.
If this error is detected we perform the remediation, by calling the newly added deactiveUser function, we then just call the respective sendEmail function again. This time it will check for the DEPROVISIONED state, which as mentioned needs to activate the user again and send them an email. So we simply add a check for DEPROVISIONED to the STAGED check, as they both activate the user!
We also add logs and metrics so we can monitor these users.
Finally we add cypress tests to test these four scenarios.
Other changes were made to remove a rogue .only in a cypress test, and adjust some matrix behaviour.
All deployment options
- [Deploy build 9723 of `identity:identity-gateway` to CODE](https://riffraff.gutools.co.uk/deployment/deployAgain?project=identity%3Aidentity-gateway&build=9723&stage=CODE&updateStrategy=MostlyHarmless&action=deploy)
- [Deploy parts of build 9723 to CODE by previewing it first](https://riffraff.gutools.co.uk/preview/yaml?project=identity%3Aidentity-gateway&build=9723&stage=CODE&updateStrategy=MostlyHarmless)
- [What's on CODE right now?](https://riffraff.gutools.co.uk/deployment/history?projectName=identity%3Aidentity-gateway&stage=CODE)
github-actions[bot]
commented
3 months ago
The Issue
If you create an account with email, and verify the passcode, but NOT set a password (e.g. by leaving the page), the account is left in a limbo state. This means that they're unable to log in, or perform recovery on themselves.
These affected users are left in the STAGED state within Okta, which means that they're not a “full” account (the ACTIVE state), and are left unverified. Normally a user would transition from the STAGED to the ACTIVE state by setting a password, which happens if a user inputs a password during the create account process.
For users in a non-ACTIVE state, we have programmatic remediation options for these users if they go through a “reset password” flow. For example for STAGED users [code] normally we attempt to call the Okta “Activate User” method which would create a token we could send to the user. However this fails with an error message “Password reset is not allowed in the user's current status” and the error code “E0000017”, which is why the user sees an error message. This suggests that the normal remediation option does not work for these users.
How to fix
Okta support mentioned that these users are left in a state where they’re unable to perform any recovery as they didn’t complete the flow. The way to recover these users is to deactivate these users, and then activate them again
This PR
In this PR we implement the remediation option that Okta suggested.
Essentially when a user goes through the reset password or register flow, we check what state the user is in.
Users in this limbo state will be either in the STAGED or PROVISIONED state which is determined by if they tried to recover before this PR went in.
This PR adds a check for a specific error which occurs when users are in this specific state.
If this error is detected we perform the remediation, by calling the newly added
deactiveUserfunction, we then just call the respective sendEmail function again. This time it will check for theDEPROVISIONEDstate, which as mentioned needs to activate the user again and send them an email. So we simply add a check forDEPROVISIONEDto theSTAGEDcheck, as they both activate the user!We also add logs and metrics so we can monitor these users.
Finally we add cypress tests to test these four scenarios.
Other changes were made to remove a rogue
.onlyin a cypress test, and adjust some matrix behaviour.Tested