我们正在考虑将 ACS 作为我们的联合 STS。我们可以将我们自己的自定义 STS 配置为 IP-STS，以及 Facebook、Live 和 Google 等“内置”身份提供商。然而，我们得到的索赔相当“差”。 ACS 中的声明转换仅在非常简单的场景中有所帮助。
我们正在寻找处理“遗失索赔”情况的最佳实践。我们认为我们需要在 ACS 前面放置一个“装饰 STS”。当 ACS 返回一个安全令牌时，这个装饰器可以用额外的声明“丰富”安全令牌。如果只是缺少声明，它可以设置一些用户界面来要求用户（一次）完成她的个人资料。这样，无论用户来自哪里，我们都有应用程序需要的声明。这是一个好主意吗 ？在这种情况下，“最佳实践”是什么？ （ACS 似乎不允许任何程序化扩展。）
【问题讨论】：
我认为答案实际上取决于具体情况。 ACS 并非旨在管理配置文件，因此它可以和应该做的事情，关于传出索赔或多或少受到设计的限制 - 它在所有情况下都是中间人。
除了管理服务身份之外，它只能处理从身份提供者那里收到的输入，并且没有管理用户配置文件或类似内容的权限。
考虑到这一点，我认为您实际上只有两个合理的选择 - 您的身份提供提供更多信息，这些信息可以通过 ACS 并可能被 ACS 转换，或者您的应用程序通过 ACS 从 IP 接收基本身份，管理其扩展配置文件。
我写过后者here
【讨论】：
您想要的称为 RP-STS，而且设置起来非常简单。联邦可以被认为是一个链，在 ACS 的情况下，这通常是 RP -> ACS -> IdP，其中令牌请求从左到右移动，令牌从右到左移动。在联邦链中，每个实体只明确知道它的邻居。你想要的是 RP -> RP-STS -> ACS -> IdP。事实上，ACS 也可以被认为是一个 RP-STS，因为它既不是身份提供者也不是依赖方。您只是在链中添加另一个链接，这没关系，因为联邦链可以任意长。
您的 RP-STS 将有两个主要操作：
在这种情况下，您实际上正在做的是将身份验证外包给 Google/FB/etc。到 ACS，因为您不想处理这些协议，然后在身份验证完成后添加您自己的值。从 ACS 的角度来看，只注册了一个 RP：您的 RP-STS。从您实际 RP 的角度来看，只有一个身份提供者：您的 RP-STS。
【讨论】：