丰富Azure ACS安全令牌

Question

我们正在考虑将ACS作为我们的联合STS。我们可以将自己的自定义STS配置为IP-STS，以及Facebook、Live和Google等“内置”身份提供商。然而，我们得到的声明是相当“糟糕”的。ACS中的声明转换只在非常简单的场景中有帮助。

我们正在寻找一种最佳实践来处理“丢失索赔”的情况。我们认为我们需要在ACS前面放置一个“装饰STS”。当ACS带着一个安全令牌返回时，这个装饰器可以用额外的声明“丰富”安全令牌。如果声明只是丢失了，它可以提供一些用户界面来要求用户(只需一次)完成其配置文件。这样，无论用户来自哪里，我们都可以获得应用程序所需的声明。这是个好主意吗？这种情况下的“最佳实践”是什么？(ACS似乎不允许任何编程扩展。)

Answer 1

我认为答案真的取决于确切的场景。ACS并不意味着管理配置文件，因此它可以和应该做的事情或多或少受到设计的限制-它在所有情况下都是中间人。

除了管理服务身份之外，它只能处理从身份提供者接收到的输入，并且没有管理用户配置文件或任何类似内容的权限。

考虑到这一点，我认为你实际上只有两个合理的选择-要么你的身份提供了更多的信息，这些信息可以通过ACS传递，并可能被ACS转换，要么你的应用程序通过ACS从IP接收基本身份并管理其扩展配置文件。

我曾写过关于后一种here的文章

Answer 2

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

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

1. 当RP发送登录请求时，打包此请求的详细信息(例如，原始RP的域和回复地址、任何RP上下文等)
2. 当ACS将令牌发送回RP-STS时，解包上下文，添加所需的任何值(例如提示用户提供更多详细信息或查找配置文件)，然后发布一个新令牌，其中包含添加的声明和ACS发布的任何您要保留的声明。

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