|
7 | 7 |
|
8 | 8 | {kib} supports the following authentication mechanisms: |
9 | 9 |
|
| 10 | +- <<multiple-authentication-providers>> |
10 | 11 | - <<basic-authentication>> |
11 | 12 | - <<token-authentication>> |
12 | 13 | - <<pki-authentication>> |
|
16 | 17 | - <<anonymous-authentication>> |
17 | 18 | - <<http-authentication>> |
18 | 19 |
|
19 | | -Enable multiple authentication mechanisms at the same time specifying a prioritized list of the authentication _providers_ (typically of various types) in the configuration. Providers are consulted in ascending order. Make sure each configured provider has a unique name (e.g. `basic1` or `saml1` in the configuration example) and `order` setting. In the event that two or more providers have the same name or `order`, {kib} will fail to start. |
| 20 | +For an introduction to {kib}'s security features, including the login process, refer to <<tutorial-secure-access-to-kibana>>. |
| 21 | + |
| 22 | +[[multiple-authentication-providers]] |
| 23 | +==== Multiple authentication providers |
| 24 | + |
| 25 | +Enable multiple authentication mechanisms at the same time by specifying a prioritized list of the authentication _providers_ (typically of various types) in the configuration. Providers are consulted in ascending order. Make sure each configured provider has a unique name (e.g. `basic1` or `saml1` in the configuration example) and `order` setting. In the event that two or more providers have the same name or `order`, {kib} will fail to start. |
20 | 26 |
|
21 | 27 | When two or more providers are configured, you can choose the provider you want to use on the Login Selector UI. The order the providers appear is determined by the `order` setting. The appearance of the specific provider entry can be customized with the `description`, `hint`, and `icon` settings. |
22 | 28 |
|
23 | 29 | TIP: To provide login instructions to users, use the `xpack.security.loginHelp` setting, which supports Markdown format. When you specify the `xpack.security.loginHelp` setting, the Login Selector UI displays a `Need help?` link that lets users access login help information. |
24 | 30 |
|
25 | 31 | If you don't want a specific provider to show up at the Login Selector UI (e.g. to only support third-party initiated login) you can hide it with `showInSelector` setting set to `false`. However, in this case, the provider is presented in the provider chain and may be consulted during authentication based on its `order`. To disable the provider, use the `enabled` setting. |
26 | 32 |
|
27 | | -TIP: The Login Selector UI can also be disabled or enabled with `xpack.security.authc.selector.enabled` setting. |
| 33 | +TIP: The Login Selector UI can also be disabled or enabled with `xpack.security.authc.selector.enabled` setting. |
28 | 34 |
|
29 | 35 | Here is how your `kibana.yml` and Login Selector UI can look like if you deal with multiple authentication providers: |
30 | 36 |
|
@@ -292,9 +298,9 @@ xpack.security.authc.providers: |
292 | 298 | order: 1 |
293 | 299 | ----------------------------------------------- |
294 | 300 |
|
295 | | -IMPORTANT: {kib} uses SPNEGO, which wraps the Kerberos protocol for use with HTTP, extending it to web applications. |
| 301 | +IMPORTANT: {kib} uses SPNEGO, which wraps the Kerberos protocol for use with HTTP, extending it to web applications. |
296 | 302 | At the end of the Kerberos handshake, {kib} forwards the service ticket to {es}, then {es} unpacks the service ticket and responds with an access and refresh token, which are used for subsequent authentication. |
297 | | -On every {es} node that {kib} connects to, the keytab file should always contain the HTTP service principal for the {kib} host. |
| 303 | +On every {es} node that {kib} connects to, the keytab file should always contain the HTTP service principal for the {kib} host. |
298 | 304 | The HTTP service principal name must have the `HTTP/kibana.domain.local@KIBANA.DOMAIN.LOCAL` format. |
299 | 305 |
|
300 | 306 |
|
@@ -386,7 +392,7 @@ xpack.security.authc.providers: |
386 | 392 | [[anonymous-access-and-embedding]] |
387 | 393 | ===== Anonymous access and embedding |
388 | 394 |
|
389 | | -One of the most popular use cases for anonymous access is when you embed {kib} into other applications and don't want to force your users to log in to view it. |
| 395 | +One of the most popular use cases for anonymous access is when you embed {kib} into other applications and don't want to force your users to log in to view it. |
390 | 396 | If you configured {kib} to use anonymous access as the sole authentication mechanism, you don't need to do anything special while embedding {kib}. |
391 | 397 |
|
392 | 398 | If you have multiple authentication providers enabled, and you want to automatically log in anonymous users when embedding dashboards and visualizations: |
|
0 commit comments