在 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 中进行相应配置。请参阅配置 Elasticsearch 以进行 SAML 身份验证

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

resp = client.security.put_role(
    name="saml-service-role",
    cluster=[
        "manage_saml",
        "manage_token"
    ],
)
print(resp)

const response = await client.security.putRole({
  name: "saml-service-role",
  cluster: ["manage_saml", "manage_token"],
});
console.log(response);

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

resp = client.security.put_user(
    username="saml-service-user",
    password="<somePasswordHere>",
    roles=[
        "saml-service-role"
    ],
)
print(resp)

const response = await client.security.putUser({
  username: "saml-service-user",
  password: "<somePasswordHere>",
  roles: ["saml-service-role"],
});
console.log(response);

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 的请求将如下所示

resp = client.security.saml_authenticate(
    content="PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
    ids=[],
)
print(resp)

const response = await client.security.samlAuthenticate({
  content:
    "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
  ids: [],
});
console.log(response);

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

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