Cookie Validation fails under SecurityDashboard plugin

Security
1

Hi,

Version used (Opensearch, Opensearch) - 1.3.2 with security enabled.

I have a custom plugin written for opensearch-dashboards for authentication. The flow of the plugin is →

  • The plugin makes a REST call to keycloak server (with required user credentials) to fetch a jwt access token to contact Opensearch.
  • The plugin then uses the fetched jwt token inside the authorization header “Bearer ” and sends it in the internal call to localhost:port/app/home.
  • We get successful response from the security plugin with header cookies
    Header cookies contains below attributes:

{ username: ‘’, credentials:
{ authHeaderValue: ‘Bearer <accessToken…>’ },
authType: ‘openid’,
expiryTime: 1659347896595
}

  • The plugin then redirects to /app/home location with the same cookie getting in above steps. But its redirecting to keycloak page for authentication - so that means its not considering the cookie valid and not considering that authentication is already done.

Concerns:
The same plugin and its flow worked absolutely fine with opendistro-1.9 with Kibana 7.8.0. We see the issue from opendistro-1.13 and it continues with Opensearch 1.x releases.

If we modify the security plugin code - precisely getCookie method in openid authentication - security-dashboards-plugin/openid_auth.ts to add an extra parameter expires_at in the cookie parameters - that works fine and does not again ask for authentication on accessing /app/home as the cookie is valid.

When we normally login to Opensearch-dashboards UI, it redirects to keycloak for authentication and then redirects to /app/home.
But with internal calls from the plugin, even though authentication was successful, cookie is created with lesser parameters - as a result, it fails to work as expected.

Can you help us understand the root cause of this issue and how can we solve this?

2

@shivani Have you tested it with the latest 2.3.0?

3

@pablo No, I haven’t tested this with 2.3.0?
Do you see this as an issue in 1.x and any particular change made in 2.3.0 might have solved this?

I am still moving from Opendistro 1.9 to Opendistro 1.13/Opensearch-1.x in my application and cannot directly move to Opensearch 2.x. I still need to be able to support this functionality with 1.x before upgrading to 2.x.
Any inputs on this will be much appreciated…

4

Hi @pablo
Any inputs on above query? Do you see a particular change made in 2.3.0 Opensearch that will help in resolving this?
And any pointers on making it work in the previous versions?

5

@shivani Could you share your config.yml file?

6

Apologies, i missed seeing this update earlier. Pls find the configs:

opensearch_dashboards.yml

        server.name: opensearch-dashboards
        #server.host: 0.0.0.0
        elasticsearch.requestTimeout: 99999
        server.customResponseHeaders: { "X-Frame-Options": "DENY" }

        csp.strict: true
        #server.ssl.supportedProtocols: ["TLSv1.2"]
        #opensearch_security.cookie.secure: true
        # Whitelist basic headers and multi tenancy header
        opensearch_security.multitenancy.enabled: false
        #opensearch.requestHeadersWhitelist: [ "Authorization", "securitytenant", "x-forwarded-for", "x-proxy-user", "x-proxy-roles" ]
        opensearch_security.auth.type: "openid"
        opensearch_security.openid.connect_url: "https://keycloak.com/auth/realms/os/.well-known/openid-configuration"
        opensearch_security.openid.base_redirect_url: "https://dashboards.com/viewer"
        opensearch_security.openid.client_id: "<clientid>"
        opensearch_security.openid.client_secret: "<secret>"
        opensearch_security.openid.header: "Authorization"
        opensearch_security.openid.root_ca: "/usr/share/opensearch-dashboards/keycloak-rootca.pem"

        opensearch_security.auth.unauthenticated_routes: ["/api/status", "/customauth/v1/sso"]
        customauth.enabled: "true"
        customauth.ssoproxy.url: https://customauth-customauth-ssoproxy.default.svc.cluster.local:8444
        customauth.sco.url: http://sco-svc.credential.svc.cluster.local

(customauth is the plugin we have written, its flow mentioned above in prev comments)

And opensearch security config.yml
/usr/share/opensearch/plugins/opensearch-security/securityconfig/

       config_yml: |-
        ---
        _meta:
          type: "config"
          config_version: 2
        config:
          dynamic:
            kibana:
              multitenancy_enabled: false
              server_username: kibanaserver 
            http:
              anonymous_auth_enabled: false
              xff:
                enabled: false
                internalProxies: '.+' # since we require clientauth cert for http, we do not need to do IP filtering
                #remoteIpHeader:  'x-forwarded-for'
                #trustedProxies: '.+' # trust all external proxies, regex pattern
            authc:
              basic_internal_auth_domain:
                http_enabled: true
                transport_enabled: true
                order: 0 
                http_authenticator:
                  type: basic
                  challenge: False   # Set this to false when openid authentication is enabled
                authentication_backend:
                  type: intern
              openid_auth_domain:
                http_enabled:  True      # Set to true to enable keycloak authentication
                transport_enabled: false
                order: 1
                http_authenticator:
                  type: openid
                  challenge: false
                  config:
                    subject_key: preferred_username
                    roles_key: roles
                    openid_connect_url: https://keycloak.com/auth/realms/os/.well-known/openid-configuration
                    openid_connect_idp:
                      verify_hostnames: false
                      trust_all: false
                      enable_ssl: true
                      pemtrustedcas_filepath: "/etc/opensearch/config/certs/keycloakRootCaPem"
                authentication_backend:
                  type: noop