Elasticsearch version: 7.10.1
Server OS version: CentOS 8
Describe the issue:
We have deployed and ELK instance protected behind a Single Sign On (SSO) system and we are using Search Guard to let the users authenticate directly through the SSO system (thus with proxy authentication enabled).
The issue we are experiencing is that Search Guard does not appear to gather the x-proxy-user from the session header (injected by the SSO system into the session). In fact, when trying to connect to Kibana, it just loads a blank page, giving out an Unauthorized Error on the file bootstrap.js (in the next sections you can find a screenshot of the error given by the browser’s console when this happens).
However, we have also tried to inject the x-proxy-user value manually into the session, by using a browser extension. In this case, not only does Kibana load normally, but it also gathers the right username (specifically, the username passed through the SSO).
Steps to verify:
In order to verify this, we have done the following:
- We manually inject the x-proxy-user value into the session (for example, x-proxy-user: “user”);
- We try to connect to Kibana. After authenticating with the SSO system, Kibana starts correctly and, instead of showing the username we injected manually (in this case, “user”), it shows the username given by the SSO (in this case “davide.malacrida”).
- However, as stated previously, if we do not inject anything manually into the session, Kibana does not appear to be loading at all.
We would expect Kibana to load correctly and gather the username by the SSO without having to inject any header manually into the session (just like it seems to be working with the x-forwarded-for session header). As of today, we have not been able to obtain this behavior without manually injecting a default value for the x-proxy-user header into the session.
Errors in browser console:
Error given when loading Kibana without manually injecting the x-proxy-user value:
We are confident this is not an SSO problem, since we can monitor the header passed by the SSO to the backend applications and these seem to be correct. We have also noticed that the x-forwarded-for header (which is also passed by the SSO system) does appear to be read correctly.
The issue has been encountered on every browser we have tried so far (Opera, Chrome, Firefox, Edge).