What responses for kibana js requests would make it close the GUI when proxy based authentication is enabled

Search Guard
#1

Kibana session doesn’t expired properly when proxy base authentication is enabled as searchguard has no control over the session, referring to older discussion

Blockquote
Kibana session doesn't expire in a expected time when proxy based authentication is enabled
Blockquote

Could you please help us that , is it possible to know what responses for kibana js requests would make it close the GUI and redirect to the login page (if ever possible), or at least close with a message to relogin-manually.

Thanks.
Subhashree

#2

There is no mechanism in the HTTP specification for the server to tell the browser to stop sending the credentials that the user already presented. There are some hacks but they are not reliable.


To expire sessions, use one of our authentication modes: basic, OpenID, SAML, etc. https://docs.search-guard.com/latest/kibana-authentication-http-basic

#3

What is your use-case? Where do you store the user accounts?

#4

our usercase is as below ,
We use proxy-based authentication where ingress is used as proxy which does the authentication and redirects to kibana with user details in the header. In our case, if the kibana session is open for too long time and when the session expires, we get the error related to bundle js when try to do some action(like a filter).
And in this case user will be unaware of the error & will be confused.
posting the screenshot here.

kibana_session_expired
kibana_session_expired1471×409 127 KB

Instead of this as a solution to this problem , is it possible to send certain respoanse code from proxy ,so that can kibana close with a message like ex. “session expired re-login manually” ?

#5

Where do you store the user accounts? What version of SG do you use?

#6

Hi ,
We use keycloak for storing the user accounts & nginx ingress as the proxy.
Searchguard version used is : 7.8.0-43.0.0.

#7

A possible solution could be redirecting the user whose session is expired to some URL. I will raise this question internally and we shall see what can be done.

Given you have already Keycloack, you can setup OpenID connect authentication as a solution.

#8

Hi , Thanks for the above response.
The second point “setup OpenID connect authentication as a solution” would not be valid for our use-case.
We would like to wait for the solution mentioned on the first point ,“A possible solution could be redirecting the user whose session is expired to some URL”.

#9

Hi @srgbnd
Could you please provide any update about the implementation of this point which you have shared in the previously that -“A possible solution could be redirecting the user whose session is expired to some URL”.

#10

Hi @shubha02
This is still in the queue. Because the problem is not trivial. I’ll ping you when there is something to try.

#11

Sure, we will wait for this matter. Thank you.

#12

Can you send your kibana.yml?

#13

Hi @srgbnd
here is the kibana configmap used -

kibana.yml: |-
    ---
    # Donot change sever name and host. This is default configuration.
    server.name: kibana
    server.host: "0"
    server.customResponseHeaders: { "X-Frame-Options": "DENY" }
    server.ssl.supportedProtocols: ["TLSv1.2"]
    # # Whitelist basic headers and multi tenancy header
    elasticsearch.requestHeadersWhitelist: [ "Authorization", "sgtenant", "x-forwarded-for", "x-proxy-user", "x-proxy-roles" ]
    searchguard.auth.type: "proxy"
    searchguard.basicauth.enabled: false
    elasticsearch.requestTimeout: 90000

Please let me know in case you need any other information .

#14

But the Keycloak is not integrated with Search Guard, isn’t it? If it is integrated, please share sg_config.yml.

#15

Here is the sg_config.yaml

sg_config.yml: |-
    ---
    _sg_meta:
      type: config
      config_version: 2
    sg_config:
      dynamic:
        http:
          anonymous_auth_enabled: false
          xff:
            enabled: true
            internalProxies: .+
            remoteIpHeader: x-forwarded-for
        authc:
          basic_internal_auth_domain:
            http_enabled: true
            transport_enabled: true
            order: 0
            http_authenticator:
              type: basic
              challenge: false
            authentication_backend:
              type: internal
          proxy_auth_domain:
            http_enabled: true
            transport_enabled: true
            order: 1
            http_authenticator:
              type: proxy
              challenge: false
              config:
                user_header: x-proxy-user
                roles_header: x-proxy-roles
            authentication_backend:
              type: noop
          clientcert_auth_domain:
            http_enabled: false
            transport_enabled: false
            order: 2
            http_authenticator:
              challenge: false
              type: clientcert
              config:
                username_attribute: cn
            authentication_backend:
              type: noop
#16

Hi @srgbnd , Did you get a chance to look for the above query?

#17

Hi @shubha02! I didn’t forget. It is still in the issues queue. Probably we address it in the next 1-2 releases. Recently Kibana makes us busy with the New Platform changes.

#18

Is NGINX somehow integrated with Keycloak? I don’t see any Keycloak integration in Kibana or SG config. It looks like the users are stored in the SG internal database.

After what time approximately the session expires for you?

Can you share the NGINX configuration?

#19

Hi @srgbnd
Yes, NGINX is integrated with keycloak. The users are not stored in the SG internal database ,we are sending only proxy headers to Kibana.
Below is the NGINX configuration.

kind: Ingress
metadata:
  annotations:
    XXXX/platform-shared-addresses: |
      {"PLATFORM_LOGS_EXTERNAL_ADDRESS": "https://IP/XXXX"}
    ingress.citm.XXXX.com/sticky-route-services: $cookie_JSESSIONID|JSESSIONID ip_cookie
    kubernetes.io/ingress.class: oam
    nginx.ingress.kubernetes.io/configuration-snippet: |
      more_clear_headers 'X-Frame-Options';
      access_by_lua_block {
        local paas = require "paas"
        local res = paas.checkAuth()
        local roles = ""
        local cluster = os.getenv("DOMAIN_NAME"):gsub("^oam", ""):match("([%w%-]+)%..+$")
        local compaasAdmin = "c:admin:"..cluster

 

        cluster = string.gsub(cluster, "%-", "%%-")
        for i,v in ipairs(res.id_token.groups) do
          if v == compaasAdmin then
            roles = roles .. "compaas:admin,"
          else
            local tenant = v:match("n:[a-z]+:"..cluster.."%.[%w%-]+%.([%w%-]+)")
            if tenant then
              local tenant_type = v:match("n:([a-z]+):")
              if tenant_type == "monitor" then
                roles = roles .. tenant .. "_monitor,"
              else
                roles = roles .. tenant .. ","
              end
            end
          end
        end
        ngx.req.set_header("x-proxy-user", res.id_token.preferred_username)
        -- remove last comma from string
        ngx.req.set_header("x-proxy-roles", roles:sub(1, -2))
      }
    nginx.ingress.kubernetes.io/limit-connections: "50"
    nginx.ingress.kubernetes.io/limit-rpm: "600"
    nginx.ingress.kubernetes.io/limit-rps: "50"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "120"
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/secure-backends: "true"
    nginx.ingress.kubernetes.io/ssl-passthrough: "false"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  creationTimestamp: "2020-12-16T17:15:45Z"
  generation: 1
  name: Namespace.XXXX.5601
  namespace: XXXX
  resourceVersion: "206623"
  selfLink: /apis/extensions/v1beta1/namespaces/xxxx/ingresses/Namespace.XXXX.5601
  uid: 26393be3-a51c-4bbd-b7a4-76398a4e6d5a
spec:
  rules:
  - host: XXXX
    http:
      paths:
      - backend:
          serviceName: kibana
          servicePort: 5601
        path: /xxxx/?(.*)

Approximately after 1 hour of time the session getting time out.
Thanks.

#20

Hi. Do you have 2 different clusters? I mean, in the current issue you talk about the proxy authentication set in kibana.yml, and in the following issue you have OpenID authentication type in kibana.yml "searchguard_authentication" cookie remains hanging in the browser