How to direct to original url when authenticating through keycloak

Search Guard
1

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

2

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.

3

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

4

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

5

Any update on this?

6

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

7

Is there an update on this?

8

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