在 Elastic Stack 上配置 SAML 单点登录

如果您的 Elasticsearch 集群在生产模式下运行，则必须先将 HTTP 接口配置为使用 SSL/TLS，然后才能启用 SAML 身份验证。

有关更多信息，请参阅 加密 Elasticsearch 的 HTTP 客户端通信。

Elasticsearch SAML 实现利用了 Elasticsearch 令牌服务。如果您在 HTTP 接口上配置了 TLS，则会自动启用此服务，并且可以通过在 elasticsearch.yml 文件中包含以下内容来显式配置此服务

xpack.security.authc.token.enabled: true

通过在 Elasticsearch 的身份验证链中配置 SAML 领域来启用 SAML 身份验证。

此领域有一些强制设置和许多可选设置。可用的设置在 安全设置 中有详细说明。例如，SAML 领域设置、SAML 领域签名设置、SAML 领域加密设置、SAML 领域 SSL 设置。本指南将引导您完成最常见的设置。

通过将以下内容添加到您的 elasticsearch.yml 配置文件中来创建领域。下面将对每个配置值进行说明。

xpack.security.authc.realms.saml.saml1:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.example.com/"
  sp.acs: "https://kibana.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."

上面示例中使用的配置值为

当用户通过您的身份提供程序连接到 Kibana 时，身份提供程序将提供有关该用户的 SAML 断言。断言将包含一个*身份验证声明*，指示用户已成功向 IdP 进行身份验证，以及一个或多个*属性声明*，其中将包含用户的*属性*。

这些属性可能包括以下内容

SAML 中的属性使用 URI 命名，例如 urn:oid:0.9.2342.19200300.100.1.1 或 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn，并且具有与其关联的一个或多个值。

这些属性标识符因 IdP 而异，大多数 IdP 提供自定义 URI 及其关联值的方法。

Elasticsearch 使用这些属性来推断已登录用户的信息，并且它们可用于角色映射（如下）。

为了使这些属性有用，Elasticsearch 和 IdP 需要对属性名称使用共同的值。这是通过手动配置 IdP 和 SAML 领域以对每个逻辑用户属性使用相同的 URI 名称来完成的。

配置这些 SAML 属性的建议步骤如下

xpack.security.authc.realms.saml.saml1:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.example.com/"
  sp.acs: "https://kibana.example.com/api/security/saml/callback"
  attributes.principal: "nameid:persistent"
  attributes.groups: "roles"
  nameid_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"

xpack.security.authc.realms.saml.saml1:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.example.com/"
  sp.acs: "https://kibana.example.com/api/security/saml/callback"
  attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  attribute_patterns.principal: "^([^@]+)@staff\\.example\\.com$"

有时，SAML SP 需要能够对将在 IdP 处进行的身份验证施加特定的限制，以便评估其对相应身份验证响应的置信度。限制可能与身份验证方法（密码、客户端证书等）、注册期间的用户识别方法以及其他详细信息有关。Elasticsearch 实现了SAML 2.0 身份验证上下文，可用于 SAML 2.0 核心规范中定义的此目的。

简而言之，SAML SP 定义了一组身份验证上下文类引用值，这些值描述了要对 IdP 施加的限制，并在身份验证请求中发送这些值。IdP 尝试授予这些限制。如果它不能授予它们，则身份验证尝试失败。如果用户已成功通过身份验证，则 SAML 响应的身份验证语句包含已满足的限制的指示。

您可以使用 SAML 领域配置中的 req_authn_context_class_ref 选项定义身份验证上下文类引用值。请参阅SAML 领域设置。

Elasticsearch 仅支持身份验证上下文的 exact 比较方法。当它从 IdP 收到身份验证响应时，Elasticsearch 会检查作为 SAML 断言的身份验证语句一部分的身份验证上下文类引用的值。如果它与其中一个请求的值匹配，则认为身份验证成功。否则，身份验证尝试失败。

SAML 协议支持单点注销 (SLO) 的概念。对 SLO 的支持级别因身份提供者而异。您应该查阅 IdP 的文档以确定它提供哪些注销服务。

默认情况下，如果满足以下条件，Elastic Stack 将支持 SAML SLO

Elastic Stack 支持生成已签名的 SAML 消息（用于身份验证和/或注销）、验证来自 IdP 的已签名 SAML 消息（用于身份验证和注销）并且可以处理加密内容。

您可以使用相同或单独的密钥为签名、加密或两者配置 Elasticsearch。

Elastic Stack 使用带有 RSA 私钥的 X.509 证书进行 SAML 加密。可以使用任何标准 SSL 工具生成这些密钥，包括 elasticsearch-certutil 工具。

您的 IdP 可能要求 Elastic Stack 具有用于对 SAML 消息进行签名的加密密钥，并且您在服务提供者配置中提供相应的签名证书（在 Elastic Stack SAML 元数据文件中或在 IdP 管理界面中手动配置） . 虽然大多数 IdP 不希望对身份验证请求进行签名，但通常情况下，注销请求需要签名。您的 IdP 将根据已为 Elastic Stack 服务提供者配置的签名证书验证这些签名。

很少需要加密证书，但 Elastic Stack 支持它们用于 IdP 或本地策略强制使用它们的情况。

bin/elasticsearch-certutil cert --self-signed --pem --days 1100 --name saml-sign --out saml-sign.zip

Kibana 中的 SAML 支持的设计预期是它将成为该 Kibana 实例用户的首选（或唯一）身份验证方法。 但是，可以通过按照以下示例设置 xpack.security.authc.providers 在单个 Kibana 实例中同时支持 SAML 和基本身份验证

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: "saml1"
  basic.basic1:
    order: 1

如果 Kibana 以这种方式配置，则用户会在登录选择器 UI 中看到一个选项。 他们可以使用 SAML 登录，也可以提供用户名和密码并依赖 Elasticsearch 中的其他安全领域之一。 只有拥有已配置 Elasticsearch 身份验证领域的用户名和密码的用户才能通过 Kibana 登录表单登录。

或者，当启用 basic 身份验证提供程序时，您可以在 Kibana 前面放置一个反向代理，并将其配置为为每个请求发送一个基本身份验证标头 (Authorization: Basic ....)。 如果此标头存在且有效，Kibana 将不会启动 SAML 身份验证过程。

如果您希望拥有多个针对同一个 Elasticsearch 集群进行身份验证的 Kibana 实例，则为 SAML 身份验证配置的每个 Kibana 实例都需要自己的 SAML 领域。

每个 SAML 领域都必须有其唯一的实体 ID (sp.entity_id) 和其自己的*断言使用者服务* (sp.acs)。 每个 Kibana 实例都将通过查找匹配的 sp.acs 值映射到正确的领域。

这些领域可以使用相同的身份提供程序，但这不是必需的。

以下是拥有 3 个不同 Kibana 实例的示例，其中 2 个使用相同的内部 IdP，另一个使用不同的 IdP。

xpack.security.authc.realms.saml.saml_finance:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.finance.example.com/"
  sp.acs: "https://kibana.finance.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.finance.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml.saml_sales:
  order: 3
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.sales.example.com/"
  sp.acs: "https://kibana.sales.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.sales.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml.saml_eng:
  order: 4
  idp.metadata.path: saml/idp-external.xml
  idp.entity_id: "https://engineering.sso.example.net/"
  sp.entity_id:  "https://kibana.engineering.example.com/"
  sp.acs: "https://kibana.engineering.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.engineering.example.com/logout"
  attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

可以有一个或多个使用 SAML 的 Kibana 实例，而其他实例使用针对另一种领域类型（例如 本机 或 LDAP）的基本身份验证。

您必须创建一个 SAML 领域并在 Elasticsearch 中对其进行相应配置。 请参阅 为 SAML 身份验证配置 Elasticsearch

该领域的设计假设需要一个特权实体充当身份验证代理。 在这种情况下，自定义 Web 应用程序是处理最终用户身份验证的身份验证代理（更准确地说，是将身份验证“委托”给 SAML 身份提供商）。 与 SAML 相关的 API 需要身份验证以及经过身份验证的用户的必要授权级别。 出于这个原因，您必须创建一个服务帐户用户并为其分配一个角色，授予其 manage_saml 集群权限。 身份验证完成后，需要使用 manage_token 集群权限，以便服务帐户用户可以维护访问权限，以便代表经过身份验证的用户刷新访问令牌或随后将其注销。

POST /_security/role/saml-service-role
{
  "cluster" : ["manage_saml", "manage_token"]
}

POST /_security/user/saml-service-user
{
  "password" : "<somePasswordHere>",
  "roles"    : ["saml-service-role"]
}

在较高的级别上，自定义 Web 应用程序需要执行以下步骤才能使用 SAML 对 Elasticsearch 中的用户进行身份验证

Elasticsearch 还可以处理 SAML 2 Web 浏览器 SSO 配置文件的 IdP 发起的单点登录流程。 在这种情况下，身份验证从 SAML 身份提供商发出的未经请求的身份验证响应开始。 与 SP 发起的 SSO 的区别在于，Web 应用程序需要处理对 sp.acs 的请求，这些请求不会作为对先前重定向的响应。 因此，它不会为用户预先创建会话，并且不会为 id 参数存储任何值。 在这种情况下，对 _security/saml/authenticate API 的请求将类似于以下内容

POST /_security/saml/authenticate
{
  "content" : "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
  "ids" : []
}

对于 SP 发起的单点注销，IdP 可能会发回一个注销响应，Elasticsearch 可以使用 SAML 完成注销 API 对其进行验证。