分配、OAuth 和信任的统一模型¶
合并 keystone 授权模型为一个，并合并其能力。
问题描述¶
角色分配、OAuth 令牌和信任都服务于单一目的：将角色委托给资源上的执行者。资源可以是项目或域，执行者可以是用户或组。
当前架构不维护责任链来跟踪最初创建角色分配的用户，也没有任何手段来限制其使用。信任更多的是一种变通方法，而不是其自身用例的唯一解决方案。
作用域令牌代表一种短期授权，用于执行完成单个工作流所需的的一系列操作。访问控制是通过将令牌内容与策略标准匹配以及通过 keystone 调用验证令牌本身来执行的。
提议的变更¶
将分配、OAuth RequestToken 和信任统一到一个单一的统一授权模型中，包含以下信息
授权者：执行者，授权范围的委托者
受托者：执行者，接收授权者一部分权限
来源：模型特定的字段，用于祖先链跟踪，由内部维护
祖先链中当前授权之前的授权序列
创建祖先链中每个授权的代理序列
代理是实际创建授权的用户 - 不一定是父授权的授权者
严格祖先：标志，指示是否检查祖先链中的所有代理和授权是否都已启用
密封：标志，禁止创建派生授权的可能性
可执行：标志，指示执行者是否允许执行任何委托的角色 - 而不仅仅是将其委托给下一个执行者，如果密封标志设置为 False
要委托的角色
目标：授权作用域的资源（项目或域）
过期时间（可选）：限制基于此授权发出的令牌的有效时间
剩余使用次数（可选）：限制基于此授权发出的令牌数量
授权将跟踪责任链，以便任何授权始终由某个执行者授予另一个执行者。为了允许这一点，keystone 必须维护链的一致性：它必须处理链中断或更改的情况。
授权撤销必须向下级联。
授权必须具有限制其使用的选项，以便它可以用于定义的流程，而不能用于其他用途。
授权模型
字段 |
含义/示例 |
|---|---|
标识符 |
[uuid] |
用户链 |
授权者/代理/代理/…/执行者(受托者) |
授权链 |
授权/…/父授权/此授权 |
严格祖先 |
“检查，用户链和授权链引用的所有内容是否都已启用” |
密封 |
“不允许进一步授权” |
可执行 |
“可以颁发作用域限定为此授权的令牌” |
目标 |
[资源(域或项目)] |
过期时间 |
2020/12/31T23:59:59 |
剩余使用次数 |
允许发行的令牌数量 |
授权角色
角色 m2m |
|---|
授权 ID |
角色 ID |
当隐式角色功能落地时，应该能够委托一个持有被认为是隐式的角色的范围，到该 m2m 表中指定的范围。如果角色是特定于域的，则应自动尊重这一点，因为授权的作用域已经限制在域内。
备选方案¶
保持原样 - 它仍然有效且仍然可以使用。
安全影响¶
分配、信任和 OAuth1 请求令牌存储已更改
引入了新的授权 API
授权搜索通过提示使用 HTTP 查询参数
策略应更改为允许普通用户使用现有的分配 API 创建授权
令牌内容可以从实际范围更改为仅仅是对其作用域的授权的引用
通知影响¶
将像现在分配操作一样发送通知
created
deleted
禁用
updated
其他最终用户影响¶
统一授权具有以下副作用：使用信任 API 创建的授权，例如，可以通过分配 API 访问。
通过其自身的 API 暴露统一授权应遵循 python-keystoneclient 库的相应扩展。目前这不在范围内。
性能影响¶
授权逻辑与分配和信任的逻辑没有太大差异，但必须进行性能测试，因为授权应用于令牌颁发和验证。
授权使用 SQL 后端存储，因此在涉及对授权管理器或驱动程序的调用的任何请求中使用临界区时，应仔细测试以防止死锁。
其他部署者影响¶
要使用统一授权驱动程序代替其自身的分配、信任或请求令牌驱动程序，需要更改相应配置部分中的驱动程序参数并应用统一现有授权数据的迁移。
迁移影响¶
来自分配、信任和 oauth 后端的数据将被合并到一个统一的授权后端中，这将需要在升级时开发和应用特定的迁移脚本。
开发人员影响¶
开发人员应继续使用现有 API 设计。未来的工作将涉及将授权的各个方面暴露给现有 API 的最终用户。
实现¶
负责人¶
- 主要负责人
Alexander Makarov amakarov@mirantis.com
- 其他贡献者
Adam Young ayoung@redhat.com
工作项¶
工作项目或任务 – 将该功能分解为实施它需要完成的事情。这些部分可能最终由不同的人完成，但我们主要试图了解实施的时间表。
依赖项¶
此设计当前不依赖于其他规范。
此蓝图和隐式角色蓝图相关。未来的工作将一起构建这两个规范。
此规范不需要任何其他库。
文档影响¶
此更改对文档团队有什么影响？有些更改可能需要向文档团队捐赠资源以更新文档。不要重复上面讨论的细节，但请在此处引用它们。
