honeymoose/OpenSearch
1
0
Fork 0
mirror of https://github.com/honeymoose/OpenSearch.git synced 2025-03-27 18:38:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

[7.x] Document support of OIDC Implicit flow in Kibana. (#46329)

Browse Source
This commit is contained in:
Aleh Zasypkin 2019-09-04 20:50:15 +02:00 committed by GitHub
parent bd7f9d5bcd
commit 5ee336ff78
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 14 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/reference/settings/security-settings.asciidoc
View File

@ -1284,9 +1284,9 @@ The OAuth 2.0 Client Secret that was assigned to {es} during registration
at the OpenID Connect Provider
`rp.redirect_uri`::
The Redirect URI within {kib}. Typically this is the
"api/security/v1/oidc" endpoint of your Kibana server. For example,
`https://kibana.example.com/api/security/v1/oidc`.
The Redirect URI within {kib}. If you want to use the authorization code flow, this is the
"api/security/v1/oidc" endpoint of your {kib} server. If you want to use the implicit flow, it is the "api/security/v1/oidc/implicit" endpoint.
For example, `https://kibana.example.com/api/security/v1/oidc`.
`rp.response_type`::
OAuth 2.0 Response Type value that determines the authorization

23
x-pack/docs/en/security/authentication/oidc-guide.asciidoc
View File

@ -5,8 +5,7 @@
The Elastic Stack supports single sign-on (SSO) using OpenID Connect via {kib} using
{es} as the backend service that holds most of the functionality. {kib} and {es}
together represent an OpenID Connect Relying Party (RP) that supports the Authorization
Code Flow as this is defined in the OpenID Connect specification.
together represent an OpenID Connect Relying Party (RP) that supports the authorization code flow and implicit flow as these are defined in the OpenID Connect specification.
This guide assumes that you have an OpenID Connect Provider where the
Elastic Stack Relying Party will be registered.
@ -39,8 +38,8 @@ RP that you commonly need to provide for registration are the following:
nor the Elastic Stack implementation impose any constraints on this value.
- `Redirect URI`: This is the URI where the OP will redirect the user's browser after authentication. The
appropriate value for this will depend on your setup and whether or not {kib} sits behind a proxy or
load balancer. It will typically be +$\{kibana-url}/api/security/v1/oidc+ where _$\{kibana-url}_
is the base URL for your {kib} instance. You might also see this called `Callback URI`.
load balancer. It will typically be +$\{kibana-url}/api/security/v1/oidc+ (for the authorization code flow) or +$\{kibana-url}/api/security/v1/oidc/implicit+ (for the implicit flow) where _$\{kibana-url}_ is the base URL for your {kib} instance. You might also see this
called `Callback URI`.
At the end of the registration process, the OP will assign a Client Identifier and a Client Secret for the RP ({stack}) to use.
Note these two values as they will be used in the {es} configuration.
@ -158,8 +157,8 @@ op.authorization_endpoint::
op.token_endpoint::
The URL for the Token Endpoint in the OpenID Connect Provider. This is the endpoint where
{es} will send a request to exchange the code for an ID Token, in the case where the Authorization Code
flow is used. The value for this setting should be provided by your OpenID Connect Provider.
{es} will send a request to exchange the code for an ID Token. This setting is optional when
you use the implicit flow. The value for this setting should be provided by your OpenID Connect Provider.
op.jwkset_path::
The path to a file or a URL containing a JSON Web Key Set with the key material that the OpenID Connect
@ -522,23 +521,23 @@ The three additional settings that are required for OpenID Connect support are s
[source, yaml]
------------------------------------------------------------
xpack.security.authProviders: [oidc]
xpack.security.authc.providers: [oidc]
xpack.security.authc.oidc.realm: "oidc1"
server.xsrf.whitelist: [/api/security/v1/oidc]
------------------------------------------------------------
The configuration values used in the example above are:
`xpack.security.authProviders`::
`xpack.security.authc.providers`::
Set this to `[ oidc ]` to instruct {kib} to use OpenID Connect single sign-on as the
authentication method. This instructs Kibana to attempt to initiate an SSO flow
everytime a user attempts to access a URL in Kibana, if the user is not already
authenticated. If you also want to allow users to login with a username and password,
you must enable the `basic` authProvider too. For example:
you must enable the `basic` authentication provider too. For example:
[source, yaml]
------------------------------------------------------------
xpack.security.authProviders: [oidc, basic]
xpack.security.authc.providers: [oidc, basic]
------------------------------------------------------------
This will allow users that haven't already authenticated with OpenID Connect to
@ -552,8 +551,8 @@ for this Kibana instance.
{kib} has in-built protection against _Cross Site Request Forgery_ attacks, which
is designed to prevent the {kib} server from processing requests that
originated from outside the {kib} application.
In order to support OpenID Connect messages that originate from your
OP or a third party (see <<third-party-login>>, we need to explicitly _whitelist_ the
If you use the authorization code flow, {kib} needs to support unsolicited messages that originate from your
OP or a third party (see <<third-party-login>>). In order to do so, you must explicitly _whitelist_ the
OpenID Connect authentication endpoint within {kib}, so that the {kib} server will
not reject these external messages.