在 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 验证此响应。