The Elastic Stack supports Security Assertion Markup Language Single Sign On (SAML SSO)
into Kibana with Elasticsearch as a backend service. In particular, the Elastic Stack supports
the SAML 2.0 Web Browser SSO and the SAML 2.0 Single Logout profiles. It can
integrate with any identity provider (IdP) that supports at least the SAML 2.0
Web Browser SSO Profile.

The Elasticsearch SAML implementation makes use of the Elasticsearch Token Service. This service
is automatically enabled if you configure TLS on the HTTP interface. You can
explicitly enable it by including the following setting in your
elasticsearch.yml file:

xpack.security.authc.token.enabled: true

Configure a SAML IdP metadata file.

The Elastic Stack uses a standard SAML metadata document in XML format, which defines
the capabilities and features of your identity provider. You should be able to
download or generate such a document within your IdP administration interface.

Most IdPs will provide an appropriate metadata file with all the features that
the Elastic Stack requires. For more information, see
The identity provider.

Download the IdP metadata document and store it within the config directory
on each Elasticsearch node. For example, store it as config/saml/idp-metadata.xml.

Get the identifier for your identity provider.

The IdP will have been assigned an identifier (EntityID in SAML terminology),
which is most commonly expressed in Uniform Resource Identifier (URI) form. Your
admin interface might tell you what this is or you might need to read the
metadata document to find it. Look for the entityID attribute on the
EntityDescriptor element.

Create one or more SAML realms.

SAML authentication is enabled by configuring a SAML realm within the
authentication chain for Elasticsearch.

This realm has a few mandatory settings, and a number of optional settings.
The available settings are described in detail in the
SAML realm settings. The following settings (in the elasticsearch.yml
configuration file) are the most common settings:

The realm must be within the xpack.security.authc.realms.saml namespace.

This setting defines a new authentication realm named "saml1". For an
introduction to realms, see Realms.

You should define a unique order on each realm in your authentication chain.
It is recommended that the SAML realm be at the bottom of your authentication
chain (that is, it has the highest order).

This is the path to the metadata file that you saved for your identity provider.
The path that you enter here is relative to your config/ directory. Elasticsearch
automatically monitors this file for changes and reloads the configuration
whenever it is updated.

This is the identifier (SAML EntityID) that your IdP uses. It should match
the entityID attribute within the metadata file.

This is a unique identifier for your Kibana instance, expressed as a URI.
You will use this value when you add Kibana as a service provider within your IdP.
We recommend that you use the base URL for your Kibana instance as the entity ID.

The Assertion Consumer Service (ACS) endpoint is the URL within Kibana that
accepts authentication messages from the IdP. This ACS endpoint supports the
SAML HTTP-POST binding only. It must be a URL that is accessible from the web
browser of the user who is attempting to login to Kibana; it does not need to be
directly accessible by Elasticsearch or the IdP. The correct value can vary depending on
how you have installed Kibana and whether there are any proxies involved, but it
is typically ${kibana-url}/api/security/v1/saml where ${kibana-url} is the
base URL for your Kibana instance.

This is the URL within Kibana that accepts logout messages from the IdP.
Like the sp.acs URL, it must be accessible from the web browser, but does
not need to be directly accessible by Elasticsearch or the IdP. The correct value can
vary depending on how you have installed Kibana and whether there are any
proxies involved, but it will typically be ${kibana-url}/logout where
${kibana-url} is the base URL for your Kibana instance.

SAML is used when authenticating via Kibana, but it is not an
effective means of authenticating directly to the Elasticsearch REST API. For this reason
we recommend that you include at least one additional realm such as the
native realm in your authentication chain for use by API clients.

When a user connects to Kibana through the identity provider, the IdP supplies a
SAML assertion that includes attributes for the user. You can configure the SAML
realm to map these attributes to properties on the authenticated user.

The recommended steps for configuring these SAML attributes are as follows:

Consult your IdP to see what user attributes it can provide. This varies
greatly between providers, but you should be able to obtain a list from the
documentation or from your local admin.

Read through the list of user properties that Elasticsearch supports and decide which
of them are useful to you and can be provided by your IdP. At a minimum, the
principal attribute is required. The groups attribute is recommended.

Configure your IdP to release those attributes to your Kibana SAML service
provider.

This process varies by provider - some provide a user interface for this, while
others might require that you edit configuration files. Usually the IdP (or your
local administrator) have suggestions about what URI to use for each attribute.
You can simply accept those suggestions, as the Elasticsearch service is entirely
configurable and does not require that any specific URIs are used.

Configure the SAML realm to associate the Elasticsearch user properties to the URIs
that you configured in your IdP.

For example, add the following settings to the elasticsearch.yml configuration
file:

You can configure Elasticsearch for signing, encryption, or both, with the same or
separate keys. For more information, see
Encryption and signing.

(Optional) Generate service provider metadata.

There are some extra configuration steps that are specific to each identity
provider. If your identity provider can import SP metadata, some of those steps
can be automated or expedited. You can generate SP metadata for the Elastic Stack by
using the elasticsearch-saml-metadata command.

Configure role mappings.

When a user authenticates using SAML, they are identified to the Elastic Stack,
but this does not automatically grant them access to perform any actions or
access any data.