Keystone Federation

Keystone 可以配置为与多种不同的身份提供者在多种不同的配置中集成。本规范试图讨论如何实现利用 Keystone Federation 的可插拔后端。

问题描述

在将 OpenStack charms 部署到企业客户时，他们很可能希望将 OpenStack 身份验证与现有的身份提供者（如 AD、LDAP、Kerberos 等）集成。Keystone 实现这种集成主要有两种方式：后端和 Federation。虽然本规范关注 Federation，但了解后端有助于区分两者。

以下内容不在本文档涵盖范围内

  • 与 Kerberos 的集成

  • Horizon SSO

  • 通过 SSSD 和 mod_lookup_identity 实现的 Federation LDAP

  • Keystone 在 Federation 环境中充当 IdP。

后端

当 Keystone 使用后端时，Keystone 本身知道如何管理该后端，如何与其通信以及如何处理对其的操作。这限制了 Keystone 可以支持的后端数量，因为每个新后端都需要 Keystone 本身的新逻辑。这种方法也存在负面的安全隐患。Keystone 可能需要一个后端帐户（LDAP 用户名和密码）来执行查找，这些帐户详细信息将以明文形式存储在 keystone.conf 中。此外，所有用户密码都将通过 Keystone 流动。

Keystone 项目将 SQL 和 LDAP（包括 AD）突出显示为他们支持的后端。这些支持的状态如下

  • SQL：目前由 keystone charm 支持。

  • LDAP：目前由 keystone 和 keystone-ldap subordinate 支持。

如果它们被独占使用，这些后端可以使用 Keystone v2 API 支持。要支持多个后端，则需要使用 Keystone v3 API，并且每个后端都与特定的 Keystone 域关联。例如，这允许服务用户位于 SQL 中，而用户位于 ldap 中。

添加新的后端是通过编写 keystone subordinate charm 并通过 keystone-domain-backend 接口将其关联到 keystone 来实现的。

启用后端通常是通过 keystone.conf 实现的

Federation

使用 Federation，Keystone 信任远程身份提供者。Keystone 使用 SAML 或 OpenID connect 等协议与该提供者通信。Keystone 依赖于本地 Apache 来管理通信，并且 Apache 将环境变量（如 REMOTE_USER）传递回 Keystone。Keystone 从与身份提供者的通信细节中抽象出来，并且永远不会看到用户的密码。在使用 Federation 时，LDAP 仍然可能是最终的后端，但它由提供 SAML/OpenID 连接的服务（如 AD Federation Service 或 Shibboleth）进行前端处理。

每个身份提供者必须与 Keystone 中的不同域关联。需要 Keystone v3 API 来支持 Federation。

兼容的身份提供者：（https://docs.openstack.org/ocata/config-reference/identity/federated-identity.html#supporting-keystone-as-a-sp）

  • OpenID

  • SAML

提议的变更

Keystone 后端和 Federation 后端可能都需要向 keystone.conf 和/或 Apache WSGI vhost 添加配置。因此，两种类型共享现有的接口是有意义的，特别是现有的接口被称为 keystone-domain-backend，它不区分两者。

本规范涵盖了使用 SAML 或 OpenID 为 keystone charm 添加 Federation 支持的更改。这将涉及扩展 keystone-domain-backend 接口以支持将配置片段传递给 Apache vhost，并创建实现 OpenID 和 SAML 的 subordinate charm。

备选方案

  • 直接向 keystone charm 添加通过 OpenID 和 SAML 进行 Federation 的支持。

  • 为通过 OpenID 和 SAML 进行 Federation 创建一个新的接口

实现

负责人

主要负责人

无

Gerrit Topic

使用 Gerrit topic “keystone_federation” 用于与本规范相关的所有补丁。

git-review -t <keystone_federation>

工作项

创建部署脚本以创建 OpenID 或 SAML 集成的测试环境

扩展 keystone-domain-backend

keystone-domain-backend 接口需要提供以下内容

  • 用于 Apache 的模块以启用

  • 要插入 Apache keystone wsgi vhost 的配置

  • 由 subordinate 触发的 Apache 重启

  • 要添加到 Keystone 的 [auth] 方法列表中的身份验证方法

  • 要插入 keystone.conf 的配置

配置 Keystone 以使用新的接口

Keystone charm 需要更新以响应上述接口描述中概述的事件

新的 keystone-openid 和 keystone-saml subordinate

新的 subordinate 需要公开连接到身份提供者所需的所有配置选项。然后，它需要使用该接口将任何所需的配置传递给 Apache 或 Keystone principle。

仓库

需要为接口和新的 subordinate 创建新项目。

文档

这需要在 subordinate 和 keystone charm 的 README 中提供文档。一篇关于部署和集成的博客将非常有用。

安全性

虽然 Keystone 后端将确定谁有权访问整个 OpenStack 部署，但此 charm 仅会更改 Keystone 和 Apache 参数，避免默认值，并应将配置留给用户。

测试

代码必须由单元测试覆盖。理想情况下，应扩展 amulet 测试以覆盖此新功能，但部署用于 Keystone 的功能性 openid 服务器可能不切实际。但是，它必须由 Mojo 规范覆盖。

依赖项

无