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
71 stars 158 forks source link

[BUG] Open ID and multi auth don't create valid cookies for pre-authenticated requests #1400

Open jochen-kressin opened 1 year ago

jochen-kressin commented 1 year ago

What is the bug? In the authentication handler, the code first looks for an authorization header before looking for credentials in the cookie to determine if the request is authenticated. Code: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/auth/types/authentication_type.ts#L113

If an authorization header is found, a cookie is constructed with the authorization header value as the credentials. Code: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/auth/types/authentication_type.ts#L118

This way, subsequent requests will be unauthenticated even if the authorization header is missing for some reason. However, for Open ID and when multi auth is enabled, the constructed cookie is not valid and subsequent requests will be unauthenticated.

Open ID

The cookie is constructed here: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/auth/types/openid/openid_auth.ts#L146 Then, the cookie is validated here: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/auth/types/openid/openid_auth.ts#L158 Please note that the expires_at attribute is missing when the cookie is constructed, which then leads to the cookie being considered invalid.

After a regular login, the expires_at attribute is read from the idToken and added to the cookie.

Multi auth

Here, the constructed cookie is empty. https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/auth/types/multiple/multi_auth.ts#L129

I'm not sure if this is intentional. It may be hard to derive the authentication type from just the header value, so maybe that's the reason why the getCookie method does not defer to another auth type in this case.

How can one reproduce the bug? Steps to reproduce the behavior:

  1. For Open ID, use a valid Bearer token in the authorization header. I used the Chrome extension ModHeader to do this.
  2. Open Dashboards without explicitly logging in. You should be able to see Dashboards as an authenticated user.
  3. Note that the security_authentication cookie is created
  4. Now, remove the authorization header and reload the page.
  5. You will be redirected to the login form

For multi auth, you need to enable it in opensearch_dashboards.yml:

opensearch_security.auth.multiple_auth_enabled: true
opensearch_security.auth.type: [basicauth, openid]

What is the expected behavior? At least for Open ID I would expect that the user is still logged in, even without the header. The credentials should be in the cookie at this point. This works with e.g. SAML.

For multi authentication, the empty cookie looks a bit more intentional, so maybe this behaviour was by choice. Otherwise I'd have expected to be logged in with a valid cookie.

What is your host/environment?

stephen-crawford commented 1 year ago

[Triage] Thank you @jochen-kressin for opening this issue. This seems like an excellent find and something that we should address to have the expected behavior.