用于 Kibana 的 SAML 身份验证 - Amazon Elasticsearch Service
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

用于 Kibana 的 SAML 身份验证

利用用于 Kibana 的 SAML 身份验证,您可以使用现有身份提供商在运行 Elasticsearch 6.7 或更高版本的域上为 Kibana 提供单一登录 (SSO)。要使用此功能,您必须启用精细访问控制

利用适用于 Kibana 的第三方身份提供商登录 Kibana、管理精细访问控制、搜索您的数据和构建可视化内容,而不是通过 Amazon Cognito内部用户数据库Amazon Elasticsearch Service进行身份验证。 支持使用 SAML 2.0 标准的提供商,例如 Okta、Keycloak、Active Directory 联合身份验证服务和 Auth0。

用于 Kibana 的 SAML 身份验证仅用于通过 Web 浏览器访问 Kibana。您的 SAML 凭证 允许您直接向 Elasticsearch或 Kibana APIs 发出 HTTP 请求。

SAML 配置概述

此页面假定您有一个现有身份提供商,并且对它有一些熟悉。我们无法仅为您的 Amazon ES 域提供确切的提供商的详细配置步骤。

Kibana 登录流可以采用以下两种形式之一:

  • 服务提供商 (SP) 已启动:您导航到 Kibana(例如,https://my-domain.us-east-1.es.amazonaws.com/_plugin/kibana),这会将您重定向到登录屏幕。登录之后,身份提供商会将您重定向到 Kibana。

  • 已启动身份提供商 (IdP):您导航到身份提供商,登录并从应用程序目录中选择 Kibana。

Amazon ES 提供两个单点登录 URLs、SP 启动和 IdP 启动,但您只需要与所需的 Kibana 登录流程匹配的登录。

在任一情况下,目标是通过您的身份提供商登录,并接收包含用户名(必需)和任何后端角色(可选但建议使用)的 SAML 断言。此信息允许精细访问控制将权限分配给 SAML 用户。在外部身份提供商中,后端角色通常称为“角色”或“组”。

注意

您无法更改 SSO URL,因此用于 Kibana 的 SAML 身份验证不支持代理服务器。

启用 SAML 身份验证

您只能对现有域启用用于 Kibana 的 SAML 身份验证,而不能在创建新域期间启用。由于 IdP 元数据文件的大小,我们强烈建议您使用 AWS 控制台。

提示

域一次仅支持一个 Kibana 身份验证方法。如果您已启用用于 Kibana 的 Amazon Cognito 身份验证,则必须先禁用它,然后才能启用 SAML。

为 Kibana 启用 SAML 身份验证(控制台)

  1. 选择域、Actions (操作)Modify authentication (修改身份验证)

  2. 选中 Enable SAML authentication (启用 SAML 身份验证)

  3. 记下服务提供商实体 ID 和两个 SSO URLs。 您只需要其中一个 SSO URLs。 有关指导,请参阅SAML 配置概述

    提示

    如果您以后为域启用URLs自定义终端节点,这些 将更改。在这种情况下,您必须更新 IdP。

  4. 使用这些值配置身份提供商。这是该过程最复杂的部分,而且遗憾的是,术语和步骤会因提供商而异。请参阅提供商的文档。

    例如,在 Okta 中,您将创建一个“SAML 2.0 Web 应用程序”。对于 Single sign on URL,指定您在步骤 3 中选择的 SSO URL。对于 Audience URI (SP Entity ID) (受众 URI (SP 实体 ID)),指定 SP 实体 ID。

    Okta 拥有用户和组,而不是用户和后端角色。对于 Group Attribute Statements (组属性语句),我们建议将 role 添加到 Name (名称) 字段,将正则表达式 .+ 添加到 Filter (筛选条件) 字段。此语句告知 Okta 身份提供商在用户进行身份验证后在 SAML 断言的 role 字段下包含所有用户组。

    在 Auth0 中,您创建一个“常规 Web 应用程序”,然后启用 SAML 2.0 附加组件。在 Keycloak 中,创建一个“客户端”。

  5. 配置身份提供商后,它会生成一个 IdP 元数据文件。此 XML 文件包含有关提供商的信息,例如 TLS 证书、单点登录终端节点和身份提供商的实体 ID。

    在 AWS 控制台中,将 IdP 元数据文件的内容复制并粘贴到 Metadata from IDP (从 IDP 获取元数据) 字段中。或者,使用 Import from XML file (从 XML 文件导入) 按钮上传元数据文件。元数据文件应如下所示:

    <?xml version="1.0" encoding="UTF-8"?> <md:EntityDescriptor entityID="entity-id" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:KeyDescriptor use="signing"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate>tls-certificate</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="idp-sso-url"/> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="idp-sso-url"/> </md:IDPSSODescriptor> </md:EntityDescriptor>
  6. 在 AWS 控制台中,将元数据文件中的 entityID 属性的内容复制并粘贴到 IDP entity ID (IDP 实体 ID) 字段中。许多身份提供商还将此值显示为配置后摘要的一部分。一些提供商将其称为“发布者”。

  7. 提供 SAML 主用户名和/或 SAML 主后端角色。此用户名和/或后端角色接收集群的完整权限(相当于新主用户),但只能在 Kibana 中使用这些权限。

    例如,在 Okta 中,您可能有一个属于组 jdoe 的用户 admins。 如果您将 jdoe 添加到 SAML 主用户名字段,则只有该用户收到完全权限。如果将 admins 添加到 SAML 主后端角色字段中,则属于 admins 组的任何用户都将收到完全权限。

    SAML 断言的内容必须与用于 SAML 主用户名和/或 SAML 主角色的字符串完全匹配。某些身份提供商在其用户名前面添加一个前缀,这可能会导致难以诊断不匹配。在身份提供商用户界面中,您可能会看到 jdoe,但 SAML 断言可能包含 auth0|jdoe。 始终使用 SAML 断言中的字符串。

    许多身份提供商都允许您在配置过程中查看示例断言,而 SAML-tracer 等工具可帮助您检查和排查真实断言的内容。断言类似于以下内容:

    <?xml version="1.0" encoding="UTF-8"?> <saml2:Assertion ID="id67229299299259351343340162" IssueInstant="2020-09-22T22:03:08.633Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">idp-issuer</saml2:Issuer> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData NotOnOrAfter="2020-09-22T22:08:08.816Z" Recipient="domain-endpoint/_plugin/kibana/_opendistro/_security/saml/acs"/> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2020-09-22T21:58:08.816Z" NotOnOrAfter="2020-09-22T22:08:08.816Z"> <saml2:AudienceRestriction> <saml2:Audience>domain-endpoint</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2020-09-22T19:54:37.274Z"> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> <saml2:AttributeStatement> <saml2:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">GroupName Match Matches regex ".+" (case-sensitive) </saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> </saml2:Assertion>
  8. 展开 Optional SAML settings (可选 SAML 设置) 部分。

  9. Subject key (主题键) 字段留空,以将 SAML 断言的 NameID 元素用于用户名。如果您的断言不使用此标准元素,而是包含用户名作为自定义属性,请在此处指定该属性。

    如果要使用后端角色(推荐),请在 Role key (角色键) 字段中指定断言的属性,例如 rolegroup。 这是 SAML-tracer 等工具可以起到作用的另一种情况。

  10. 默认情况下,Kibana 会在 60 分钟后注销用户。您可以使用 Session time to live (会话生存时间) 字段将此值增加到 1,440(24 小时)。

  11. 选择 Submit。域进入处理状态大约一分钟,在此期间,Kibana 不可用。

  12. 在域完成处理后,打开 Kibana。

    • 如果您选择了 SP 发起的 URL,请导航到 domain-endpoint/_plugin/kibana/

    • 如果您选择了 IdP 发起的 URL,请导航到身份提供商的应用程序目录。

    在这两种情况下,以 SAML 主用户或属于 SAML 主后端角色的用户身份登录。要继续步骤 7 中的示例,请以 jdoeadmins 组的成员身份登录。

  13. 在 Kibana 加载后,选择 SecurityRoles

  14. 映射角色以允许其他用户访问 Kibana。

    例如,您可以将受信任同事 jroe 映射到 all_accesssecurity_manager 角色。您还可以将后端角色 analysts 映射到 readallkibana_user 角色。

    如果您更喜欢使用 API 而不是 Kibana,请参阅以下示例请求:

    PATCH _opendistro/_security/api/rolesmapping [ { "op": "add", "path": "/security_manager", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/all_access", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/readall", "value": { "backend_roles": ["analysts"] } }, { "op": "add", "path": "/kibanauser", "value": { "backend_roles": ["analysts"] } } ]

示例 CLI 命令

以下 AWS CLI 命令在现有域上启用用于 Kibana 的 SAML 身份验证:

aws es update-elasticsearch-domain-config \ --domain-name my-domain \ --advanced-security-options '{"SAMLOptions":{"Enabled":true,"MasterUserName":"my-idp-user","MasterBackendRole":"my-idp-group-or-role","Idp":{"EntityId":"entity-id","MetadataContent":"metadata-content-with-quotes-escaped"},"RolesKey":"optional-roles-key","SessionTimeoutMinutes":180,"SubjectKey":"optional-subject-key"}}'

您必须对元数据 XML 中的所有引号和换行符进行转义。例如,使用 <KeyDescriptor use=\"signing\">\n 而不是 <KeyDescriptor use="signing"> 和一个换行符。有关使用 AWS CLI 的详细信息,请参阅 AWS CLI Command Reference

示例配置 API 请求

对配置 API 的以下请求在现有域上启用针对 Kibana 的 SAML 身份验证:

POST https://es.us-east-1.amazonaws.com/2015-01-01/es/domain/my-domain/config { "AdvancedSecurityOptions": { "SAMLOptions": { "Enabled": true, "MasterUserName": "my-idp-user", "MasterBackendRole": "my-idp-group-or-role", "Idp": { "EntityId": "entity-id", "MetadataContent": "metadata-content-with-quotes-escaped" }, "RolesKey": "optional-roles-key", "SessionTimeoutMinutes": 180, "SubjectKey": "optional-subject-key" } } }

您必须对元数据 XML 中的所有引号和换行符进行转义。例如,使用 <KeyDescriptor use=\"signing\">\n 而不是 <KeyDescriptor use="signing"> 和一个换行符。有关使用配置 API 的详细信息,请参阅Amazon Elasticsearch Service 配置 API 参考

SAML 故障排除

错误 详细信息

Your request: '/some/path' is not allowed.

验证您是否向身份提供商提供了正确的 SSO URL(步骤 3)。

Please provide valid identity provider metadata document to enable SAML.

您的 IdP 元数据文件不符合 SAML 2.0 标准。使用验证工具检查错误。

SAML 配置选项在 控制台中不可见。

更新到最新的服务软件

SAML configuration error: Something went wrong while retrieving the SAML configuration, please check your settings.

此常规错误可能由许多原因导致。

  • 检查您是否向身份提供商提供了正确的 SP 实体 ID 和 SSO URL。

  • 重新生成 IdP 元数据文件,并验证 IdP 实体 ID。在 AWS 控制台中添加任何更新的元数据。

  • 验证您的域访问策略是否允许访问 Kibana 和 _opendistro/_security/*。 一般而言,我们建议对使用精细访问控制的域使用开放访问策略。

  • 有关配置 SAML 的步骤,请参阅身份提供商的文档。

Missing role: No roles available for this user, please contact your system administrator.

您已成功进行身份验证,但 SAML 断言中的用户名和任何后端角色未映射到任何角色,因此没有任何权限。这些映射区分大小写。

使用以下调用,使用 SAML-tracer 等工具和您的角色映射验证您的 SAML 断言内容:

GET _opendistro/_security/api/rolesmapping

当尝试访问 Kibana 时,您的浏览器会持续重定向或接收 HTTP 500 错误。

如果您的 SAML 断言包含大量总计约 1,500 个字符的角色,则可能会出现这些错误。例如,如果您传递了 80 个角色,平均长度为 20 个字符,则您可能超出了 Web 浏览器中 Cookie 的大小限制。

禁用 SAML 身份验证

对 Kibana 禁用 SAML 身份验证 (控制台)

  1. 选择域、Actions (操作)Modify authentication (修改身份验证)

  2. 取消选中 Enable SAML authentication (启用 SAML 身份验证)

  3. 选择 Submit

  4. 在域完成处理后,使用以下调用验证精细访问控制角色映射:

    GET _opendistro/_security/api/rolesmapping

    禁用用于 Kibana 的 SAML 身份验证 删除 SAML 主用户名和/或 SAML 主后端 角色的映射。如果您要删除这些映射,请使用内部用户数据库 (如果启用) 登录 Kibana,或使用 API 删除它们:

    PUT _opendistro/_security/api/rolesmapping/all_access { "users": [ "master-user" ] }