亚马逊AWS官方博客
向使用 SAML 和 ADFS 的 Open Distro for Elasticsearch Kibana 添加单点登录
Open Distro for Elasticsearch Security (Open Distro Security) 带有即开即用的身份验证和访问控制功能。先前的博文讨论过 LDAP 与 Open Distro for Elasticsearch 的集成以及使用 Open Distro for Elasticsearch 进行 JSON Web Token 身份验证。
安全断言标记语言 2.0 (SAML) 是一种用于与应用程序和服务提供者交换身份和安全信息的开放标准。 Open Distro Security 使用 SAML 2.0 协议的 Web 浏览器单点登录 (SSO) 配置文件。这使得您能够配置与符合 SAML 2.0 的身份提供者 (IdP) 的联合访问 – 例如 Microsoft Active Directory Federation Services (ADFS)、Okta、Auth0 和 AWS SSO。此集成仅配合 Web 浏览器使用;这并不是对用户进行身份验证的一般方法。其主要应用情况为支持 Kibana 单点登录。在本篇博文中,我们将讨论设置使用 Microsoft ADFS 的基于 SAML 的 SSO。
先决条件
- 安装并配置 Open Distro for Elasticsearch。
- 安装并配置 Kibana。记住 Kibana 服务器的 FQDN,设置
kibana_base_url
和kibana_port
(默认为 5601)。 - 在 Elasticsearch 和 Kibana 上启用 SSL(大多数身份提供者都会如此要求)。
- 使用 ADFS 的 Active Directory 已经设置。
- 创建用户并分配到的 IdP 中的组。本文中,我已创建三个用户 –
esuser1
、esuser2
和esuser3
– 和两个组 –ESAdmins
和ESUsers
组,成员关系如下所示:
用户 | Active Directory 组 | Open Distro Security 角色 |
esuser1 | ESAdmins | all_access |
esuser2 | ESUsers | readall |
esuser3 | 无数据 | 无数据 |
Active Directory Federation Services (ADFS) 配置
ADFS 在以下两方加入时发生:身份或申明提供者(我们的示例中为 Active Directory)以及依赖方(我们的示例中为 Kibana)。SAML 联合身份验证通过发布申明和在申明提供者与依赖方之间转换申明发挥作用。申明是来自可信来源的用户信息:可信来源声称信息真实,并且来源已经使用某种方式验证了用户身份。申明提供者是申明的来源。依赖方 (Kibana) 是申明去向的目标。
依赖方
将 Kibana 配置为 ADFS 中的依赖方:
1.在 ADFS 管理控制台右键单击 ADFS 并选择“添加依赖方信任”。
2.在“添加依赖方信任向导”中,选择“申明感知”并单击“开始”。
3.然后选择选项 –“手动输入依赖方的数据”并单击下一步。
4.添加适当的显示名称并单击下一步。
5.在 URL 配置屏幕中,勾选对应的框以“启用对 SAML 2.0 WebSSO 协议的支持”并输入此 Kibana URL 作为服务 URL:
https://<kibana_base_url>:<kibana_port>/_opendistro/_security/saml/acs
确保将 kibana_base_url
和 kibana_port
替换为您实际的 kibana 配置(如前所述)。我的设置中,此处为:https://new-kibana.ad.example.com:5601/
单击下一步。
6.为依赖方信任标识符添加字符串。此处您可以任意选择名称;在此演示中,我们使用 kibana-saml。您将在 Open Distro Security SAML 配置中使用此名称作为 SP-entity-id。
7.在访问控制策略中,您可以允许所有人访问 Kibana,或者限制为仅允许选定的组。注意:这只会提供用户在 Kibana 上执行身份验证的访问权。我们尚未设置 Open Distro Security 角色和权限。从用户的 AD 组到 Elasticsearch 后端角色的映射如下所示。
8.在下一个屏幕中审阅所有设置,并单击完成以将 Kibana 添加为依赖方信任。
申明规则
主体(即用户名)通常保存在 SAML 响应的 NameId
元素中。我们将创建两条申明规则,一条用于“NameId”(用户名),另一条用于“角色”(组映射)。
在“依赖方信任”中右键单击 Kibana 然后选择编辑申明发布策略…
1.NameId
在编辑申明发布策略对话框中单击添加规则…
选择转化传入申明作为规则类型,然后单击下一步。
在下一屏幕中使用以下设置:
- 申明规则名称:NameId
- 传入申明类型:Windows 账户名称
- 传出申明类型:名称 ID
- 传出名称 ID 格式:未指定
- 传递所有申明值:选中
单击完成。
2.角色
在编辑申明发布策略对话框中单击添加规则…
选择发送 LDAP 属性作为申明作为规则类型并单击下一步。
在下一屏幕中使用以下设置:
- 申明规则名称:Send-Group-as-Roles
- 属性存储:Active Directory
- LDAP 属性:令牌组 – 不合格名称(用于选择组名称)
- 传出申明类型:角色。(此处设置应该与 Open Distro Security 配置中定义的 roles_key 匹配。)
单击完成。
最后从 ADFS 下载 SAML 元数据文件并复制到 Elasticsearch 配置目录。ADFS 元数据文件可以通过 https://<ADFS FQDN>/FederationMetadata/2007-06/FederationMetadata.xml
访问
在 Open Distro Security 中配置 SAML
对于新设置,可以使用 plugins/opendistro_security/securityconfig/config.yml
更新 SAML 配置详细信息。在既有的设置中,确保从正在运行的集群检索当前 Open Distro Security 配置并使用这些文件避免丢失任何更改。有关如何使用 securityadmin.sh
的更多详细信息,请参阅 Open Distro for Elasticsearch 文档。
要使用 SAML 执行身份验证,您需要在 config.yml
的 authc
部分配置身份验证域。因为 SAML 仅在 HTTP 层上工作,您不需要任何 authentication_backend
并且可将其设置为 noop
。我建议至少添加一个其他身份验证域,例如 LDAP 或互联网用户数据库,以支持 API 在不使用 SAML 的情况下访问 Elasticsearch。对于 Kibana 和互联网 Kibana 服务器用户,您还需要添加支持基本身份验证的其他身份验证域。该身份验证域应放置于链的首位,并且 challenge
旗标应设置为 false
。配置多个身份验证机制可保证在某个机制出现故障时您仍然能进入系统。
我的配置如下所示:
authc:
basic_internal_auth_domain:
http_enabled: true
transport_enabled: true
order: 0
http_authenticator:
type: "basic"
challenge: false
authentication_backend:
type: "intern"
saml_auth_domain:
http_enabled: true
transport_enabled: false
order: 1
http_authenticator:
type: saml
challenge: true
config:
idp: metadata_file: adfs.xml entity_id: http://sts.ad.example.com/adfs/services/trust sp: entity_id: kibana-saml kibana_url: https://new-kibana.ad.example.com:5601/ roles_key: Roles exchange_key: 'AbCDefg123......'
authentication_backend:
type: noop
idp.metadata_file
:您 IdP 的 SAML 2.0 元数据文件的路径。将元数据文件放置于 Open Distro for Elasticsearch 的 config
目录。该路径必须相对于 config
目录予以指定(您也可以不指定文件,而是指定 metadata_url
)。
idp.entity_id
:这是您身份提供者的唯一 ID。您可以在 SAML 元数据中找到此 ID:
sp.entity_id
:此值应当与 ADFS 配置中的“可靠方标识符”相匹配。
kibana_url
:接收 HTTP 请求的您安装的 Kibana 基准 URL。
roles_key
:存储角色的 SAML 响应中的属性。在 ADFS 中您称呼您的申明类型为“角色”。
exchange_key
:SAML 与其他协议不同,不用于应每个请求交换用户凭据。Open Distro Security 将 SAML 响应交换为存储已验证用户属性的轻量级 JSON Web 令牌。此令牌签名所使用的交换密钥您可以自由选择。其算法为 HMAC256,所以至少应为 32 个字符。请注意,当您更改此密钥时,所有使用其签名的令牌都将立即失效。
更新 Open Distro Security 的配置
现在,运行 securityadmin.sh
以更新 Open Distro Security 的配置,如下所示:
$ /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh \
-cacert /etc/elasticsearch/root-ca.pem \
-cert /etc/elasticsearch/kirk.pem \
-key /etc/elasticsearch/kirk-key.pem \
-h <Cluster-IP-or-FQDN> \
-f <Path-to-config>/config.yml -t config
这里,我指定了根 CA 证书 (-cacert)
、管理员证书 (-cert)
和管理员私有密钥 (-key)
文件的路径。管理员证书的可识别名 (DN) 需要在 elasticsearch.yml
文件中的 opendistro_security.authcz.admin_dn
下配置。我通过明确指定配置文件位置,限制为仅对此配置文件进行此更新。
角色映射
您可以将 Open Distro Security 角色映射到用户名、后端角色和/或主机。后端角色作为身份验证和授权的一部分予以确定,在我们的示例中其为 SAML 响应的“角色”属性值。我先前关于为 Open Distro for Elasticsear 设置 LDAP 集成的博文详细叙述了配置安全角色和角色映射的方法。我将我的 AD 组 ESAdmins
映射为安全角色 all_access
,并将 AD 组 ESUsers
映射为 readall
Kibana 配置
因为大部分 SAML 特定的配置都在 Open Distro Security 之中完成,您可以通过在 kibana.yml
中添加以下语句,轻松地激活 SAML:
此外您必须将 Kibana 终端节点加入白名单,以便完成 SAML 断言的验证,以及登出终端节点:
为了测试您的配置,您必须重新启动 Kibana。
sudo systemctl restart kibana.service
测试以不同的用户身份登录
导航至 https://<<kibana url>>:5601
。您将被重定向到 ADFS 登录页面:
以读写用户 esuser1
身份登录
用户 esuser1
属于 ESAdmins
AD 组,并映射到安全角色 all_access
。允许此用户执行读写操作。
添加文档(正如所料成功):
运行搜索查询(正如所料成功):
以只读用户 esuser2
身份登录
用户 esuser2
属于 ESUsers
AD 组,并映射到安全角色 readall
。允许此用户执行只读操作。
创建文档(正如所料失败;esuser2
不是允许写入的组的成员):
运行搜索查询(正如所料成功):
以用户 esuser3
(不属于任何组)身份登录
用户 esuser3
不属于任何 AD 组,也没有映射到任何安全角色。不允许此用户执行任何操作。
运行搜索查询(正如所料失败;esuser3
不是任何组的成员):
小结
本文中,我讨论了使用 ADFS 的 Kibana 单点登录的 SAML 身份验证。有关 使用 SAML 配置 Open Distro Security 的其他配置选项,请参阅 Open Distro for Elasticsearch 文档
有问题或疑问? 希望参与讨论? 您可以在我们的论坛上获得帮助并讨论 Open Distro for Elasticsearch。您可以在这里提出问题。