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] Session expiration and keepalive settings ignored #2021

Open
hagaram opened this issue Jul 3, 2024 · 2 comments
Open

[BUG] Session expiration and keepalive settings ignored #2021

hagaram opened this issue Jul 3, 2024 · 2 comments
Labels
bug Something isn't working triaged

Comments

@hagaram
Copy link

hagaram commented Jul 3, 2024

What is the bug?
These options seems to be ignored

opensearch_security.cookie.ttl: 86400000
opensearch_security.session.ttl: 86400000
opensearch_security.session.keepalive: true

I have no issue with frequent logouts, but with that that cookie is set as “session cookie” regardless of what I configure. This also happens when local account is used (tried with admin) - only difference is that with local login there is one cookie set: security_authentication
With oidc login there is security_authentication AND security_authentication_oidc1.

In both cases the cookie is deleted after browser is closed. If I modify expiration date of cookie, everything work after closing and reopening the browser, but security_authentication is set back to session cookie, so I have to change it back with expiration, if I want to to live trought another browser closing.

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

  1. Log in to opensearch dashboards and inspect the cookies
  2. close browser
  3. open browser
  4. relogin is needed and cookies are gone

What is the expected behavior?
Continue work with OSD without the need to relogin again

What is your host/environment?

  • OS: Linux
  • Version 2.15 (also happened on 2.14)

Do you have any additional context?

  • OSD is on 3 servers with nginx in fornt of it which does the balancing. This unfortunately happens also when I go to specific dashboard directly, with local account, bypassing nginx.
  • I use keycloak OIDC + default basic auth login
@hagaram hagaram added bug Something isn't working untriaged labels Jul 3, 2024
@stephen-crawford
Copy link
Contributor

[Triage] Hi @hagaram thanks for filing this issue. @derek-ho has taken a look at similar issue in the past so will check into this use case and see if that is something we are able to support.

@hagaram
Copy link
Author

hagaram commented Jul 8, 2024

@scrawfor99 @derek-ho Thank you very much for taking a look at this.

If it helps anything, here is OSD config.

server.port: 5601
server.host: "0.0.0.0"
opensearch.hosts: ["https://xxxx.XXXXXXXX:9200","https://xxx.XXXXXXXX:9200","https://xxx.XXXXXXXX:9200"]
opensearch.username: "XXXXXXXXXX"
opensearch.password: "XXXXXXXXXX"
opensearch.requestHeadersWhitelist: [ authorization,securitytenant ]

opensearch_security.multitenancy.enabled: false
# opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
opensearch_security.multitenancy.tenants.enable_global: true
opensearch_security.readonly_mode.roles: ["kibana_read_only"]


opensearch.ssl.verificationMode: "full"
opensearch.ssl.certificate: "/usr/share/opensearch-dashboards/config/esnode.pem"
opensearch.ssl.key: "/usr/share/opensearch-dashboards/config/esnode-key.pem"
opensearch.ssl.certificateAuthorities: [ "/usr/share/opensearch-dashboards/config/root-ca.pem" ]
server.ssl.enabled: true
server.ssl.certificate: /usr/share/opensearch-dashboards/config/rest-esnode.pem
server.ssl.key: /usr/share/opensearch-dashboards/config/rest-esnode-key.pem
server.ssl.certificateAuthorities: [ "/usr/share/opensearch-dashboards/config/rest-root-ca.pem" ]

opensearch_security.cookie.secure: true

# OpenID settings -> IDP used is Keycloak
opensearch_security.auth.type: ["basicauth","openid"]
opensearch_security.auth.multiple_auth_enabled: true

opensearch_security.openid.base_redirect_url: "https://xXXXXXX.XXXXXXXX"
opensearch_security.openid.client_id: "XXXXXXX.XXXXXXXX"
opensearch_security.openid.scope: "openid profile email"
opensearch_security.openid.client_secret: "XXXXXXXXX"
opensearch_security.openid.connect_url: "https://XXXXX.XXXXXX.XXXXX/realms/XXXXXX/.well-known/openid-configuration"
opensearch_security.openid.verify_hostnames: true



opensearch_security.cookie.ttl: 86400000
opensearch_security.session.ttl: 86400000
#I've tried to change the bellow two setting to true/false - no effect regarding this issue
#opensearch_security.session.keepalive: false
#opensearch_security.openid.refresh_tokens: true
opensearch_security.ui.openid.login.buttonname: "Sign in with XXXXXX ID"

And here is security plugins config

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: ".*"
        remoteIpHeader: "x-forwarded-for"
    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: false
        order: 0
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: internal
      openid_auth_domain:
        description: "Authenticate via Keycloak"
        http_enabled: true
        transport_enabled: true
        order: 1
        http_authenticator:
          type: openid
          challenge: false
          config:
            enable_ssl: true
            verify_hostnames: true
            subject_key: preferred_username
            roles_key: roles
            openid_connect_url: https://XXXXXX.XXXXX.XXXXX/realms/XXXXXX/.well-known/openid-configuration
            kibana_url: https://XXXXX.XXXXX.XXXXX
        authentication_backend:
          type: noop
    authz: {}
    ```

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

2 participants