Before reporting an issue

• I have searched existing issues
• I have reproduced the issue with the latest release

Area

authentication

Describe the bug

When Kerberos authentication is enabled in the browser flow, non-kerberos authentication user cannot complete the reset password flow because "Page has expired" error happens.

Version

RH-SSO 7.6

Expected behavior

HTTP 200 success response should be returned after resetting the password.

Actual behavior

HTTP 401 error response is returned after resetting the password.

How to Reproduce?

1. Create a new realm
2. Create a new RH-SSO local user
3. Make "Kerberos" execution in the "Browser" flow requirement "ALTERNATIVE"
   (No need to configure kerberos User Federation config for reproducing the error)
4. Make "Forgot password" option "ON"
5. Go "Realm Settings" -> "Email" tab, and configure "Host" and "From" fields.
6. Open the login form page
7. Navigate to the password reset form page by clicking "Forgot Password?" link
8. Fill the "Username or email" field with the user created in the step2, and submit

The request will be processed properly, the reset link email will be sent, but the HTTP response will have HTTP status code 401 and "WWW-Authenticate: Negotiate" header, which instructs the browser to do Kerberos authentication.
If the browser is not configured to handle Kerberos authentication, the browser will re-submit the same HTTP request,
but RH-SSO server will reject the request because the session code in the request is already consumed in the previous request, and RH-SSO server will return the "Page has expired" page.

There is a similar issue(KEYCLOAK-17218), but the issue still persists in RH-SSO 7.6.0.

Anything else?

RH-SSO server must not add "WWW-Authenticate: Negotiate" header to the "Reset password" response even when Kerberos authentication execution is enabled.

Workaround(only works for wildfly based distribution)
Following JBoss CLI commands mitigates the issue by removing the "WWW-Authenticate: Negotiate" header from the "Reset password" response.

/subsystem=undertow/configuration=filter/expression-filter=clear-www-authenticate-header-filter:add(expression="clear(attribute='%{o,WWW-Authenticate}', pre-commit='true')")
/subsystem=undertow/server=default-server/host=default-host/filter-ref=clear-www-authenticate-header-filter:add(predicate="method(POST) and path-prefix(/auth/realms/<PUT_YOUR_REALM_NAME_HERE>/login-actions/reset-credentials)")

Please note this workaround only works for Wildfly(JBoss-EAP) based distribution. For Quarkus-based distribution, it cannot be used and need to fix the root cause.