I faced an issue, when i login the kibana ,after i login , the browser will go to https://sent2-kibana-qa.dsentience.net/logout?next=%2Fapp%2Fkibana%23%2Fhome%3F_g%3D()&msg=SESSION_EXPIRED
Environment of my ELK
two nodes for kibana, there is a loud balance those two kibabas, and SAML in enable in this environment.
when i remove one kibana, so the environment only have one kibana, i can login successfully.
here is the configuration in kibana
xpack.monitoring.elasticsearch.requestHeadersWhitelist: [ es-security-runas-user, authorization ]
the two nodes' configuration are the same.
the version of kibana and elastic is version 6.3.1
As I've also mentioned in other topics you've opened:
Please take the time to do this, it makes your post so much easier to consume and that means you have better chances of getting a response.
This is unrelated to your issue, but you only need one
in your configuration.
In order to make sure that SAML Authentication succeeds when using a load balancer in front of Kibana, you need to ensure that:
Your X Kibana instances need to use the same
xpack.security.encryptionKey. This is unrelated to SAML and would be required even if you used basic authentication for Kibana. It is required so that all Kibana instances can verify the authentication cookie that one of them generates after successful authentication, in case the user gets to a different Kibana instance (due to LB configuration) while they have an active session.
You need to setup your LB with a certain session affinity. The details of how to do that are specific to you LB, but you need to configure it in such a way so that both the
- The original request to Kibana ( Step 1 in the diagram available here )
- The final request to Kibana with the SAML Response (Step 6 in the diagram above)
reach the same Kibana instance.
The reason for that is that Kibana generates and stores the SAML Authentication RequestID in step 1 and it also passes it to Elasticsearch for verification in step 6. So if the request to step 6, reaches another Kibana instance, it would have no way to inform Elasticseach what the valid RequestID is and the authentication will fail.
The required duration for the session affinity depends on network latency and the user themselves ( how quickly they fill in the authentication form in the SAML Identity Provider, whether they are already logged in there or not, etc.) but I would start with a few minutes at least and work my way from there.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.