Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Security cookie could be too large when using JWT auth type #1638

Open
pheex opened this issue Nov 2, 2023 · 5 comments
Open

[BUG] Security cookie could be too large when using JWT auth type #1638

pheex opened this issue Nov 2, 2023 · 5 comments
Assignees
Labels
bug Something isn't working triaged

Comments

@pheex
Copy link

pheex commented Nov 2, 2023

What is the bug?
When using JWT auth type, security cookie is too large if JWT token is big, browser refuse to store it (more than 4kb) looks like #1352 is not applied to JWT auth type

How can one reproduce the bug?
Use this configuration
security-config : i use openid config only to get JWKS keyring

    openid_auth_domain:
        http_enabled: true
        transport_enabled: true
        order: 1
        http_authenticator:
          type: openid
          challenge: false
          config:
            openid_connect_idp:
              enable_ssl: true
              verify_hostnames: false
              pemtrustedcas_filepath: "/usr/share/opensearch/config/ca.crt"
            subject_key: preferred_username
            roles_key: flatten_ressources_access
            jwks_uri: {{getv "/keycloak/url"}}/realms/{{getv "/keycloak/realm"}}/protocol/openid-connect/certs
        authentication_backend:
          type: noop
      jwt_auth_domain:
        http_enabled: true
        transport_enabled: true
        order: 2
        http_authenticator:
          type: jwt
          challenge: false
          config:
            jwt_header: "Authorization"
            subject_key: preferred_username
            roles_key: flatten_ressources_access
            jwt_clock_skew_tolerance_seconds: 20
        authentication_backend:
          type: noop

opensearch_dashboard.yml

opensearch_security.auth.type: "jwt"
opensearch_security.jwt.url_param: "token"

What is the expected behavior?
Cookie should be splitted

What is your host/environment?
opensearch 2.11.0
opensearch dashboard 2.11.0

@pheex pheex added bug Something isn't working untriaged labels Nov 2, 2023
@stephen-crawford
Copy link
Contributor

[Triage] Hi @pheex thank you for filing this issue. @jochen-kressin, could you please follow-up on this since you made the original change to split cookies?

Thank you

@jochen-kressin
Copy link
Contributor

I can take care of this one

@jochen-kressin
Copy link
Contributor

jochen-kressin commented Nov 14, 2023

Hi @pheex!

Could you maybe tell me a bit more about your setup so that I know I'm testing this correctly?
For example, how is the token "delivered" to the JWT authentication in Dashboards?
You do mention opensearch_security.jwt.url_param: "token", so is my assumption correct that you are using the url query parameter?

Also, in your opensearch_dashboards.yml - do you have opensearch_security.jwt.enabled: true?

Thanks!

@jochen-kressin
Copy link
Contributor

Hi @scrawfor99,

Working on this now. So do I understand you correctly that we would like to have the exact same behaviour as for OIDC and SAML?

  1. New config options with cookie name and number of additional cookies
  2. The extra cookie(s) is/are always used
  3. We do this while still preserving "backwards compatibility" for users who already have an existing jwt cookie

Also, two other questions came up:
4. In order for the JWT authentication type to create a cookie when an authorization header is found, or when the token is passed via query parameter, at least one config option related to jwt must be manually set in opensearch_dashboards.yml - default values are not enough. Probably due to schema.maybe here: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/index.ts#L225.
Do you know if this is intentional?
I remember we had this for openid as well, but there the user would always have to configure the well-known url, so it wasn't really an issue.
5. With JWT, the logout link doesn't seem to work. The logout route is registered with an extra API_PREFIX, but the logout button does not use that prefix. Do you know if this is a known problem, or if I'm doing something wrong?

Thanks!

@pheex
Copy link
Author

pheex commented Nov 14, 2023

Hi @jochen-kressin

Yes, to test simply pass JWT token to the dashboard using query string parameter named "token"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triaged
Projects
None yet
Development

No branches or pull requests

3 participants