Shadow users: Unified identity for multiple authentication sources

bp shadow-users

本地管理的用户的处理方式与通过 LDAP 认证的用户略有不同，而通过联合身份认证的用户则有显著的不同。可用的 API、相关的 API 以及令牌验证响应都各不相同。例如，用户接收不同类型的 ID，密码可能存储在 Keystone 中，也可能不存储，并且在联合身份认证的情况下，可能无法直接接收角色分配。未来增加的认证方法可能会进一步增加复杂性。

与其继续沿着这条道路走下去，我们可以重构我们的用户持久化方式，将身份与本地管理的凭据（如果有的话）分离。结果将为终端用户和操作员提供统一的体验。

问题描述

用例

  • 一致的用户体验。 联合身份认证的用户应该与本地管理的用户的体验相同。例如，联合身份认证的用户应该能够像本地管理的用户的角色分配一样，消费本地角色分配。目前，联合身份认证的用户只能映射到用户组，并且接收带有较大负载的令牌以适应其临时性。

  • 一个用户，多个凭据。 在现实世界中，一个人拥有多种身份验证方式。例如，一个人可能携带驾驶执照、护照，并且知道一个秘密，例如信用卡验证码 (CVV)。就 OpenStack 而言，用户可能在 Keystone 中拥有密码，拥有一个私有身份提供商（例如公司 LDAP），拥有一个公共身份提供商（例如社交媒体资料），拥有一个 X.509 证书，以及在远程云上拥有的现有帐户。如果所有这些身份验证来源都同样有效，那么最终的用户和操作员体验不应该基于所选择的来源而有所不同。所有这些身份验证方式都应该绑定到相同的用户身份，而不是导致不同的身份。

    注意：我们讨论了未来可能需要将权限绑定到身份验证方法。这不在本规范的范围内，但是规范不会阻止或与未来添加此功能冲突。

  • 此外：促进多因素身份验证和帐户链接。 拥有与相同用户身份绑定的多种类型的凭据，用户可以同时使用多个凭据进行身份验证。Keystone 随后可以对用户的身份做出更强的断言，并且通往可行的多因素身份验证 (MFA) 的路径将缩短。同样，提议的更改支持将同一用户的多个帐户链接到单个帐户，并简化了对联合身份认证用户的审计。虽然本规范并未解决 MFA 或帐户链接问题，但为本规范所做的重构将使这些功能的开发更容易。

提议的变更

  1. 将用户身份与其本地管理的凭据分离。 将 user 表重构为 identity 表和本地管理的 password 表。将数据从用户表迁移到这些新表，并最终删除用户表。修改后端代码以使用新表。

  2. Shadow LDAP 和联合身份认证用户。 为映射 LDAP 和联合身份认证用户到本地身份创建新的 shadow 表。联合身份认证用户拥有 idp_id、protocol_id、显示名称以及由身份提供商断言的唯一 ID。这些是识别返回用户并为其提供一致 identity 所需的最低数据量。同样，LDAP 用户拥有用于识别用户的 ‘domain_id’ 和 ‘dn’。也就是说，有可能将 LDAP 和联合身份认证用户泛化为单个表。这将在开发期间解决。

备选方案

我们可以继续将联合身份认证用户视为临时性的。从长远来看，这要么会导致额外的元数据包含在令牌负载中，最终使 Fernet 令牌超出其预期容量，要么会导致根据用户的身份验证来源而产生越来越不同的用户体验。

安全影响

  • 用户 ID 可能会用作 OpenStack 中的授权来源，并且本规范将影响它们的控制方式。我们需要确保两个不同的用户不会被意外映射到相同的身份。最简单的解决方案是始终分配随机 UUID 作为 OpenStack 面向的用户身份。我们需要仔细考虑使用任何其他来源的影响。

  • 我们将获得从令牌中删除有关联合身份认证用户的信息的能力，从而完全消除“联合身份认证令牌”的概念。

  • 联合身份认证用户组的成员资格将变为持久的，而不是每次身份验证都临时性的。联合身份认证用户可能会在联合身份认证映射的结果中自动接收具体的角色分配，并接收反映这些角色的 Fernet 令牌。在令牌的生命周期内，操作员可能会分配或撤销其他角色，这些角色将立即反映在用户的现有令牌中。这种行为对于本地管理的用户的来说已经存在，但对于联合身份认证用户来说是新的。

通知影响

使用联合身份认证信息在令牌中进行的审计通知将不再能够访问该信息，而只能访问 v3 令牌呈现的多种身份验证方法。所有审计通知将有效地引用本地用户身份。

其他最终用户影响

所有终端用户将获得一致的 API 体验：本地管理的体验。

性能影响

  • 所有用户身份都需要在 Keystone 的本地后端中进行 shadow。这意味着即使通过身份联合进行身份验证，如果您有数百万的用户使用 Keystone 进行身份验证，他们每个人都将在 Keystone 中拥有一个记录。

  • 令牌验证的代码路径将简化，因为它们将始终引用本地用户。

  • 需要持久化的令牌格式将需要更少的磁盘或内存空间。

  • 联合身份认证用户将能够消费本地角色分配，从而略微增加令牌验证的响应时间。

其他部署者影响

  • 没有新的配置选项。

  • 即使对于完全使用身份联合的部署，也需要提供本地身份持久化。

  • 在升级期间，需要进行数据库迁移以拆分本地管理的的用户。在运行时，当 LDAP 和联合身份认证用户成功使用 Keystone 进行身份验证时，将自动创建 shadow 记录。

开发人员影响

支持替代身份验证方法的开发人员将能够引用通用的用户身份，并自行创建 shadow 记录。重要的是要注意，现有的 CRUD API 不会受到影响；只有后端正在重构。

由于联合身份认证是一个更可行的选择，因此支持使用自定义代码来引导具有角色分配的新用户的部署者可以利用联合身份认证映射来实现相同的结果，如果他们迁移到联合身份认证。

实现

负责人

主要负责人

dolph

其他贡献者

dstanek derosenet

工作项

  1. 将用户身份与其本地管理的凭据分离。

  2. 在新的数据库表中 shadow 联合身份认证和 LDAP 用户。

  3. 在评估联合身份认证映射后进行具体的角色分配。

  4. 当联合身份认证用户通过身份验证时发出的通知需要更新。

  5. 映射引擎和其他相关的后端逻辑可能需要进行一些重构。

依赖项

无。

文档影响

部署者需要了解新的本地用户持久化要求，即使在联合身份认证的情况下也是如此。

需要修改建议联合身份认证用户无法接收本地角色分配的文档。

参考资料