Our use case is to giver external users access to specific spaces, dashboards and indices in an on-prem Elastic cluster. We are using OpenID Connect authorization and Keycloak as provider.
We have configed Keycloack, Elasticsearch and Kibana as well as created a role_mapping based on groups, see attachments. In Kibana we have configured specific roles and spaces. If a user login in with basic authentication the user is granted access to the specific space, daskboards and indices. So this part of the configuration is correct.
The redirect from Kibana to Keycloak works, the users are authenticated in Keycloak, but Kibana rejects access with an HTTP 403.
No errors are found in the Elasticsearch log or in the Kibana log as well as the Kibana audit log. When running Kibana in debug or trance mode Kibana accepts the authorization, find the spaces ect, but rejects access to the specific space. We are wounding if the role_mapping is wrong or we are missing some mapping of claims.
Hi @ikakavas Do you mind to take a look at this issue?
I have read you answer to a similar post, but in our case the OP returns the expected value in the groups claim. Our case is that the OP will have several groups which must be mapped to different roles and thus spaces in Kibana
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.