security-dashboards-plugin icon indicating copy to clipboard operation
security-dashboards-plugin copied to clipboard

[BUG] - 2.12 auth redirect resets query

Open dhumphries-sainsburys opened this issue 11 months ago • 7 comments

Describe the bug

When a user is forced through auth redirects either for initial login or reauth after timeout the query they were navigating to or previously loaded is lost and they are directed back to the homepage of dashboards

To Reproduce Steps to reproduce the behavior:

  1. Setup an openid provider
  2. Hook up to dashboards
  3. Navigate to a known query URL assuming you do not have active auth
  4. Get directed to home

Expected behavior It load whatever you were on before the redirect took effect

OpenSearch Version 2.12

Dashboards Version 2.12

Plugins

Inbuilt Security One https://github.com/Aiven-Open/prometheus-exporter-plugin-for-opensearch

dhumphries-sainsburys avatar Mar 12 '24 14:03 dhumphries-sainsburys

Can you provide more details on the configuration? Routing to security Dashboards to look. @opensearch-project/admin Can you route this to Dashboards security plugin?

manasvinibs avatar Mar 12 '24 17:03 manasvinibs

I believe this is likely to be the relevant part of the config. We install via the helm chart approach in case that matters

opensearch_dashboards.yml: |
    opensearch.hosts: [https://opensearch-cluster-client:9200]
    opensearch.ssl.verificationMode: none
    opensearch.requestHeadersWhitelist: [authorization, securitytenant]

    opensearch_security.multitenancy.enabled: false
    opensearch_security.multitenancy.tenants.preferred: [Private, Global]
    opensearch_security.readonly_mode.roles: [kibana_dashboards]
    opensearch_security.cookie.secure: true
    opensearch_security.auth.type: "openid"
    opensearch_security.openid.connect_url: "https://dex.${env}.${infra_domain}/.well-known/openid-configuration"
    opensearch_security.openid.client_id: "opensearch"
    opensearch_security.openid.client_secret: "${opensearch_client_secret}"
    opensearch_security.openid.base_redirect_url: "https://logs.${env}.${infra_domain}"
    opensearch_security.openid.scope: "openid email profile groups offline_access"
    server.host: '0.0.0.0'

dhumphries-sainsburys avatar Mar 13 '24 11:03 dhumphries-sainsburys

[Triage] @dhumphries-sainsburys Thank you for filing this issue and providing your configuration.

There was a PR that went into 2.12 that is related to nextUrl for openid that should resolve the issue, but I see that you are using 2.12.

Could you post the network calls on login during the issue? You can contact maintainers on the OpenSearch Slack with details.

cwperks avatar Mar 18 '24 15:03 cwperks

I have the same problem on 2.12. I think "redirectHash" is getting dropped during the redirect to the IDP.

In the call to /auth/openid/login?nextUrl=%2Fosd%2Fapp%2Fdata-explorer%2Fdiscover&redirectHash=true, I noticed that the returned cookie has redirectHash set to false

{ oidc:
   { state: '...',
     nextUrl: '...',
     redirectHash: false },
  authType: 'openid' }

Then once the IDP redirects the browser to /login?code=whatever, I don't see /auth/openid/redirectUrlFragment ever getting called after.

Doesn't schema.boolean() at routes.ts#L102 convert the string to an actual boolean, so the strict equality test at routes.ts#L138 always fails ?

ubcharron avatar Apr 05 '24 00:04 ubcharron

I can confirm that this bug occurs in 2.12.0 and 2.13.0, it essentially breaks login flow for deploying the dashboard on a subpath since after logging the user end up on / (which in my case has nothing running).

fbegyn avatar Apr 09 '24 22:04 fbegyn

I can confirm this bug continues to still be present in 2.15.0 .

dhumphries-sainsburys avatar Jul 05 '24 14:07 dhumphries-sainsburys

This bug still exists on 2.15.0

ahmadabulaban avatar Jul 15 '24 11:07 ahmadabulaban