SAML authentication in Kibana requires a small number of additional settings in addition to the standard Kibana security configuration. The Kibana security documentation provides details on the available configuration options that you can apply.
In particular, since your Elasticsearch nodes have been configured to use TLS on the HTTP
interface, you must configure Kibana to use a
https URL to connect to Elasticsearch, and
you may need to configure
elasticsearch.ssl.certificateAuthorities to trust
the certificates that Elasticsearch has been configured to use.
SAML authentication in Kibana is subject to the following timeout settings in
You may want to adjust these timeouts based on your security requirements.
The three additional settings that are required for SAML support are shown below:
xpack.security.authc.providers: saml.saml1: order: 0 realm: "saml1"
The configuration values used in the example above are:
samlprovider to instruct Kibana to use SAML SSO as the authentication method.
Set this to the name of the SAML realm that you have used in your Elasticsearch realm configuration, for instance:
The SAML support in Kibana is designed on the expectation that it will be the
primary (or sole) authentication method for users of that Kibana instance.
However, it is possible to support both SAML and Basic authentication within a
single Kibana instance by setting
xpack.security.authc.providers as per the
xpack.security.authc.providers: saml.saml1: order: 0 realm: "saml1" basic.basic1: order: 1
If Kibana is configured in this way, users are presented with a choice at the Login Selector UI. They log in with SAML or they provide a username and password and rely on one of the other security realms within Elasticsearch. Only users who have a username and password for a configured Elasticsearch authentication realm can log in via Kibana login form.
Alternatively, when the
basic authentication provider is enabled, you can
place a reverse proxy in front of Kibana, and configure it to send a basic
authentication header (
Authorization: Basic ....) for each request.
If this header is present and valid, Kibana will not initiate the SAML
If you wish to have multiple Kibana instances that authenticate against the same Elasticsearch cluster, then each Kibana instance that is configured for SAML authentication, requires its own SAML realm.
Each SAML realm must have its own unique Entity ID (
sp.entity_id), and its own
Assertion Consumer Service (
sp.acs). Each Kibana instance will be mapped to
the correct realm by looking up the matching
These realms may use the same Identity Provider, but are not required to.
The following is example of having 3 difference Kibana instances, 2 of which use the same internal IdP, and another which uses a different IdP.
xpack.security.authc.realms.saml.saml_finance: order: 2 idp.metadata.path: saml/idp-metadata.xml idp.entity_id: "https://sso.example.com/" sp.entity_id: "https://kibana.finance.example.com/" sp.acs: "https://kibana.finance.example.com/api/security/v1/saml" sp.logout: "https://kibana.finance.example.com/logout" attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1" attributes.groups: "urn:oid:184.108.40.206.4.1.59220.127.116.11." xpack.security.authc.realms.saml.saml_sales: order: 3 idp.metadata.path: saml/idp-metadata.xml idp.entity_id: "https://sso.example.com/" sp.entity_id: "https://kibana.sales.example.com/" sp.acs: "https://kibana.sales.example.com/api/security/v1/saml" sp.logout: "https://kibana.sales.example.com/logout" attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1" attributes.groups: "urn:oid:18.104.22.168.4.1.5922.214.171.124." xpack.security.authc.realms.saml.saml_eng: order: 4 idp.metadata.path: saml/idp-external.xml idp.entity_id: "https://engineering.sso.example.net/" sp.entity_id: "https://kibana.engineering.example.com/" sp.acs: "https://kibana.engineering.example.com/api/security/v1/saml" sp.logout: "https://kibana.engineering.example.com/logout" attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"