[BUG] `oidcHash`/`redirectHash` ignored when using Keycloak authentication

[HETO-SOPTIM]

What is the bug? We are using OpenSearch Dashboards and have this plugin enabled to log in via Keycloak SSO (OIDC). We recently noticed that hash links (such as set filters) are lost when using that login method. When returning from the OIDC login process, /auth/openid/login immediately redirects to the target page, skipping redirectUrlFragment and ignoring the previously set oidcHash.

Consider the following (simplified) location chain:

• /app/login?nextUrl=%2Fapp%2Ftest1#test2
  • (Select OIDC login option)
• /auth/openid/captureUrlFragment?nextUrl=%2Fapp%2Ftest1#test2
  • Hereafter, oidcHash is correctly set in the local storage as #test2.
• /auth/openid/login?redirectHash=true&nextUrl=%2Fapp%2Ftest1
• (OIDC login chain)
• /auth/openid/login?state=[...]&session_state=[...]&code=[...]
• /app/test1
  • Unexpected! Should have been /app/test1#test2.

What is the expected behavior? Based on openid/routes.ts, ll. 154 ff., the service should have extracted redirectHash as being true from the cookie previously set at ll. 136 ff., thereby enacting a redirect to /auth/openid/redirectUrlFragment?nextUrl=%2Fapp%2Ftest1#test2 and restoring the oidcHash once the login is complete.

The cookie itself appears functional, and nextUrl is extracted from it successfully. redirectUrlFragment and oidcHash also work as intended when forcing the former into the location chain (e.g. by starting from /app/login?nextUrl=%2Fauth%2Fopenid%2FredirectUrlFragment%3FnextUrl%3D%252Fapp%252Ftest1#test2), but this should not be a permanent workaround.

What is your host/environment?

• OS: Kubernetes/Rancher cluster
• Version: OpenSearch Dashboards v2.16.0, Security Dashboards Plugin v2.16.0.0

[cwperks]

[Triage] @HETO-SOPTIM Thank you for filing this issue. I found another issue on this repo that may be related as well: https://github.com/opensearch-project/security-dashboards-plugin/issues/1823