Use the backend roles in the correct way

I have following setup:

  1. User provides credentials to a proxy
  2. Proxy talks to keycloak and validates the user
  3. Proxy passes x-auth-username and x-auth-group to kibana
  4. Kibana is configured to get the header variables

This set up works, but I have some miss understanding related to the “backend roles”.

My Idea was: I do not need to map the users directly to the respective searchguard roles but I can use the backend role, which is coming from the proxy in x-auth-group variable. But this does not seems to work.

When I configure following in the role mapping GUI in Kibana:

the user cannot access kibana at all, even though he provides the correct backend role. In this case: SOME_RANDOM_BACKEND_ROLE

When I configure

The user has acess to kibana with the correct rights, but… what is the backend role for then? It has no effect.

It looks i miss something. Can you help me to understand how users, backend roles and search guard guard roles work together and most important: Am I able to do authorization based on the backend roles only ?


Ok i created a new built-in user with the role “SOME_RANDOM_BACKEND_ROLE” as backend role and I could successfuly be authorized in kibana just based on this backend role.

When I do the same with the user redirected from keycloak it does not work anymore and when I try to login to kibana I see following in kibana logs:


and when I try to open kibana in the browser I see following message:

{"statusCode":403,"error":"Forbidden","message":"no permissions for [indices:data/read/search] and User [name=my-user, backend_roles=[[SOME_RANDOM_BACKEND_ROLE]], requestedTenant=null]: [security_exception] no permissions for [indices:data/read/search] and User [name=my-user, backend_roles=[[SOME_RANDOM_BACKEND_ROLE]], requestedTenant=null]"}

Those double brackets look strange: backend_roles=[[SOME_RANDOM_BACKEND_ROLE]] <-- is this correct behavior? It’s differs from the logs in kibana.log. My expectation would be: backend_roles=[SOME_RANDOM_BACKEND_ROLE] or "backend_roles": ["APP_LHIND_OC_ARTIFACTORY"]


The SG roles set permissions for Elasticsearch. The backend roles don’t set the permissions for Elasticsearch. To use the backend roles you need to map them to the SG roles. There are several modes to map the roles.

Did you check the article about Keycloak and OpenID?

Thanks yes I checked that. But it is not an option at the moment. I understand that I need to map the backend roles to search guard roles. But I do not need to map the users to SG roles additionally right? So it should be enough to map the backend role to sg role and the user will be authorized accordingly right?

In short, the algorithm to setup the Keycloak OpenID is

  1. Setup Search Guard and Keycloak properly.
  2. Go to the Keycloak. Create users and roles in the Keycloak. Or maybe use Keycloak as a federation service to pull the users and roles from other sites, for example, LDAP. You shouldn’t create users in SG. SG pulls the users and their roles (backend roles) from Keycloak.
  3. Go to the Search Guard. Create roles and map the roles to the Keycloak roles (backend roles). Don’t forget about the kibanauser role. Each Keycloak user must have it assigned if you want them to access Kibana.
  4. At this point, you should be able to login to Kibana using Keycloak users.

Right, it should be enough. Double-check whether you have proper proxy authentication configuration. Kibana Proxy | Security for Elasticsearch | Search Guard

Yeah the config looks right. All the headers are passed and utilized correctly except the group header which is a list. It is okay for searchguard that the header variable contains a list, right?

It is ok to have a list there. Are you sure the proxy sends data in x-auth-group? Try to “listen” to the HTTP traffic on the Kibana host and see if you get the correct data from the proxy. For this, you can use tcpdump, tshark, wireshark, or similar software.

In the recent SG version, you have an option to debug auth. If you enable it, you can see headers in the Kibana log. But this option displays sensitive information related to the authentication, be careful to not log it permanently.


searchguard.auth.debug: true

I think I found the issue. My louketo proxy (gatekeeper) seems not to be able to handle a list of groups. In kibana Log I receive:


Which is not a list but a string with square brackets in it… I guess searchguard cannot evaluate the value

after I mapped search guard role to [SOME_RANDOM_BACKEND_ROLE] instead of SOME_RANDOM_BACKEND_ROLE the authtorization worked

I configured oidc connector for direct communication between kibana and keycloak and it worked immediately out of the box. Now need to figure out the enterprise license :slight_smile:

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.