@@ -733,20 +733,25 @@ SAML authentication in {kib} is also subject to the
733
733
`xpack.security.sessionTimeout` setting that is described in the {kib} security
734
734
documentation, and you may wish to adjust this timeout to meet your local needs.
735
735
736
- The two additional settings that are required for SAML support are shown below:
736
+ The three additional settings that are required for SAML support are shown below:
737
737
738
738
[source, yaml]
739
739
------------------------------------------------------------
740
- xpack.security.authProviders: [saml]
740
+ xpack.security.authc.providers: [saml]
741
+ xpack.security.authc.saml.realm: saml1
741
742
server.xsrf.whitelist: [/api/security/v1/saml]
742
743
------------------------------------------------------------
743
744
744
745
The configuration values used in the example above are:
745
746
746
- `xpack.security.authProviders `::
747
+ `xpack.security.authc.providers `::
747
748
Set this to `[ saml ]` to instruct {kib} to use SAML SSO as the authentication
748
749
method.
749
750
751
+ `xpack.security.authc.saml.realm`::
752
+ Set this to the name of the SAML realm that you have used in your <<saml-create-realm,
753
+ Elasticsearch realm configuration>>, for instance: `saml1`
754
+
750
755
`server.xsrf.whitelist`::
751
756
{kib} has in-built protection against _Cross Site Request Forgery_ attacks which
752
757
are designed to prevent the {kib} server from processing requests that
@@ -755,47 +760,18 @@ In order to support SAML authentication messages that originate from your
755
760
Identity Provider, we need to explicitly _whitelist_ the SAML authentication URL
756
761
within {kib}, so that the {kib} server will not reject these external messages.
757
762
758
- If your {kib} instance is behind a proxy, you may also need to add configuration
759
- to tell {kib} how to form its public URL. This is needed because all SAML
760
- messages are exchanged via the user's web browser, so {kib} needs to know what
761
- URLs are used within the browser. In this case, the following settings should be
762
- added to your `kibana.yml` configuration file:
763
-
764
- [source, yaml]
765
- ------------------------------------------------------------
766
- xpack.security.public:
767
- protocol: https
768
- hostname: kibana.proxy.com
769
- port: 443
770
- ------------------------------------------------------------
771
-
772
- `xpack.security.public.protocol`::
773
- This is the protocol that the user's web browser uses to connect to the proxy.
774
- Must be one of `http` or `https`. It is strongly recommended that you use the
775
- `https` protocol for all access to {kib}.
776
-
777
- `xpack.security.public.hostname`::
778
- The fully qualified hostname that your users use to connect to the proxy server.
779
-
780
- `xpack.security.public.port`::
781
- The port number that your users use to connect to the proxy server (e.g. `80`
782
- for `http` or `443` for `https`).
783
-
784
- These values must be aligned with the URLs used in the {es} configuration for
785
- `sp.acs` and `sp.logout`.
786
-
787
763
[[saml-kibana-basic]]
788
764
==== Supporting SAML and basic authentication in {kib}
789
765
790
766
The SAML support in {kib} is designed on the expectation that it will be the
791
767
primary (or sole) authentication method for users of that {kib} instance.
792
768
However, it is possible to support both SAML and Basic authentication within a
793
- single {kib} instance by setting `xpack.security.authProviders ` as per the
769
+ single {kib} instance by setting `xpack.security.authc.providers ` as per the
794
770
example below:
795
771
796
772
[source, yaml]
797
773
------------------------------------------------------------
798
- xpack.security.authProviders : [saml, basic]
774
+ xpack.security.authc.providers : [saml, basic]
799
775
------------------------------------------------------------
800
776
801
777
The order is important - this will _initiate_ SAML authentication for
0 commit comments