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.
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:
For Open ID, use a valid Bearer token in the authorization header. I used the Chrome extension ModHeader to do this.
Open Dashboards without explicitly logging in. You should be able to see Dashboards as an authenticated user.
Note that the security_authentication cookie is created
Now, remove the authorization header and reload the page.
You will be redirected to the login form
For multi auth, you need to enable it in opensearch_dashboards.yml:
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?
OS: Mac OS
Version I used the main branch from this repository
[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.
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:
For multi auth, you need to enable it in
opensearch_dashboards.yml
: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?