How to direct to original url when authenticating through keycloak

[lzukel]

Searchguard version:
7.9.1-45.1.0

Elasticsearch version:
7.9.1

Server OS version:
RHEL 7

Kibana version (if relevant):
7.9.1

Describe the issue:
The first time a user visits kibana through a link to a saved visualization or dashboard, they are redirected to SSO (Keycloak), then once authenticated they are directed to the kibana home page instead of the link that they had clicked originally

Alternatively, if a user has already authenticated with SSO for Kibana, the link will take them directly to where they intended to go.

Expected behavior:
After authentication, user should be directed to the link they were trying to get to

Provide configuration:
elasticsearch/config/elasticsearch.yml

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

THIS FILE IS MANAGED BY CHEF, DO NOT EDIT MANUALLY, YOUR CHANGES WILL BE OVERWRITTEN!

Please see the documentation for further information on configuration options:

https://www.elastic.co/guide/en/elasticsearch/reference/current/settings.html

---

cluster.initial_master_nodes:

• cleared for privacy
  cluster.name: ingest-test
  node.name: _es-data0
  bootstrap.memory_lock: true
  node.data: true
  node.master: true
  node.ingest: true
  network.host: 0.0.0.0
  transport.host: 0.0.0.0
  http.compression: true
  reindex.remote.whitelist: “:443"
  path.data: “/grid/hot/0/elasticsearch/”
  path.logs: “/var/log/elasticsearch/es-data0”
  http.cors.enabled: true
  http.cors.allow-origin: "”
  http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE
  http.cors.allow-headers: X-Requested-With,X-Auth-Token,Content-Type,Content-Length
  http.detailed_errors.enabled: true
  cluster.routing.allocation.disk.watermark.low: 80%
  cluster.routing.allocation.disk.watermark.high: 85%
  cluster.routing.allocation.disk.watermark.flood_stage: 99%
  search.max_buckets: 5500
  thread_pool.write.queue_size: 10000
  xpack.ilm.enabled: true
  indices.lifecycle.poll_interval: 30m
  indices.breaker.fielddata.limit: 1%
  indices.breaker.fielddata.overhead: ‘1.03’
  indices.breaker.request.limit: 60%
  indices.breaker.request.overhead: ‘1’
  indices.breaker.total.limit: 95%
  network.breaker.inflight_requests.limit: 85%
  network.breaker.inflight_requests.overhead: ‘2’
  indices.breaker.total.use_real_memory: false
  cluster.fault_detection.follower_check.interval: 1s
  cluster.fault_detection.follower_check.timeout: 20s
  cluster.fault_detection.follower_check.retry_count: ‘5’
  cluster.fault_detection.leader_check.interval: 3s
  cluster.fault_detection.leader_check.timeout: 20s
  cluster.fault_detection.leader_check.retry_count: ‘5’
  cluster.publish.timeout: 45s
  cluster.follower_lag.timeout: 90s
  cluster.election.duration: 5s
  cluster.election.initial_timeout: 500ms
  cluster.info.update.timeout: 25s
  cluster.remote.initial_connect_timeout: 45s
  discovery.zen.join_retry_attempts: ‘10’
  discovery.zen.ping.unicast.concurrent_connects: ‘25’
  transport.connections_per_node.bulk: ‘6’
  transport.connections_per_node.reg: ‘12’
  transport.connections_per_node.ping: ‘2’
  transport.connections_per_node.state: ‘3’
  xpack.ml.enabled: false
  xpack.monitoring.enabled: true
  xpack.security.enabled: false
  xpack.sql.enabled: true
  xpack.watcher.enabled: false
  searchguard.disabled: false
  searchguard.ssl.http.enabled: true
  searchguard.ssl.transport.enforce_hostname_verification: false
  discovery.zen.ping.unicast.hosts:
• cleared for privacy
  discovery.zen.minimum_master_nodes: 2
  searchguard.enterprise_modules_enabled: true
  searchguard.ssl.transport.keystore_filepath: server.jks
  searchguard.ssl.transport.keystore_password:
  searchguard.ssl.transport.truststore_filepath: rootCA.jks
  searchguard.ssl.transport.truststore_password:
  searchguard.ssl.http.keystore_filepath: server.jks
  searchguard.ssl.http.keystore_password:
  searchguard.ssl.http.truststore_filepath: rootCA.jks
  searchguard.ssl.http.truststore_password:
  searchguard.authcz.admin_dn:
• CN=cleared for privacy
  searchguard.nodes_dn:
• CN= cleared for privacy

bootstrap.system_call_filter: false
node.attr.zone: BZ21
node.attr.rack_id: ‘005’
node.attr.box_type: prod
http.port: 9200
transport.tcp.port: 9300
node.processors: 48

searchguard.audit.type: log4j
searchguard.audit.config.log4j.logger_name: sgaudit
#searchguard.audit.config.log4j.level: INFO
searchguard.audit.config.log4j.level: TRACE
searchguard.unsupported.restapi.allow_sgconfig_modification: true
searchguard.restapi.roles_enabled: [“sg_super_admin”, “sg_all_access”]
searchguard.unsupported.restore.sgindex.enabled: true
searchguard.enable_snapshot_restore_privilege: true

kibana.yml:

#base Kibana settings
elasticsearch.requestTimeout: 90000
elasticsearch.shardTimeout: 55000
elasticsearch.ssl.verificationMode: none
elasticsearch.hosts: [“https://<es_ip>:9200”]
elasticsearch.username: “kibanaserver”
elasticsearch.password: “kibanaserver”
server.basePath: “/kibana”
server.host: “0.0.0.0”
server.port: 5601
server.ssl.enabled: true
server.ssl.certificate: /etc/kibana/server.crt
server.ssl.key: /etc/kibana/server.key
#elasticsearch.requestHeadersWhitelist: [ “Authorization”, “sgtenant”, “heimdall_jwt”, “x-forwarded-for”, “x-forwarded-server”, “x-forwarded-by”, “X-Opaque-Id”]
elasticsearch.requestHeadersWhitelist: [ “Authorization”, “sgtenant”, “heimdall_jwt”, “x-forwarded-for”, “x-forwarded-server”, “x-forwarded-by”]

#configurable Kibana features
logging.verbose: true
elasticsearch.logQueries: true
console.enabled: false
#xpack.graph.enabled: true
xpack.grokdebugger.enabled: true
xpack.searchprofiler.enabled: true
xpack.security.enabled: false
xpack.apm.ui.enabled: false
xpack.infra.enabled: false
xpack.ml.enabled: false
xpack.spaces.enabled: false
xpack.monitoring.enabled: true
xpack.securitySolution.enabled: false
xpack.uptime.enabled: false

xpack reporting configurations

xpack.reporting.encryptionKey: “12345678910”
xpack.reporting.kibanaApp: /kibana/app/kibana
xpack.reporting.kibanaServer.protocol: https
xpack.reporting.roles.allow: [“kibana-user”,“kibana-admins”]

#searchguard openid-keycloak settings.
searchguard.multitenancy.tenants.enable_private: false
searchguard.auth.type: “openid”
searchguard.openid.connect_url: “https://keycloak.<our_keycloak_url>.com/auth/realms/.well-known/openid-configuration”
searchguard.openid.client_id: “pi-searchguard”
searchguard.openid.client_secret: “”
searchguard.openid.base_redirect_url: “https://.com”
server.rewriteBasePath: false
searchguard.accountinfo.enabled: true
searchguard.openid.scope: roles
searchguard.openid.root_ca: “/etc/kibana/root_ca.pem”
searchguard.openid.verify_hostnames: false
searchguard.readonly_mode.roles: [“kibana_dashboard_only_user”]
searchguard.cookie.ttl: 28800000
searchguard.session.ttl: 28800000
searchguard.session.keepalive: true

#Other kibana settings
telemetry.enabled: false
csp.warnLegacyBrowsers: true

[srgbnd]

Hi. Thank you for reporting this. It is a duplicate of the following issue Cannot reach Kibana dashboard URL after Keycloak (openid) login We work on it. I’ll let you know.

[Mike]

Hi @lzukel,

Could you please share an example of a dashboard or visualization URL?
Does it look something like this?
https://localhost:5601/app/dashboards#/view/edf84fe0-e1a0-11e7-b6d5-4dc382ef7f5b?_g=(filters:!(),refresh...

I can reproduce that the part after the #-symbol gets lost after authentication, but I’m a bit confused about the fact that you are redirected to the Kibana home page, and not the dashboard overview (https://localhost:5601/app/dashboards)

I’ll keep digging though.

Thanks,
Mike

[lzukel]

@Mike
This is pretty much the same thing we are experiencing.

[lzukel]

Any update on this?

[srgbnd]

Hi @lzukel We work on the issue. It is not trivial. I’ll let you know when it is solved.

[lzukel]

Is there an update on this?

[srgbnd]

The issue was solved in the release 49.0.0 Latest Releases | Security for Elasticsearch | Search Guard