azure - 丰富 Azure ACS 安全 token

Question

我们正在考虑将 ACS 作为我们的联合 STS。我们可以将自己的自定义 STS 配置为 IP-STS，以及“内置”身份提供商，例如 Facebook、Live 和 Google。然而，我们收到的 claim 相当“差”。 ACS 中的声明转换仅在非常简单的情况下有帮助。
我们正在寻找最佳实践来处理“遗失 claim ”的情况。我们认为需要在ACS前面放置一个“装饰STS”。当 ACS 带着安全 token 返回时，该装饰器可以通过附加声明来“丰富”安全 token 。如果声明只是丢失，它可以建立一些用户界面来要求用户(一次)完成她的个人资料。这样，无论用户来自哪里，我们都可以获得应用程序所需的声明。这是一个好主意吗 ？在这种情况下，“最佳实践”是什么？ (ACS 似乎不允许任何编程扩展。)

Answer 1

您想要的称为 RP-STS，并且设置起来非常简单。联合可以被认为是一条链，在 ACS 情况下，这通常是 RP -> ACS -> IdP，其中 token 请求从左到右移动， token 从右到左移动。在联合链中，每个实体仅明确地了解其邻居。您想要的是 RP -> RP-STS -> ACS -> IdP。事实上，ACS 也可以被视为 RP-STS，因为它既不是身份提供者，也不是依赖方。您只需在链中添加另一个链接，这是可以的，因为联合链可以是任意长的。

您的 RP-STS 将有两个主要操作:

1. 当 RP 发送登录请求时，将此请求的详细信息(例如原始 RP 的领域和回复地址、任何 RP 上下文等)打包到 wctx 中，并向 ACS 创建此登录请求。
2. 当 ACS 将 token 发送回 RP-STS 时，解压上下文，添加所需的任何值(例如提示用户提供更多详细信息或查找配置文件)，然后颁发包含添加的声明和任何内容的新 token 。您想要保留的 ACS 签发的声明。

在这种情况下，您实际上所做的是将身份验证外包给 Google/FB/等。到 ACS，因为您不想处理这些协议(protocol)，然后在身份验证完成后添加您自己的值。从 ACS 的角度来看，只有一个注册的 RP:您的 RP-STS。从您实际 RP 的角度来看，只有一个身份提供商:您的 RP-STS。