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

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

用于 Kibana 的 SAML 身份验证

针对 Kibana 的 SAML 身份验证允许您使用现有身份提供商为运行 Elasticsearch 6.7 或更高版本的 Amazon Elasticsearch Service (Amazon ES) 域上的 Kibana 提供单点登录 (SSO)。要使用 SAML 身份验证,您必须启用访问权限的精细控制。只能对新域启用精细访问控制,而不能对现有域执行此操作。通过扩展,这意味着您只能在新域或已启用精细访问控制的现有域上启用 SAML 身份验证。

而不是通过身份验证Amazon Cognito内部用户数据库,通过针对 Kibana 的 SAML 身份验证,您可以使用第三方身份提供程序登录 Kibana、管理细粒度访问控制、搜索数据以及构建可视化效果。Amazon ES 支持使用 SAML 2.0 标准的提供商,例如 Okta、键盘、活动目录联合身份验证服务 (ADFS) 和 Auth0。

注意

Amazon ES 向第三方提供商发出的请求不会使用服务提供商证书进行明确加密。

Kibana 的 SAML 身份验证仅用于通过 Web 浏览器访问 Kibana。您的 SAML 凭据执行不是允许您向弹性搜索或基巴纳 API 直接发出 HTTP 请求。

SAML 配置概述

此页假定您有一个现有的身份提供程序,并且对其熟悉程度。我们无法为您的确切供应商(仅针对您的 Amazon ES 域)提供详细的配置步骤。

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

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

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

Amazon ES 提供了两个单一登录 URL,即 SP 启动和 IDP 启动,但您只需要与所需 Kibana 登录流程匹配的一个登录 URL。如果要配置 SP-和 IDP 启动的身份验证,则必须通过身份提供商执行此操作。例如,在 Okta 中,您可以启用允许此应用程序请求其他 SSO URL并添加一个或多个 IdP 启动的 SSO URL。

无论您使用哪种身份验证类型,目标都是通过身份提供商登录并接收包含您的用户名(必需)和任何后端角色(可选,但我们建议您这样做)。此信息允许访问权限的精细控制向 SAML 用户分配权限。在外部身份提供程序中,后端角色通常称为 “角色” 或 “组”。

注意

您无法从其服务提供的值中更改 SSO URL,因此 Kibana 的 SAML 身份验证不支持代理服务器。

启用 SAML 身份验证

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

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

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

  1. 选择域,操作, 和修改身份验证

  2. Check启用 SAML 身份验证

  3. 请注意服务提供商实体 ID 和两个 SSO URL。您只需要其中一个 SSO URL。有关操作指南,请参阅 SAML 配置概述

    提示

    如果稍后启用了一个定制终端节点您的域。在这种情况下,您必须更新您的 IdP。

  4. 使用这些值配置您的身份提供商。这是过程中最复杂的部分,不幸的是,术语和步骤因供应商而异。请参阅提供商的文档。

    例如,在 Okta 中,您创建一个 "SAML 2.0 Web 应用程序。” 适用于单一登录 URL中,指定您在步骤 3 中选择的 SSO URL。适用于受众 URI (SP 实体 ID)中,指定 SP 实体 ID。

    Okta 拥有用户和组,而不是用户和后端角色。适用于组属性语句,我们建议添加role添加到名称字段和正则表达式.+添加到筛选条件字段中返回的子位置类型。此语句告诉 Okta 身份提供程序在role在用户进行身份验证后 SAML 断言的字段。

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

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

    将 IdP 元数据文件的内容复制并粘贴到IdP 中的元数据字段中的Amazon控制台。或者,使用从 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. 复制并粘贴entityID属性从元数据文件添加到IdP Entity ID字段中的Amazon控制台。许多身份提供程序还将此值显示为配置后摘要的一部分。有些提供商称之为 “发行人”。

  7. 提供SAML 主用户名和/或aSAML 主后端角色。此用户名和/或后端角色接收群集的完全权限,等同于新建主用户,但只能在 Kibana 中使用这些权限。

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

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

    许多身份提供程序允许您在配置过程中查看示例断言,以及SAML 跟踪可以帮助您检查和排除真实断言的内容。断言如下所示:

    <?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. 展开可选 SAML 设置部分。

  9. 离开使用者键字段为空,以使用NameID元素,用于用户名的 SAML 断言。如果您的断言不使用此标准元素,而是将用户名作为自定义属性,请在此处指定该属性。

    如果要使用后端角色(推荐),请在角色键字段,例如role或者group。这是另一种情况,其中像SAML 跟踪可以提供帮助。

  10. 默认情况下,Kibana 会在 60 分钟后注销用户。您可以将此值增加到 1,440(24 小时),使用生存时间字段中返回的子位置类型。

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

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

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

    • 如果选择了 IDP 启动的 URL,请导航到身份提供商的应用程序目录。

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

  13. Kibana 加载后,选择安全角色

  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 命令

以下Amazon 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">和换行符。有关使用Amazon CLI,请参阅Amazon CLI命令参考

示例配置 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 故障排除

错误 详细信息

您的请求:'/某人/路径'不允许执行。

验证您提供了正确的SSO URL(步骤 3)发送给您的身份提供商。

请提供有效的身份提供商元数据文档以启用 SAML。

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

控制台中不显示 SAML 配置选项。

更新到最新的服务软件

SAML 配置错误:检索 SAML 配置时出现问题,请检查您的设置。

出现这种通用错误的原因很多。

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

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

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

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

缺少角色:此用户没有可用的角色,请与您的系统管理员联系。

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

使用类似的工具验证 SAML 断言的内容SAML 跟踪和您的角色映射使用以下调用:

GET _opendistro/_security/api/rolesmapping

您的浏览器在尝试访问 Kibana 时不断重定向或收到 HTTP 500 错误。

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

您无法注销 ADFS。

ADFS 要求对所有注销请求进行签名,Amazon ES 不支持这一点。Remove<SingleLogoutService />从 IdP 元数据文件中强制 Amazon ES 使用其自己的内部注销机制。

禁用 SAML 身份验证

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

  1. 选择域,操作, 和修改身份验证

  2. 取消选中启用 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" ] }