opensearch-project / security-dashboards-plugin

🔐 Manage your internal users, roles, access control, and audit logs from OpenSearch Dashboards
https://opensearch.org/docs/latest/security-plugin/index/
Apache License 2.0
66 stars 148 forks source link

[BUG] - 2.12 auth redirect resets query #1823

Open dhumphries-sainsburys opened 3 months ago

dhumphries-sainsburys commented 3 months ago

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

manasvinibs commented 3 months ago

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?

dhumphries-sainsburys commented 3 months ago

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'
cwperks commented 3 months ago

[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.

ubcharron commented 3 months ago

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 ?

fbegyn commented 3 months ago

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).

dhumphries-sainsburys commented 3 days ago

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