WARNING: Version 6.2 of Kibana 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.

« Configuring Security in Kibana Security Settings in Kibana »

› › ›

Authentication in Kibana

edit

Authentication in Kibana

edit

Kibana supports the following authentication mechanisms:

Basic Authentication
SAML Single Sign-On

Basic Authentication

edit

Basic 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. For more information about Basic Authentication and built-in users, see Setting Up User Authentication.

SAML Single Sign-On

edit

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:
```
xpack.security.authProviders: [saml]
```
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]
```
Sometimes Kibana is behind a reverse proxy so that the user-facing Kibana protocol, hostname, and port are different than what is known to Kibana. If this is your case, update the following settings:
```
xpack.security.public:
  protocol: https
  hostname: kibana.proxy.com
  port: 8080
```

The Kibana user-facing origin should be the same in Kibana, Elasticsearch, and the Identity Provider SAML configuration.

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.

Some Identity Providers support a portal or dashboard from which users can open an application that is integrated with the Identity Provider. This login scenario is known as Identity Provider initiated login, and Kibana has limitations with this scenario. Users cannot open Kibana in multiple tabs from the Identity Provider portal in the same browser context if an active Kibana session exists. No issues exist if users open Kibana in multiple tabs using direct Kibana URL.

Access and Refresh Tokens

edit

Once the user logs in to Kibana via SAML Single Sign-On, 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 SAML 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 SAML "handshake" and redirects the user to the Identity Provider. Depending on Elasticsearch and the Identity Provider configuration, the user might be asked to re-enter credentials.

If Kibana can’t redirect the user to the Identity 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

edit

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 SAML "local" logout.

Kibana can also initiate a SAML "global" logout or Single Logout if it’s supported by the Identity Provider and not explicitly disabled by Elasticsearch. In this case, the user is redirected to the Identity Provider for log out of all applications associated with the active Identity Provider session.

SAML and Basic Authentication

edit

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.authProviders: [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.authProviders setting in addition to saml.

« Configuring Security in Kibana Security Settings in Kibana »