-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document authentication settings. #69284
Changes from all commits
5e59bb9
0220b73
c910eec
01cea76
e101052
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
[role="xpack"] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. note: didn't find any existing suitable section for this feature, so create a new one. |
||
[[xpack-security-access-agreement]] | ||
=== Access agreement | ||
|
||
Some work environments require you to acknowledge and accept an agreement before you can access {kib}, which can contain sensitive information. The agreement text supports Markdown format and can be specified using the `xpack.security.authc.providers.<provider-type>.<provider-name>.accessAgreement.message` setting. | ||
|
||
[NOTE] | ||
============================================================================ | ||
You need to acknowledge the access agreement only once per session, and {kib} reports the acknowledgement in the audit logs. | ||
============================================================================ | ||
|
||
Here is how your `kibana.yml` can look like if you define an access agreement: | ||
|
||
[source,yaml] | ||
-------------------------------------------------------------------------------- | ||
xpack.security.authc.providers: | ||
basic.basic1: | ||
order: 0 | ||
accessAgreement: | ||
message: "**You are accessing a system with a sensitive information** \n\n | ||
By logging in, you acknowledge that (shortened ...)" | ||
-------------------------------------------------------------------------------- | ||
|
||
When you authenticate using `basic.basic1`, you'll see the following agreement that you must acknowledge before you can access {kib}: | ||
|
||
[role="screenshot"] | ||
image::user/security/images/access-agreement.png["Access Agreement UI"] |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,22 +17,29 @@ | |
|
||
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. | ||
|
||
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` setting. | ||
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. | ||
|
||
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. | ||
|
||
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. | ||
|
||
TIP: The Login Selector UI can also be disabled or enabled with `xpack.security.authc.selector.enabled` setting. | ||
|
||
Here is how your `kibana.yml` can look like if you deal with multiple authentication providers: | ||
Here is how your `kibana.yml` and Login Selector UI can look like if you deal with multiple authentication providers: | ||
|
||
[source,yaml] | ||
-------------------------------------------------------------------------------- | ||
xpack.security.loginHelp: "**Help** info with a [link](...)" | ||
xpack.security.authc.providers: | ||
basic.basic1: | ||
order: 0 | ||
icon: "logoElasticsearch" | ||
hint: "Typically for administrators" | ||
saml.saml1: | ||
order: 1 | ||
realm: saml1 | ||
description: "Log in with SSO" | ||
icon: "https://my-company.xyz/saml-logo.svg" | ||
saml.saml2: | ||
order: 2 | ||
realm: saml2 | ||
|
@@ -42,6 +49,11 @@ xpack.security.authc.providers: | |
enabled: false | ||
-------------------------------------------------------------------------------- | ||
|
||
[role="screenshot"] | ||
image::user/security/images/kibana-login.png["Login Selector UI"] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: given the configuration above, shouldn't I expect to see the Kerberos realm in this screenshot? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nope it's There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I kept it to show that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah I missed that! |
||
|
||
For more information, refer to <<authentication-security-settings, authentication security settings>>. | ||
|
||
[[basic-authentication]] | ||
==== Basic authentication | ||
|
||
|
@@ -170,6 +182,7 @@ Basic authentication is supported _only_ if the `basic` authentication provider | |
To support basic authentication for the applications like `curl` or when the `Authorization: Basic base64(username:password)` HTTP header is included in the request (for example, by reverse proxy), add `Basic` scheme to the list of supported schemes for the <<http-authentication,HTTP authentication>>. | ||
|
||
[float] | ||
[[security-saml-and-long-urls]] | ||
===== SAML and long URLs | ||
|
||
At the beginning of the SAML handshake, {kib} stores the initial URL in the session cookie, so it can redirect the user back to that URL after successful SAML authentication. | ||
|
@@ -325,4 +338,4 @@ NOTE: Don't forget to explicitly specify default `apikey` scheme when you just w | |
xpack.security.authc.http.schemes: [apikey, basic, something-custom] | ||
-------------------------------------------------------------------------------- | ||
|
||
With this configuration, you can send requests to {kib} with the `Authorization` header using `ApiKey`, `Basic` or `Something-Custom` HTTP schemes (case insensitive). Under the hood, {kib} relays this header to {es}, then {es} authenticates the request using the credentials in the header. | ||
With this configuration, you can send requests to {kib} with the `Authorization` header using `ApiKey`, `Basic` or `Something-Custom` HTTP schemes (case insensitive). Under the hood, {kib} relays this header to {es}, then {es} authenticates the request using the credentials in the header. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: the setting name is super long and it leaves a tiny space for the setting description itself. I didn't manage to find a better way to make it readable. Another alternative I was considering is omitting
xpack.security.authc.providers.
prefix completely and explaining that all settings in this section are assumed to have one. But it didn't look well with the rest of the settings we describe in this file.Happy to hear any suggestions!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't worry about the spacing issues in the tables. Gail is changing the tables into definition lists, so the spacing issue should work itself out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, thanks! I'll remove my workaround then.