SearchGuard and OIDC

Search Guard
1

If you think it is a bug report or you have a technical issue, please answer the following questions.

Elasticsearch version:

8.19.19

Kibana version (if relevant):

8.19.19

Describe the issue:

I’m currently trying to configure OIDC in Kibana. Kibana is behind a Apache reverse proxy. I have problems with the settings and the documentation.

The configuration file is

---
_sg_meta:
  type: "frontend_authc"
  config_version: 2

default:
  debug: true
  auth_domains:
    - type: basic
      label: "Login"
    - type: oidc
      oidc:
        client_id: "kibanadev"
        client_secret: "XXXX"
        get_user_info: true
        use_dynamic_frontend_url: true
         idp:
          openid_configuration_url: "https://XXXXX/oidc/.well-known/openid-configuration"
      user_mapping:
        roles:
          from_comma_separated_string: "oidc_id_token.roles"

First point the _sg_meta is not provided in the documentation Kibana OIDC Quick Start | Security for Elasticsearch | Search Guard. I’m not sure if it’s mandatory or not.

The documentation talks about use_pkce, but when I add it in the file, I got

$ sudo java -Xmx1G -jar sgctl update-config  --sgctl-config-dir=.../sgconf --debug /tmp/dev/sg_frontend_authc.yml 

Selected cluster: development
------------------------------------------------
HTTP/1.1 200 OK
Content-Type: application/json
{"user":"User O=XXXX<tls_cert>","user_name":"XXXX","user_requested_tenant":null,"remote_address":null,"backend_roles":[],"attribute_names":[],"sg_roles":[],"sg_ten...
------------------------------------------------
Successfully connected to cluster development (esdev02.XXXX) as user XXXX
Uploading config files: sg_frontend_authc.yml
------------------------------------------------
HTTP/1.1 400 Bad Request
Content-Type: application/json
{"status":400,"error":{"message":"'frontend_authc.default.auth_domains.1.oidc.use_pkce': Unsupported attribute","details":{"frontend_authc.default.auth_domains.1.oidc.use_pkce":[{"error":"Unsupported attribute","value":"true"}]}}}
------------------------------------------------
Invalid config files:

/tmp/dev/sg_frontend_authc.yml:
  default.auth_domains.1.oidc.use_pkce:
  	Unsupported attribute

use_pkce is described the Elastic plugin source code. But it’s seems to be missing in the Kibana plugin.

I also a problem in the callback URL. As it’s behind a reverse proxy, it’s resolved as http://localhost:5602/auth/openid/login that will obviously fails. The document says to configure use_dynamic_frontend_url to control the usage of frontend_base_url. I tried to then set default.auth_domains.1.oidc.idp.frontend_base_url to “https://XXXX/auth/openid/login” and efault.auth_domains.1.oidc.use_dynamic_frontend_url to false, but now the callback URL is the quite strange https://XXXX:5601/auth/openid/login instead of localhost. I don’t know how I can handle that.

2

I solved my callback URL problem. I set use_dynamic_frontend_url to false and fixed a bug in kibana.yml, the plugin uses the value of server.publicBaseUrl that was incorrectly set in my case.

I now have another problem. I added a custom profiles groups with the claim memberOf that return the attribute memberOf as extracted from ActiveDirectory. But it’s parsed with the value user_mapping.roles.from_comma_separated_string. That does not fit a list of DN where the real separator is , .

3

Hello @fbacchella

Are these roles included in the token in DN format, or is the CN extracted for each role?

Regarding use_pkce option, the documentation is incorrect. The correct setting is oidc.pkce .

4

It was only a documentation problem. OIDC can provide the group list as an array of group, so the best solution is not to use from_comma_separated_string but directly from the userinfo endpoint.

To sum up, I see 3 possible improvement to do in the documentation
— correct the use_pcke
— In the Dynamic Frontend URL section, explain more clearly that the used settings is server.publicBaseUrl, and use_dynamic_frontend_url should be set to false. I don’t even understand the purpose of this in Advanced settings, it generated confusion with the settings in Kibana setup section that is correct.
— The from_comma_separated_string is a fails back settings, and it’s only used if the groups list provided is not correctly generated from the idp.

5

Another small improvement that can be done. In my OIDC server, I see in the logs
[2026-09-18 11:23:41] 10.xx.xx9.xx “XXXX” “GET /oidc/.well-known/openid-configuration HTTP/1.1” 5420 200 + 4540 “-” “Apache-HttpClient/4.5.14 (Java/25.0.4.1)”

Providing an helpfull User-Agent string like “SearchGuard/XX ElasticSearch/XXX” would be nice to identify logs.