WARNING: Version 6.2 of the Elastic Stack has passed its EOL date.

This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.

« User Metadata Configuring Role-based Access Control »
Elastic Docs ›X-Pack for the Elastic Stack [6.2] ›Securing the Elastic Stack ›Configuring SAML Single-Sign-On on the Elastic Stack

Configuring Kibana

edit

Configuring Kibana

edit

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 also subject to the xpack.security.sessionTimeout setting that is described in the Kibana security documentation, and you may wish to adjst this timeout to meet your local needs.

The two additional settings that are required for SAML support are shown below:

xpack.security.authProviders: [saml]
server.xsrf.whitelist: [/api/security/v1/saml]

The configuration values used in the example above are:

xpack.security.authProviders
Set this to [ saml ] to instruct Kibana to use SAML SSO as the authentication method.
server.xsrf.whitelist
Kibana has in-built protection against Cross Site Request Forgery attacks which are designed to prevent the Kibana server from processing requests that originated from outside the Kibana application. In order to support SAML authentication messages that originate from your Identity Provider, we need to explicitly whitelist the SAML authentication URL within Kibana, so that the Kibana server will not reject these external messages.

If your Kibana instance is behind a proxy, you may also need to add configuration to tell Kibana how to form its public URL. This is needed because all SAML messages are exchanged via the user’s web browser, so Kibana needs to know what URLs are used within the browser. In this case, the following settings should be added to your kibana.yml configuration file:

xpack.security.public:
  protocol: https
  hostname: kibana.proxy.com
  port: 443
xpack.security.public.protocol
This is the protocol that the user’s web browser uses to connect to the proxy. Must be one of http or https. It is strongly recommended that you use the https protocol for all access to Kibana.
xpack.security.public.hostname
The fully qualified hostname that your users use to connect to the proxy server.
xpack.security.public.port
The port number that your users use to connect to the proxy server (e.g. 80 for http or 443 for https).

These values must be aligned with the URLs used in the Elasticsearch configuration for sp.acs and sp.logout.

Supporting SAML and Basic authentication in Kibana

edit

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.authProviders as per the example below:

xpack.security.authProviders: [saml, basic]

The order is important - this will initiate SAML authentication for unauthenticated users, but will accept basic authentication.

If Kibana is configured in this way, then users who wish to login with a username and password, can do so by directly accessing the /login page in Kibana. This login will not use SAML credentials, and will rely on one of the other security realms within Elasticsearch. Only users who have a username and password for a configured Elasticsearch authentication realm will be able to login via this page.

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 authentication process.

Operating multiple Kibana instances

edit

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 sp.acs value.

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_finance:
  type: saml
  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:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml_sales:
  type: saml
  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:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml_eng:
  type: saml
  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"

It is possible to have one or more Kibana instances that use SAML, while other instances use basic authentication against another realm type (e.g. Native or LDAP).

« User Metadata Configuring Role-based Access Control »