mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 01:38:56 -04:00
parent
1ca8db7fe6
commit
34b1e9d456
1 changed files with 77 additions and 16 deletions
|
@ -10,6 +10,7 @@
|
|||
- <<basic-authentication>>
|
||||
- <<token-authentication>>
|
||||
- <<saml>>
|
||||
- <<oidc>>
|
||||
|
||||
[[basic-authentication]]
|
||||
==== Basic Authentication
|
||||
|
@ -79,22 +80,6 @@ IMPORTANT: The {kib} user-facing origin should be the same in {kib}, {es}, and t
|
|||
|
||||
Users will be able to log in to {kib} via SAML Single Sign-On by navigating directly to the {kib} 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 {es} or the Identity Provider is configured to force user to re-authenticate. This login scenario is called _Service Provider initiated login_.
|
||||
|
||||
[float]
|
||||
===== Access and Refresh Tokens
|
||||
|
||||
Once the user logs in to {kib} via SAML Single Sign-On, {es} issues access and refresh tokens that {kib} 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 {kib} 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 {kib} will automatically renew it with a one-time-use refresh token and store it in the same cookie.
|
||||
|
||||
{kib} 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), {kib} initiates a new SAML "handshake" and redirects the user to the Identity Provider. Depending on {es} and the Identity Provider configuration, the user might be asked to re-enter credentials.
|
||||
|
||||
If {kib} 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 {kib} page fixes the error.
|
||||
|
||||
[float]
|
||||
===== Local and Global Logout
|
||||
|
||||
During logout, both the {kib} 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.
|
||||
|
||||
{kib} can also initiate a SAML "global" logout or _Single Logout_ if it's supported by the Identity Provider and not explicitly disabled by {es}. In this case, the user is redirected to the Identity Provider for log out of all applications associated with the active Identity Provider session.
|
||||
|
||||
[float]
|
||||
===== SAML and Basic Authentication
|
||||
|
||||
|
@ -109,3 +94,79 @@ xpack.security.authProviders: [saml, basic]
|
|||
The order of `saml` and `basic` is important. Users who open {kib} will go through the SAML Single Sign-On process unless the direct Basic authentication `/login` link is used. This might be the case for {kib} or {es} 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`.
|
||||
|
||||
[[oidc]]
|
||||
==== OpenID Connect Single Sign-On
|
||||
|
||||
Similar to SAML, authentication with OpenID Connect allows users to log in to {kib} using an OpenID Connect Provider such as Google, or Okta. OpenID Connect
|
||||
should also be configured in {es}, see {xpack-ref}/saml-guide.html[Configuring OpenID Connect Single-Sign-On on the Elastic Stack] for more details.
|
||||
|
||||
Set the configuration values in `kibana.yml` as follows:
|
||||
|
||||
. Enable the SAML authentication:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
xpack.security.authProviders: [oidc]
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
. {kib} needs to specify which OpenID Connect realm in {es} should be used, in case there are more than one configured there.
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
xpack.security.authc.oidc.realm: oidc1
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
. {kib} 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 {kib}. If you want to use Third Party initiated SSO , then you must disable the CSRF check for this endpoint.
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
server.xsrf.whitelist: [/api/security/v1/oidc]
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
[float]
|
||||
===== OpenID Connect and Basic Authentication
|
||||
|
||||
Similar to SAML, OpenID Connect support in {kib} is designed to be the primary (or sole) authentication method for users
|
||||
of that {kib} instance. However, you can configure both OpenID Connect and Basic authentication for the same {kib} instance:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
xpack.security.authProviders: [oidc, basic]
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
Users will be able to access the login page and use Basic authentication by navigating to the `/login` URL.
|
||||
|
||||
[float]
|
||||
==== Single Sign-On provider details
|
||||
|
||||
The following sections apply both to <<saml>> and <<oidc>>
|
||||
|
||||
[float]
|
||||
===== Access and Refresh Tokens
|
||||
|
||||
Once the user logs in to {kib} Single Sign-On, either using SAML or OpenID Connect, {es} issues access and refresh tokens
|
||||
that {kib} 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 {kib} 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 {kib} will automatically renew it with a one-time-use refresh token and store it in the same cookie.
|
||||
|
||||
{kib} 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), {kib} initiates a new "handshake" and
|
||||
redirects the user to the external authentication provider (SAML Identity Provider or OpenID Connect Provider)
|
||||
Depending on {es} and the external authentication provider configuration, the user might be asked to re-enter credentials.
|
||||
|
||||
If {kib} 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 {kib} page fixes the error.
|
||||
|
||||
[float]
|
||||
===== Local and Global Logout
|
||||
|
||||
During logout, both the {kib} 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.
|
||||
|
||||
{kib} can also initiate a "global" logout or _Single Logout_ if it's supported by the external authentication provider and not
|
||||
explicitly disabled by {es}. In this case, the user is redirected to the external authentication provider for log out of
|
||||
all applications associated with the active provider session.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue