Issue with Password Handling During JIT Provisioning in IS 7.0 with "Prompt for Password and Consent": User Unable to Log In with Provided Password Until Admin Reset

[AfraHussaindeen]

Describe the issue :

In IS 7.0, when a user provides a password during the JIT provisioning flow (with the provisioning scheme set to "Prompt for password and consent"), the user is successfully provisioned. However, if the user tries to log in to the MyAccount portal using the provisioned local user account and the password provided during the JIT flow, the login fails. If the password is reset by the admin via the console, the user can successfully log in to MyAccount.

Steps to Reproduce:

1. Log in to the IS console as an admin.
2. Set up a Google federated authenticator and enable JIT provisioning with the provisioning scheme set to "Prompt for password and consent."
3. Create an application configured to use the Google federated authenticator.
4. Perform a login to the application.
5. Observe that a password prompt is displayed.
6. After successfully logging in, open an incognito window and try to log in to the MyAccount portal using the username and the provided password. Notice that the login fails.
7. Go back to the console, navigate to the User Management section, and click on Users. Select the provisioned user and click on the Reset Password button.
8. Try to log in to the MyAccount portal using the new password. Observe that the login is successful.

Expected Behavior:

The user should be able to log in to MyAccount with the password provided during the JIT provisioning flow without needing a password reset.

Actual Behavior:

The user cannot log in with the password provided during the JIT provisioning flow. A password reset is required for successful login.

Possible Cause:

A random password may still be set despite the user's input during JIT provisioning.

Optional Fields

Related issues:

Suggested labels:

[mpmadhavig]

Analysis

The rootcause for this issue was the password field getting sent from the FE does not have a field password. It has been renamed to password2 in a later effort. This has lead to password field being null for the BE and when the field is null it genarates a random password for the user.

Fix:
Send a field called password in the request.