Authentication in Kibana
editAuthentication in Kibana
editKibana supports the following authentication mechanisms:
Basic authentication
editBasic authentication requires a username and password to successfully log in to Kibana. It is enabled by default and based on the Native security realm provided by Elasticsearch. The basic authentication provider uses a Kibana provided login form, and supports authentication using the Authorization
request header’s Basic
scheme.
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
editToken authentication allows users to login using the same Kibana provided login form as basic authentication. The token authentication provider is built on Elasticsearch’s 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 Bearer
scheme.
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 kibana.yml
:
xpack.security.authc.providers: [token]
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]
SAML single sign-on
editSAML 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:
xpack.security.authc.providers: [saml]
-
Kibana needs to specify which SAML realm in Elasticsearch should be used:
xpack.security.authc.saml.realm: realm-name
-
The Identify Provider sends authentication requests to the
Assertion Consumer Service
endpoint that Kibana exposes through a "non-safe"POST
HTTP method. This does not include CSRF protection HTTP headers specific to Kibana. You must disable the CSRF check for this endpoint.server.xsrf.whitelist: [/api/security/v1/saml]
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 and basic authentication
editSAML 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 saml
and 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 saml
.
OpenID Connect single sign-on
editSimilar 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:
xpack.security.authc.providers: [oidc]
-
Kibana needs to specify which OpenID Connect realm in Elasticsearch should be used, in case there are more than one configured there.
xpack.security.authc.oidc.realm: oidc1
-
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"
POST
HTTP 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.server.xsrf.whitelist: [/api/security/v1/oidc]
OpenID Connect and basic authentication
editSimilar 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 /login
URL.
Single sign-on provider details
editThe following sections apply both to SAML single sign-on and OpenID Connect single sign-on
Access and refresh tokens
editOnce 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 xpack.security.sessionTimeout
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.
Local and global logout
editDuring 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.