Kibana supports the following authentication mechanisms:
To successfully log in to Kibana, basic authentication requires a username and password. Basic authentication is enabled by default, and is based on the Native security realm or LDAP security realm that is provided by Elasticsearch. The basic authentication provider uses a Kibana provided login form, and supports authentication using the
Authorization request header
The session cookies that are issued by the basic authentication provider are stateless. Therefore, logging out of Kibana when using the basic authentication provider clears the session cookies from the browser, but does not invalidate the session cookie for reuse.
For more information about basic authentication and built-in users, see User authentication.
Token authentication allows users to login using the same Kibana provided login form as basic authentication, and is based on the Native security realm or LDAP security realm that is provided by Elasticsearch. The token authentication provider is built on Elasticsearch token APIs. The bearer tokens returned by Elasticsearch’s get token API can be used directly with Kibana using the
Authorization request header with the
The session cookies that are issued by the token authentication provider are stateful, and logging out of Kibana invalidates the session cookies for reuse.
Prior to configuring Kibana, ensure token support is enabled in Elasticsearch. See the Elasticsearch token API documentation for more information.
To enable the token authentication provider in Kibana, set the following value in your
The token authentication provider can be used in conjunction with the basic authentication provider. The login form will continue to use the token authentication provider, while enabling applications like
curl to use the
Authorization request header with the
Basic scheme. Set the following in your
kibana.yml, maintaining the order of the auth providers:
xpack.security.authc.providers: [token, basic]
PKI authentication will not work if Kibana is hosted behind a TLS termination reverse proxy. In this configuration, Kibana does not have direct access to the client certificates and cannot authenticate the user.
PKI authentication allows users to log into Kibana using X.509 client certificates that must be presented while connecting to Kibana. The certificates must first be accepted for authentication on the Kibana TLS layer, and then they are further validated by an Elasticsearch PKI realm. The PKI authentication provider relies on the Elasticsearch Delegate PKI authentication API to exchange X.509 client certificates to access tokens. All subsequent requests to Elasticsearch APIs on behalf of users will be authenticated using these access tokens.
Prior to configuring Kibana, ensure that the PKI realm is enabled in Elasticsearch and configured to permit delegation. See Configuring a PKI realm for more information.
To enable the PKI authentication provider in Kibana, you must first configure Kibana to encrypt communications between the browser and Kibana server. You must also enable TLS client authentication and include the certificate authority (CA) used to sign client certificates into a list of CAs trusted by Kibana in your
server.ssl.certificateAuthorities: /path/to/your/cacert.pem server.ssl.clientAuthentication: required xpack.security.authc.providers: [pki]
PKI support in Kibana is designed to be the primary (or sole) authentication method for users of that Kibana instance. However, you can configure both PKI and Basic authentication for the same Kibana instance:
xpack.security.authc.providers: [pki, basic]
Note that with
server.ssl.clientAuthentication set to
required, users are asked to provide a valid client certificate, even if they want to authenticate with username and password. Depending on the security policies, it may or may not be desired. If not,
server.ssl.clientAuthentication can be set to
optional. In this case, Kibana still requests a client certificate, but the client won’t be required to present one. The
optional client authentication mode might also be needed in other cases, for example, when PKI authentication is used in conjunction with Reporting.
SAML authentication allows users to log in to Kibana with an external Identity Provider, such as Okta or Auth0. Make sure that SAML is enabled and configured in Elasticsearch before setting it up in Kibana. See Configuring SAML single sign-on on the Elastic Stack.
Set the configuration values in
kibana.yml as follows:
Enable the SAML authentication:
Kibana needs to specify which SAML realm in Elasticsearch should be used:
The Identify Provider sends authentication requests to the
Assertion Consumer Serviceendpoint that Kibana exposes through a "non-safe"
POSTHTTP method. This does not include CSRF protection HTTP headers specific to Kibana. You must disable the CSRF check for this endpoint.
Users will be able to log in to Kibana via SAML Single Sign-On by navigating directly to the Kibana URL. Users who aren’t authenticated are redirected to the Identity Provider for login. Most Identity Providers maintain a long-lived session—users who logged in to a different application using the same Identity Provider in the same browser are automatically authenticated. An exception is if Elasticsearch or the Identity Provider is configured to force user to re-authenticate. This login scenario is called Service Provider initiated login.
SAML support in Kibana is designed to be the primary (or sole) authentication method for users of that Kibana instance. However, you can configure both SAML and Basic authentication for the same Kibana instance:
xpack.security.authc.providers: [saml, basic]
The order of
basic is important. Users who open Kibana will go through the SAML Single Sign-On process unless the direct Basic authentication
/login link is used. This might be the case for Kibana or Elasticsearch admins whose accounts aren’t linked to the Single Sign-On users database. Or, when the
Authorization: Basic base64(username:password) HTTP header is included in the request (for example, by reverse proxy).
Basic authentication is supported only if
basic authentication provider is explicitly declared in
xpack.security.authc.providers setting in addition to
At the beginning of the SAML handshake, Kibana stores the initial URL in the session cookie, so it can redirect the user back to that URL after successful SAML authentication. If the URL is long, the session cookie might exceed the maximum size supported by the browser—typically 4KB for all cookies per domain. When this happens, the session cookie is truncated, or dropped completely, and you might experience sporadic failures during SAML authentication.
To remedy this issue, you can decrease the maximum size of the URL that Kibana is allowed to store during the SAML handshake. The default value is 2KB.
Similar to SAML, authentication with OpenID Connect allows users to log in to Kibana using an OpenID Connect Provider such as Google, or Okta. OpenID Connect should also be configured in Elasticsearch. For more details, see Configuring single sign-on to the Elastic Stack using OpenID Connect.
Set the configuration values in
kibana.yml as follows:
Enable the OpenID Connect authentication:
Kibana needs to specify which OpenID Connect realm in Elasticsearch should be used, in case there are more than one configured there.
Kibana supports Third Party initiated Single Sign On, which might start with an external application instructing the user’s browser to perform a "non-safe"
POSTHTTP method. This request will not include CSRF protection HTTP headers that are required by Kibana. If you want to use Third Party initiated SSO , then you must disable the CSRF check for this endpoint.
Similar to SAML, OpenID Connect support in Kibana is designed to be the primary (or sole) authentication method for users of that Kibana instance. However, you can configure both OpenID Connect and Basic authentication for the same Kibana instance:
xpack.security.authc.providers: [oidc, basic]
Users will be able to access the login page and use Basic authentication by navigating to the
Once the user logs in to Kibana Single Sign-On, either using SAML or OpenID Connect, Elasticsearch issues access and refresh tokens
that Kibana encrypts and stores them in its own session cookie. This way, the user isn’t redirected to the Identity Provider
for every request that requires authentication. It also means that the Kibana session depends on the
setting and the user is automatically logged out if the session expires. An access token that is stored in the session cookie
can expire, in which case Kibana will automatically renew it with a one-time-use refresh token and store it in the same cookie.
Kibana can only determine if an access token has expired if it receives a request that requires authentication. If both access and refresh tokens have already expired (for example, after 24 hours of inactivity), Kibana initiates a new "handshake" and redirects the user to the external authentication provider (SAML Identity Provider or OpenID Connect Provider) Depending on Elasticsearch and the external authentication provider configuration, the user might be asked to re-enter credentials.
If Kibana can’t redirect the user to the external authentication provider (for example, for AJAX/XHR requests), an error indicates that both access and refresh tokens are expired. Reloading the current Kibana page fixes the error.
During logout, both the Kibana session cookie and access/refresh token pair are invalidated. Even if the cookie has been leaked, it can’t be re-used after logout. This is known as "local" logout.
Kibana can also initiate a "global" logout or Single Logout if it’s supported by the external authentication provider and not explicitly disabled by Elasticsearch. In this case, the user is redirected to the external authentication provider for log out of all applications associated with the active provider session.
As with the previous SSOs, make sure that you have configured Elasticsearch first accordingly. See Kerberos authentication.
Next, to enable Kerberos in Kibana, you will need to enable the Kerberos authentication provider in the
kibana.yml configuration file, as follows:
You may want to be able to authenticate with the basic authentication provider as a secondary mechanism or while you are setting up Kerberos for the stack:
xpack.security.authc.providers: [kerberos, basic]
As a reminder, the order is important as it determines the order in which each authentication provider is attempted.
Kibana uses SPNEGO, which wraps the Kerberos protocol for use with HTTP, extending it to web applications. At the end of the Kerberos handshake, Kibana will forward the service ticket to Elasticsearch. Elasticsearch will unpack it and it will respond with an access and refresh token which are then used for subsequent authentication.