Keystone 到 Keystone 联合¶
bp keystone-to-keystone-federation
启用 Keystone 实例之间的身份联合，Keystone 代表用户提供跨云授权和统一的跨云服务列表。
问题描述¶
参与者¶
云实施者：部署和配置 OpenStack 云的人员或团队。
服务提供商 (SP)：提供 OpenStack 兼容云服务（公有或私有）的实体。
身份提供商 (IdP)：最终用户的联合身份提供商。负责管理最终用户身份验证的服务。
最终用户：可以访问一个或多个 OpenStack 云的身份。
在 Icehouse 版本中，我们确定了一种在 IdP 和 Keystone 之间建立信任的方法。这允许云实施者在配置云时设置单点登录，而无需承担在 Keystone 中配置身份的管理开销。Keystone 充分信任 IdP，可以接受来自他们的联合身份。但是，目前还没有 Keystone 信任另一个 Keystone 的方法。这就是一个 Keystone 信任另一个 Keystone 以向其断言联合身份的地方。
用例 1：多个转售商¶
CERN 在其数据中心内设置了一个 OpenStack 云，Keystone 身份由 LDAP 实例支持。如果他们的云资源不足，他们希望在多个公共服务提供商之间分配云工作负载。
用例 2：云爆发¶
ACME 在其数据中心内设置了一个 OpenStack 云，用于提供大型电子商务网站。他们将在黑色星期五迎来促销活动，但没有足够的基础设施来处理预期的流量。他们甚至不确定预期的流量是多少。他们希望在 SP 之间自动扩展其应用程序。
用例 3：多个内部 OpenStack¶
ACME 有多个 OpenStack 云，并且每个云都维护其自己的分配集。他们希望在多个云之间启用身份联合，以便访问每个云的身份无需维护多个令牌和凭据。
用例 4：仅存储配置¶
服务提供商希望仅向外部用户提供存储服务。因此，在任何联合中，SP 必须能够“宣传”其 Swift 服务端点，而不能宣传其他任何端点。此外，存储提供商可能希望根据其定义的角色集来强制访问策略（谁可以访问哪些容器）。因此，用户的 Keystone 必须能够获取此角色集并相应地将其分配给用户。
需求¶
该解决方案需要是递归的，因此，如果云 A 在过载时爆发到云 B，而云 B 在过载时爆发到云 C，则来自 A 的作业可以通过 B 爆发到 C。
该解决方案需要对现有的非 Keystone 组件进行最少的更改，即客户端和 OpenStack 服务都需要进行最少的更改，或者说，大部分更改应应用于 Keystone。
(A) 如果必须对客户端或 OpenStack 服务应用更改，则客户端的更改应优先于对 OpenStack 服务的更改。在这种情况下，如果只需要更改 Keystone 客户端，这将是最佳的。
或者
(B) 当前的用户体验，即非联合感知客户端使用的用户体验，不需要更改。因此，对服务的更改应优先于对客户端的更改。
该解决方案必须像 Keystone 和 Openstack 的现有实现一样安全。具体来说，我们不能通过引入 Keystone 联合来降低整体安全性。另一方面，它不需要更安全，因为攻击者总是会攻击最薄弱的环节。
该解决方案不得降低现有客户端和服务的可用功能。
该解决方案必须适用于联合用户和非联合用户。
该解决方案不应不适当地影响现有 OpenStack 服务的非功能方面，例如性能、可扩展性等。
本地 Keystone 管理员必须能够完全控制他信任的外部实体。对于直接信任关系，实现起来相对容易，但对于间接信任关系，则更为复杂，例如，Keystone A 信任 IdP 1 和外部 Keystone B，但不信任 IdP2。Keystone B 信任 IdP 1 和 IdP 2。Keystone A 必须能够阻止来自 IdP2 的用户通过此间接路由进行身份验证并访问其服务。
如果令牌被撤销（无论是被其持有者还是颁发者撤销），所有接收者（即 CSP）都需要某种方式来了解此事件。例如，有一个接收者可以联系的撤销服务，或者颁发者将其广播到其信任的 CSP，以便撤销是全面的。或者，IdP 可以发布短寿命令牌，这些令牌永远不会被撤销，例如 SAML 中那样。Keystone 应该能够处理这两种情况。
提议的变更¶
在两个实体之间建立信任。BETA，受信任的服务提供商是一个外部服务（可能是另一个 Keystone），它信任本地 Keystone 以向其断言联合身份。
这将允许云实施者显式管理信任关系。例如，BETA 是一个服务提供商。ACME 想要使用 BETA 的资源。为了在两者之间建立关系，ACME 将信任 BETA 作为服务提供商，而 BETA 将信任 ACME 作为身份提供商。这将允许 ACME 爆发到 BETA 云，但反之则不行。
ACME 的 Keystone 应该只知道 BETA 的身份验证 URL。一旦 ACME 的用户使用 ACME 进行身份验证，他们可以将他们的 Keystone 令牌转换为 BETA 可以使用的 SAML 断言。
值得注意的是，此新功能建立在现有的 Icehouse SAML 联合功能之上并利用了它。因此，它不需要修改 Keystone 消费联合断言的现有能力。相反，它只是增加了 Keystone 生成断言的能力，而不仅仅是消费它们。
BETA 的 Keystone 在接收到 SAML 断言后，需要能够将 ACME 的用户映射到 BETA 中的角色和组。
Figure 1: Creating a trust relationship
+----------+ +---------------+
| |<--- (1) Add BETA as an SP ----| |
| ACME | | ACME Cloud |
| | | Implementer |
| |<--- (2) Add IdP1 as an IdP ----| |
+----------+ +---------------+
|
| Out of Band
|
+----------+ +---------------+
| |<--- (3) Add ACME as an IdP ----| |
| BETA | | BETA Cloud |
| | | Implementer |
| |<--- (4) Add DELTA as an SP ----| |
+----------+ +---------------+
|
| Out of Band
|
+----------+ +---------------+
| |<--- (5) Add BETA as an IDP ----| |
| DELTA | | DELTA Cloud |
| | | Implementer |
| | | |
+----------+ +---------------+
图 1 所示的流程包括以下步骤
ACME 的云实施者将 BETA 添加为 V3 区域，提供 BETA 的外部身份验证 URL。
(可选) ACME 的用户可以选择本地身份验证或通过受信任的 IdP 进行身份验证。
BETA 的云实施者通过现有的 OS-FEDERATION API 将 ACME 添加为受信任的 IdP。云实施者还必须创建一个映射并将其与 ACME IdP 和协议相关联。
(可选) BETA 的云实施者将 DELTA 添加为受信任的 SP 等。
(可选) DELTA 的云实施者将 BETA 添加为受信任的 IdP 等。
Figure 2: Authentication Flow
+----------+
| |
+-------(1') IdP sends assertion ---------| IdP |
| | |
| +----------+
| |
| (1)
| Authenticates
| |
v |
+----------+ +---------------+
| | | |
| |----(2)--- Catalog returned ---->| |
| ACME | | USER |
| |<---(3)---- Scoped Token ------| |
| | | |
| |----(4)-- SAML token returned -->| |
+----------+ +---------------+
| ^
| |
| |
| |
+---------+ User authenticates | |
| |<---(5)- with SAML data from (4) -----' |
| BETA | OS-FEDERATION |
| | |
| |----(6)--- BETA token returned --------------'
+---------+
图 2 所示的流程包括以下步骤
用户使用 ACME 进行身份验证，无论是本地还是通过其本地 IdP。
用户收到一个服务目录，其中包含 ACME 的服务以及受信任服务提供商的身份服务 URL。
用户将他的作用域令牌和“BETA”（区域 ID）发送到 ACME。
ACME 云返回一个 SAML 断言。
恢复先前建立的 Icehouse 联合行为
用户使用从 (4) 返回的 SAML 断言向 BETA 进行身份验证。请注意，由于 ACME 充当用户的 IdP 的受信任代理，因此用户实际身份验证的位置（用户的 IdP）可能会丢失给 BETA，除非它在 SAML 断言中明确标识。
BETA 接收 SAML 断言并恢复已建立的联合身份验证流程。
备选方案¶
要求用户提前获得多个凭据，每个 CSP 一个，以便他们可以使用正确的本地令牌授权任何 CSP 服务。
这非常不受欢迎，因为它需要在每次信任新的 CSP 时更改客户端配置或代码，并且使客户端代码更复杂，需要处理具有不同作用域和不同到期时间的多个令牌。
所有 CSP 服务都将迎合来自任何受信任的 IdP 或代理 IdP 的用户，通过接受每个令牌发出的所有凭据，无论用户拥有哪个令牌，他都可以获得提供的服务。（这需要每个服务（例如 Swift）都更改为接受本地发行的凭据以外的任何凭据）。
这非常不受欢迎，因为它意味着每个 OpenStack 服务都需要更改才能支持远程用户
每个 CSP 托管一个本地令牌交换服务（可以是 Keystone），以便当用户到达 CSP 时，他们当前持有的任何凭据都可以交换为 CSP 服务使用的本地凭据。
如果 Keystone 成为本地令牌交换服务，这是一个可行的模型。CSP 的任何服务都不需要更改。如果用户首先点击 Keystone，它将简单地将远程令牌交换为本地令牌，然后将用户重定向到本地服务。如果用户首先点击服务，它可以简单地将从每个用户收到的每个令牌发送到本地 Keystone 进行验证，并且 Keystone 将发送服务可以用来进行授权的信息。
设置一个新的信任圈 (CoT) 令牌服务，该服务允许用户在访问远程 CSP 之前获得“国际”凭据。用户可以将这些 CoT 令牌呈现给信任圈中的每个 CSP。CSP 将 CoT 令牌发送到 CoT 服务进行验证，然后向用户提供 CSP 服务有效的本地凭据。
这也是一个可行的解决方案。如果 Keystone 向用户提供两个令牌：一个由其自身颁发，对本地服务有效，另一个由 CoT 服务颁发，对 CoT 中的所有远程服务有效。当用户访问远程 CSP 时，现在它的行为就像 iii) 上面一样，除了 CoT 令牌被发送到 CoT 服务进行验证，而不是本地 Keystone 服务，并且它返回对本地 CSP 有效的令牌。
安全影响¶
此更改会触及几个敏感数据组件，特别是令牌
如果 SP (BETA) 不希望再接受来自 IdP 的请求，则 SP 管理员可以简单地禁用 ACME IdP 条目。
如果 IdP 删除 SP，则 SP 应该删除 IdP。这是一个带外操作，超出此规范的范围。
可能的信息泄露。令牌可能包含来自 ACME 的 ID 和角色等，这些信息可供 BETA 使用。虽然这些信息目前可能不重要，但将来可能会变得重要。
这是否会增加云被破坏时的攻击面？例如，假设 ACME 与 BETA 和 DELTA 作为 SP 建立了合作伙伴关系。对 BETA 的破坏是 ACME 和 DELTA 在令牌层面的破坏。
这将不再成为问题，因为 SAML 断言是 X509 签名的。
通知影响¶
Keystone 将发出 CADF 通知（向经过身份验证和授权的身份），先前发出的断言应被撤销。
其他最终用户影响¶
python-keystoneclient 可能需要处理多个令牌（每个联合云一个令牌）。
性能影响¶
以下操作可能会影响性能
由于服务提供商可能与区域一样多，因此目录可能会变大。但是，此限制今天已经存在，因为目录可以有很多端点，并且也可能变得很大，并且用户可以访问的端点很多。
更多需要验证的证书。
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
主要负责人
stevemar (Steve Martinelli <stevemar@ca.ibm.com>)
marekd (Marek Denis <marek.denis@cern.ch>)
其他贡献者
henrynash (Henry Nash <henryn@linux.vnet.ibm.com>)
工作项¶
修改 Regions API 以定义外部身份验证 URL。
定义并实现一种存储外部 IdP 的签名密钥的方法。这项工作可能可以使用 Barbican 来完成。
定义并实现一种将 Keystone 令牌转换为 SAML 断言的方法。
定义并实现一种跨服务提供商使令牌失效的方法。
依赖项¶
无
文档影响¶
需要进行广泛的文档记录，以描述任何新的配置。
