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] Security cookie could be too large when using JWT auth type #1638

Open pheex opened 11 months ago

pheex commented 11 months ago

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 https://github.com/opensearch-project/security-dashboards-plugin/pull/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

stephen-crawford commented 11 months ago

[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 commented 11 months ago

I can take care of this one

jochen-kressin commented 11 months ago

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 commented 11 months ago

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:

  1. 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.
  2. 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 commented 11 months ago

Hi @jochen-kressin

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