常见的 SAML 问题

编辑

下面列出了一些常见的 SAML 问题以及如何解决这些问题的提示。

  1. 症状

    Kibana 中的身份验证失败,并且 Elasticsearch 日志中打印出以下错误

    Cannot find any matching realm for [SamlPrepareAuthenticationRequest{realmName=saml1,
    assertionConsumerServiceURL=https://my.kibana.url/api/security/saml/callback}]

    解决方案

    为了启动 SAML 身份验证,Kibana 需要知道应该从 Elasticsearch 中配置的那些 SAML 领域中使用哪个 SAML 领域。您可以使用 xpack.security.authc.providers.saml.<provider-name>.realm 设置在 Kibana 中显式设置 SAML 领域的名称。它必须与在 Elasticsearch 中配置的 SAML 领域的名称匹配。

    如果您遇到类似上述的错误,则可能意味着 Kibana 配置中 xpack.security.authc.providers.saml.<provider-name>.realm 的值错误。验证它是否与 Elasticsearch 中配置的领域的名称匹配,该名称是 Elasticsearch 配置中 xpack.security.authc.realms.saml. 后面的字符串。

  2. 症状

    Kibana 中的身份验证失败,并且 Elasticsearch 日志中打印出以下错误

    Authentication to realm saml1 failed - Provided SAML response is not valid for realm
    saml/saml1 (Caused by ElasticsearchSecurityException[Conditions
    [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company....ple.com/]
    do not match required audience
    [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com]])

    解决方案

    我们收到了一个发送到另一个 SAML 服务提供商的 SAML 响应。这通常意味着 elasticsearch.yml 中配置的 SAML 服务提供商实体 ID(sp.entity_id)与 SAML 身份提供商文档中配置的 SAML 服务提供商实体 ID 不匹配。

    要解决此问题,请确保 Elasticsearch 中的 saml 领域和 IdP 都使用相同的字符串配置 SAML 服务提供商的实体 ID。

    在 Elasticsearch 日志中,在异常消息(上面)之前,还将有一条或多条 INFO 级别的消息,形式如下:

    Audience restriction
    [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com/]
    does not match required audience
    [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com]
    (difference starts at character [#68] [/] vs [])

    此日志消息可以帮助确定从 IdP 收到的值与 Elasticsearch 中配置的值之间的差异。只有当两个字符串被认为相似时,才会显示描述这两个受众标识符之间差异的括号中的文本。

    即使值类似于 URL,这些字符串也被视为区分大小写的字符串,而不是规范化的 URL。请注意尾部斜杠、端口号等。

  3. 症状

    Kibana 中的身份验证失败,并且 Elasticsearch 日志中打印出以下错误

    Cannot find metadata for entity [your:entity.id] in [metadata.xml]

    解决方案

    我们无法在配置的元数据文件(metadata.xml)中找到 SAML 实体 ID your:entity.id 的元数据。

    1. 确保您使用的 metadata.xml 文件确实是您的 SAML 身份提供商提供的文件。
    2. 确保 metadata.xml 文件包含一个 <EntityDescriptor> 元素,如下所示:<EntityDescriptor ID="0597c9aa-e69b-46e7-a1c6-636c7b8a8070" entityID="https://saml.example.com/f174199a-a96e-4201-88f1-0d57a610c522/" ... 其中 entityID 属性的值与您在 elasticsearch.yml 中的 SAML 领域配置中设置的 idp.entity_id 值相同。
    3. 请注意,这些也被视为区分大小写的字符串,而不是规范化的 URL,即使值类似于 URL。
  4. 症状

    Kibana 中的身份验证失败,并且 Elasticsearch 日志中打印出以下错误

    unable to authenticate user [<unauthenticated-saml-user>]
    for action [cluster:admin/xpack/security/saml/authenticate]

    解决方案

    此错误表示 Elasticsearch 无法处理传入的 SAML 身份验证消息。由于无法处理该消息,Elasticsearch 不知道要验证的用户是谁,因此使用 <unauthenticated-saml-user> 占位符。要诊断实际问题,您必须检查 Elasticsearch 日志以获取更多详细信息。

  5. 症状

    Kibana 中的身份验证失败,并且 Elasticsearch 日志中打印出以下错误

    Authentication to realm <saml-realm-name> failed - SAML Attribute [<AttributeName0>] for
    [xpack.security.authc.realms.saml.<saml-realm-name>.attributes.principal] not found in saml attributes
    [<AttributeName1>=<AttributeValue1>, <AttributeName2>=<AttributeValue2>, ...] or NameID [ NameID(format)=value ]

    解决方案

    此错误表示 Elasticsearch 无法在身份提供商发送的 SAML 响应中找到必要的 SAML 属性。在此示例中,Elasticsearch 配置如下:

    xpack.security.authc.realms.saml.<saml-realm-name>.attributes.principal: AttributeName0

    此配置意味着 Elasticsearch 期望在 SAML 响应中找到名称为 AttributeName0 的 SAML 属性或具有适当格式的 NameID,以便将其映射principal 用户属性。principal 用户属性是必需的属性,因此,如果此映射无法发生,则身份验证将失败。

    如果您尝试映射 NameID,请确保预期的 NameID 格式与发送的格式匹配。有关更多详细信息,请参见特殊属性名称

    如果您尝试映射 SAML 属性,而该属性不在错误消息中的列表中,则可能意味着您拼写错误了属性名称,或者 IdP 没有发送此特定属性。您可以使用列表中的另一个属性映射到 principal,或者咨询您的 IdP 管理员以确定是否可以发送所需的属性。

  6. 症状

    Kibana 中的身份验证失败,并且 Elasticsearch 日志中打印出以下错误

    Cannot find [{urn:oasis:names:tc:SAML:2.0:metadata}IDPSSODescriptor]/[urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect] in descriptor

    解决方案

    此错误表示您的身份提供商的 SAML 元数据不包含具有 HTTP-Redirect 绑定 (urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect) 的 <SingleSignOnService> 端点。Elasticsearch 仅支持 SAML 身份验证请求的 HTTP-Redirect 绑定(并且不支持 HTTP-POST 绑定)。咨询您的 IdP 管理员以启用至少一个支持 HTTP-Redirect 绑定的 <SingleSignOnService> 并更新您的 IdP SAML 元数据。

  7. 症状

    Kibana 中的身份验证失败,并且 Elasticsearch 日志中打印出以下错误

    Authentication to realm my-saml-realm failed -
    Provided SAML response is not valid for realm saml/my-saml-realm
    (Caused by ElasticsearchSecurityException[SAML Response is not a 'success' response:
     The SAML IdP did not grant the request. It indicated that the Elastic Stack side sent
     something invalid (urn:oasis:names:tc:SAML:2.0:status:Requester). Specific status code which might
     indicate what the issue is: [urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy]]
    )

    解决方案

    这意味着 SAML 身份提供商未能验证用户身份,并向服务提供商(Elastic Stack)发送了指示此失败的 SAML 响应。该消息将传达 SAML 身份提供商是否认为问题出在服务提供商(Elastic Stack)或身份提供商本身,并且后续的特定状态代码非常有用,因为它通常指示潜在问题。SAML 2.0 核心规范 - 3.2.2.2 节中定义了特定错误代码列表,最常遇到的错误代码是

    1. urn:oasis:names:tc:SAML:2.0:status:AuthnFailed:SAML 身份提供商未能验证用户身份。对于此状态,Elastic Stack 端几乎没有要排除故障的地方,SAML 身份提供商的日志应该会提供更多信息。
    2. urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy:SAML 身份提供商无法支持使用请求的格式发布 NameID。创建 SAML 身份验证请求时,Elasticsearch 使用适当的值设置身份验证请求的 NameIDPolicy 元素。这由 elasticsearch.yml 中的nameid_format配置参数控制,如果未设置,则默认为 urn:oasis:names:tc:SAML:2.0:nameid-format:transient。这指示身份提供商以该特定格式在 SAML 响应中返回 NameID。如果 SAML 身份提供商无法授予该请求,例如因为它配置为改为发布具有 urn:oasis:names:tc:SAML:2.0:nameid-format:persistent 格式的 NameID 格式,则它会返回此错误,指示 NameID 策略无效。可以通过调整 nameid_format 以匹配 SAML 身份提供商可以返回的格式或将其设置为 urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified 来解决此问题,以便身份提供商可以返回任何它想要的格式。
  8. 症状

    Kibana 中的身份验证失败,并且 Elasticsearch 日志中打印出以下错误

    The XML Signature of this SAML message cannot be validated. Please verify that the saml
    realm uses the correct SAMLmetadata file/URL for this Identity Provider

    解决方案

    这意味着 Elasticsearch 无法验证身份提供商发送的 SAML 消息的数字签名。Elasticsearch 使用包含在 SAML 元数据中的身份提供商的公钥来验证 IdP 使用其对应的私钥创建的签名。无法做到这一点可能有许多原因

    1. 正如错误消息所示,最常见的原因是使用了错误的元数据文件,因此其中包含的公钥与身份提供商使用的私钥不对应。
    2. 身份提供商的配置已更改或密钥已轮换,并且 Elasticsearch 使用的元数据文件尚未更新。
    3. SAML 响应在传输过程中已被更改,即使使用了正确的密钥也无法验证签名。

    如上所述,用于 SAML 数字签名的私钥和公钥以及自签名 X.509 证书与在传输层或 http 层上用于 TLS 的密钥和证书无关。上述故障与您的 xpack.ssl 相关配置无关。

  9. 症状

    由于启用了 SAML,用户无法使用本地用户名和密码登录 Kibana。

    解决方案

    如果您希望用户能够使用本地凭据进行 Kibana 身份验证,以及使用 SAML 领域进行单点登录,则必须在 Kibana 中启用 basic authProvider。该过程在SAML 指南中进行了说明

  10. 症状

    没有 SAML 请求 ID 值从 Kibana 传递到 Elasticsearch

    Caused by org.elasticsearch.ElasticsearchSecurityException: SAML content is in-response-to [_A1B2C3D4E5F6G8H9I0] but expected one of []

    解决方案: 此错误表示 Elasticsearch 收到了与特定 SAML 请求绑定的 SAML 响应,但 Kibana 没有明确指定该请求的 ID。这通常意味着 Kibana 找不到之前存储 SAML 请求 ID 的用户会话。

    要解决此问题,请确保在 Kibana 配置中 xpack.security.sameSiteCookies 未设置为 Strict。根据您的配置,您可以依赖默认值或显式将值设置为 None

    更多信息,请阅读 MDN SameSite Cookie

    如果您在负载均衡器后运行多个 Kibana 实例,请确保所有实例都使用 相同的安全配置

日志记录

如果之前的解决方案无法解决您的问题,请启用 SAML 领域的附加日志记录以进行进一步的故障排除。您可以通过配置以下持久性设置来启用调试日志记录。

resp = client.cluster.put_settings(
    persistent={
        "logger.org.elasticsearch.xpack.security.authc.saml": "debug"
    },
)
print(resp)
response = client.cluster.put_settings(
  body: {
    persistent: {
      'logger.org.elasticsearch.xpack.security.authc.saml' => 'debug'
    }
  }
)
puts response
const response = await client.cluster.putSettings({
  persistent: {
    "logger.org.elasticsearch.xpack.security.authc.saml": "debug",
  },
});
console.log(response);
PUT /_cluster/settings
{
  "persistent": {
    "logger.org.elasticsearch.xpack.security.authc.saml": "debug"
  }
}

或者,您可以将以下几行添加到 ES_PATH_CONF 中的 log4j2.properties 配置文件的末尾。

logger.saml.name = org.elasticsearch.xpack.security.authc.saml
logger.saml.level = DEBUG

有关更多信息,请参阅 配置日志级别