验证在Kibana (X-PACK)
Kibana支持以下身份验证机制：
1、基本认证
2、令牌认证
3、公钥基础结构（PKI）身份验证
4、SAML单点登录
5、OpenID Connect单一登录
6、Kerberos单点登录
基本身份验证编辑
要成功登录Kibana，基本身份验证需要用户名和密码。默认情况下，基本身份验证处于启用状态，并且基于Elasticsearch提供的本机安全领域或LDAP安全领域。基本身份验证提供程序使用Kibana提供的登录表单，并支持使用Authorization请求标头Basic方案的身份验证。
基本身份验证提供程序发出的会话cookie是无状态的。因此，使用基本身份验证提供程序时注销Kibana会从浏览器中清除会话cookie，但不会使会话cookie无效以供重用。
有关基本身份验证和内置用户的更多信息，请参阅 用户身份验证。
令牌认证编辑
令牌认证允许用户使用与基本认证相同的Kibana提供的登录表单进行登录，并且基于Elasticsearch提供的本机安全领域或LDAP安全领域。令牌身份验证提供程序基于Elasticsearch令牌API构建。由Elasticsearch的get令牌API返回的承载令牌可以通过Authorization该Bearer方案的请求标头直接与Kibana一起使用。
令牌认证提供者发出的会话cookie是有状态的，注销Kibana会使会话cookie无效以供重用。
在配置Kibana之前，请确保在Elasticsearch中启用了令牌支持。有关更多信息，请参见Elasticsearch令牌API文档。
要在Kibana中启用令牌身份验证提供程序，请在中设置以下值kibana.yml：
xpack.security.authc.providers: [token]
令牌身份验证提供程序可以与基本身份验证提供程序一起使用。登录表单将继续使用令牌身份验证提供程序，同时使应用程序喜欢curl将Authorization请求标头与Basic方案一起使用。在中设置以下内容kibana.yml，并保持auth提供者的顺序：
xpack.security.authc.providers: [token, basic]
公钥基础设施（PKI）认证编辑
如果将Kibana托管在TLS终止反向代理之后，则PKI身份验证将不起作用。在这种配置下，Kibana无法直接访问客户端证书，也无法验证用户身份。
通过PKI身份验证，用户可以使用X.509客户端证书登录Kibana，该证书必须在连接Kibana时出示。必须首先在Kibana TLS层上接受证书进行身份验证，然后再由Elasticsearch PKI领域对其进行验证。PKI身份验证提供程序依靠Elasticsearch 委托PKI身份验证API交换X.509客户端证书以访问令牌。代表用户对Elasticsearch API的所有后续请求都将使用这些访问令牌进行身份验证。
在配置Kibana之前，请确保在Elasticsearch中启用了PKI领域并将其配置为允许委派。有关更多信息，请参阅配置PKI领域。
要在Kibana中启用PKI身份验证提供程序，必须首先配置Kibana以加密浏览器和Kibana服务器之间的通信。您还必须启用TLS客户端身份验证，并将用于对客户端证书进行签名的证书颁发机构（CA）包括在您的Kibana信任的CA列表中kibana.yml：
server.ssl.certificateAuthorities: /path/to/your/cacert.pem
server.ssl.clientAuthentication: required
xpack.security.authc.providers: [pki]``
> 信任的CA也可以在PKCS＃12密钥库与你Kibana服务器证书/密钥使用绑定的指定 server.ssl.keystore.path或使用一个单独的信托商店server.ssl.truststore.path。
Kibana中的PKI支持被设计为该Kibana实例的用户的主要（或唯一）身份验证方法。但是，您可以为同一Kibana实例配置PKI和基本身份验证：
```csharp
xpack.security.authc.providers: [pki, basic]
请注意，server.ssl.clientAuthentication设置required为时，即使用户要使用用户名和密码进行身份验证，也会要求他们提供有效的客户端证书。根据安全策略，可能需要也可能不需要。如果不是，server.ssl.clientAuthentication可以设置为optional。在这种情况下，Kibana仍会请求客户证书，但是不需要客户提供证书。的optional，可能也需要客户端认证模式在其它情况下，例如，当PKI认证结合使用具有报告。
SAML单点登录编辑
SAML身份验证允许用户使用外部身份提供程序（例如Okta或Auth0）登录到Kibana。在Kibana中进行设置之前，请确保已在Elasticsearch中启用并配置了SAML。请参阅在弹性堆栈上配置SAML单一登录。
1、kibana.yml如下配置配置值：
启用SAML身份验证：
xpack.security.authc.providers: [saml]
2、Kibana需要指定应在Elasticsearch中使用哪个SAML领域：
xpack.security.authc.saml.realm: realm-name
3、身份提供者Assertion Consumer Service通过“非安全” POSTHTTP方法将身份验证请求发送到Kibana公开的端点。这不包括针对Kibana的CSRF保护HTTP标头。您必须为此端点禁用CSRF检查。
server.xsrf.whitelist: [/api/security/saml/callback]
通过直接导航到Kibana URL，用户将能够通过SAML单一登录登录Kibana。未经身份验证的用户将被重定向到身份提供者进行登录。大多数身份提供者维护一个长期存在的会话-使用同一浏览器中的同一身份提供者登录到不同应用程序的用户将自动进行身份验证。如果将Elasticsearch或身份提供者配置为强制用户重新认证，则为例外。此登录方案称为服务提供商启动的登录。
SAML和基本身份验证编辑
Kibana中的SAML支持被设计为该Kibana实例的用户的主要（或唯一）身份验证方法。但是，您可以为同一Kibana实例配置SAML和基本身份验证：
的顺序saml和basic是很重要的。除非使用直接的基本身份验证/login链接，否则打开Kibana的用户将经历SAML单一登录过程。对于未将帐户链接到“单一登录用户”数据库的Kibana或Elasticsearch管理员，可能就是这种情况。或者，当Authorization: Basic base64(username:password)请求中包含HTTP标头时（例如，通过反向代理）。
仅当basic在中的xpack.security.authc.providers设置中显式声明了身份验证提供程序时，才支持基本身份验证saml。
SAML和长URL编辑
在SAML握手开始时，Kibana将初始URL存储在会话cookie中，因此在成功进行SAML身份验证后，它可以将用户重定向回该URL。如果URL较长，则会话cookie可能会超过浏览器支持的最大大小-每个域的所有cookie通常为4KB。发生这种情况时，会话cookie将被截断或完全删除，并且在SAML身份验证期间您可能会遇到零星的故障。
要解决此问题，您可以减小SAML握手期间允许Kibana存储的URL的最大大小。默认值为2KB。
OpenID Connect单一登录编辑
与SAML相似，使用OpenID Connect进行身份验证可以使用户使用Google或Okta等OpenID Connect提供程序登录Kibana。还应在Elasticsearch中配置OpenID Connect。有关更多详细信息，请参阅使用OpenID Connect配置到弹性堆栈的单点登录。
kibana.yml如下配置配置值：
1、启用OpenID Connect身份验证：
2、Kibana需要指定应在Elasticsearch中使用哪个OpenID Connect领域，以防在其中配置了多个。
3、Kibana支持第三方启动的单点登录，该操作可能以指示用户浏览器执行“非安全” POSTHTTP方法的外部应用程序开始。该请求将不包含Kibana所需的CSRF保护HTTP标头。如果要使用第三方发起的SSO，则必须对此端点禁用CSRF检查。
ID连接和基本身份验证编辑
与SAML相似，Kibana中的OpenID Connect支持被设计为该Kibana实例的用户的主要（或唯一）身份验证方法。但是，您可以为同一Kibana实例配置OpenID Connect和基本身份验证：
用户将能够通过导航到/loginURL 来访问登录页面并使用基本身份验证。
单一登录提供者详细信息编辑
以下各节适用于SAML单一登录和OpenID Connect单一登录
访问和刷新令牌编辑
用户使用SAML或OpenID Connect登录到Kibana单一登录后，Elasticsearch会发布访问和刷新令牌，这些令牌将由Kibana加密并将其存储在自己的会话cookie中。这样，对于每个需要身份验证的请求，用户都不会重定向到身份提供者。这也意味着Kibana会话取决于xpack.security.session.idleTimeout和xpack.security.session.lifespan设置，并且如果会话过期，用户将自动注销。会话cookie中存储的访问令牌可能会过期，在这种情况下，Kibana将使用一次使用的刷新令牌自动对其进行续订并将其存储在同一cookie中。
Kibana只能确定访问令牌是否在收到要求身份验证的请求后才过期。如果访问令牌和刷新令牌都已经过期（例如，在闲置24小时之后），则Kibana会发起新的“握手”操作，并将用户重定向到外部身份验证提供程序（SAML身份提供程序或OpenID Connect提供程序），具体取决于Elasticsearch和外部身份验证提供程序配置，则可能要求用户重新输入凭据。
如果Kibana无法将用户重定向到外部身份验证提供程序（例如，对于AJAX / XHR请求），则会出现错误，指示访问令牌和刷新令牌都已过期。重新加载当前的Kibana页面可修复该错误。
局部和全局注销编辑
注销期间，Kibana会话cookie和访问/刷新令牌对均无效。即使Cookie已泄漏，注销后也无法重复使用。这称为“本地”注销。
如果外部身份验证提供程序支持并且未由Elasticsearch明确禁用，则Kibana还可以启动“全局”注销或“ 单一注销 ” 。在这种情况下，用户将重定向到外部身份验证提供程序，以注销与活动提供程序会话关联的所有应用程序。
Kerberos的单点登录编辑
与以前的SSO一样，请确保首先配置了Elasticsearch。请参阅Kerberos身份验证。
接下来，要在Kibana中启用Kerberos，您将需要在kibana.yml配置文件中启用Kerberos身份验证提供程序，如下所示：
您可能希望能够使用基本身份验证提供程序作为辅助机制进行身份验证，或者在为堆栈设置Kerberos时：
提醒一下，该顺序很重要，因为它决定了尝试每个身份验证提供程序的顺序。
Kibana使用SPNEGO，它包装Kerberos协议以供HTTP使用，并将其扩展到Web应用程序。在Kerberos握手结束时，Kibana将把服务票证转发给Elasticsearch。Elasticsearch将解压缩它，并使用访问和刷新令牌进行响应，然后将其用于后续身份验证。
参考链接 ：
https://www.elastic.co/guide/en/kibana/current/kibana-authentication.html#pki-authentication
