用于联合身份验证的直接用户映射

bp federated-direct-user-mapping

允许指定映射规则,其中有效的用户存在于后端。否则将其视为临时用户,属于名为 Federated 的服务域。

问题描述

目前映射引擎假定所有有效用户都是临时的,并且故意不执行任何数据库查找。许多云提供商希望使用云联合身份验证,以便由一流的身份提供程序处理身份验证,但用户存在于身份后端。

这个问题以多种方式表现出来,首先,当一个临时用户获得令牌时,令牌的用户部分没有“域”部分。这破坏了我们在获取令牌时建立的 API 合同。目前,使用项目通过检查令牌中是否存在“OS-FEDERATION”来解决此问题。

提议的变更

该更改的一部分是添加默认联合域的概念。也就是说,所有临时用户(不存在于后端)都将存储在默认联合域中。该域的名称将是不可变的,并且命名为 Federated

即使有许多来自许多 IdP 的用户被放置在默认的 Federated 域中,用户 ID 和名称之间也不会发生冲突,因为用户不存在于 Keystone 中,并且域是 Keystone 的概念。用户的令牌将提供有关用于进行身份验证的身份提供程序的信息。

应更改映射规则 - 云管理员应能够指定用户所属的域。如果未显式指定该属性,则表示该用户应为临时用户,并自动属于联合域。如果域不存在于后端,服务器将以适当的错误代码响应。如果指定了域属性并且存在于后端,服务器将执行用户查找并使用未作用域的令牌进行响应。稍后,该令牌将根据分配给用户的角色作用域限定到项目或域。在映射规则中指定其他组不会对用户分配的角色产生任何影响。域可以通过 idname 标识。在 user 对象中指定域的 local 规则示例

"local": [
    {
        "user": {
            "id": "{0}",
            "domain": {
                "id": "12de34"
            }
        }
    }
]

如果有效用户是临时的,将颁发未作用域的联合令牌

{
    "token": {
        "methods": [
            "saml2"
        ],
        "user": {
            "id": "username%40example.com",
            "domain": {
                "name": "Federated"
            },
            "name": "username@example.com",
            "OS-FEDERATION": {
                "identity_provider": "ACME",
                "protocol": "SAML",
                "groups": [
                    {"id": "abc123"},
                    {"id": "bcd234"}
                ]
            }
        }
    }
}

区分用户是临时用户还是非临时用户的正确方法是通过检查其在联合域中的成员资格。如果未提供任何域信息,则假定该用户是临时用户,并将使用默认联合域。

提议的更改还解决了返回不一致令牌的问题(其中用户没有域),并且客户端/中间件所需进行的特殊处理应该更少。

备选方案

无。

安全影响

利用一流的身份提供程序进行身份验证可以提高整体安全性。

通知影响

无。

其他最终用户影响

无。

性能影响

联合工作流包括更多的 HTTP 调用,以向最终用户提供令牌。

其他部署者影响

无。

开发人员影响

无。

实现

负责人

主要负责人

Marek Denis (marek-denis)

其他指派人

Steve Martinelli (stevemar) Guang Yee (gyee)

工作项

  • 为服务域 Federated 添加逻辑。

  • 映射引擎应正确处理 user 对象中的 domain 关键字。

  • 调整身份验证插件以区分临时用户身份验证和现有用户映射。

  • 对于临时用户,更改未作用域令牌的格式

依赖项

无。

文档影响

所有更改必须反映在文档中。

参考资料

为联合用户添加域 — https://review.openstack.org/#/c/110858/