丰富的Azure ACS安全令牌

我们正在考虑将ACS作为我们的联合STS。我们可以将我们自己定制的STS配置为IP-STS，以及Facebook，Live和Google等“内置”身份提供商。然而，我们收回的索赔却相当“差”。 ACS中的索赔转换只对非常简单的情况有帮助。
我们正在寻找最佳做法来处理“失踪索赔”的情况。我们认为我们需要在ACS面前摆放“装饰STS”。当ACS返回一个安全令牌时，这个装饰器可以用其他声明“丰富”安全令牌。如果索赔完全丢失，它可以建立一些用户界面来询问用户（一次）完成其个人资料。这样，无论用户来自何处，我们都拥有应用程序所需的声明。这是一个好主意吗？这种情况下的“最佳做法”是什么？（ACS似乎不允许任何编程扩展。）丰富的Azure ACS安全令牌

来源

2013-02-09 Willy Van den Driessche

我认为答案确实取决于确切的方案。 ACS并不是要管理配置文件，因此它可以并且应该做的与传出的声明有关的限制或多或少受到设计的限制 - 它是所有其中一种情况下的中间人（man-in-the-middle）。

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

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

我写关于后者here

来源

2013-02-09 16:14:19

嗨，谢谢你的回答。由于我无法控制身份提供者（除了我自己的身份提供者），我不能让他们提供我需要的数据。您的方法将“配置文件”放置在客户端应用程序中。这种方法很有效，但我必须在每个客户端应用程序中“复制”这项工作。我想这是一个可行的方法，如果每个客户端应用程序有不同的“配置文件需求”。我有点希望把这个“外包”给STS。 – 2013-02-10 00:45:07

你想要什么叫做RP-STS，是相当简单的设置。联邦可以被认为是一个链，在ACS情况下，这通常是RP - > ACS - > IdP，其中令牌请求从左向右移动，令牌从右向左移动。在联邦链中，每个实体只明确知道其邻居。你想要的是RP - > RP-STS - > ACS - > IdP。事实上，ACS也可以被认为是RP-STS，因为它既不是身份提供者也不是依赖方。你只是在链中添加另一个链接，这是可以的，因为联邦链可以是任意长的。

你的RP-STS将有两个主要动作：

当RP发送的登录请求，包这一要求（详情如原RP的境界和回复地址，任何RP背景下，等等）在wctx中，并向ACS创建一个登录请求。
当ACS向RP-STS发送令牌时，解包上下文，添加所需的任何值（例如提示用户获取更多详细信息或查找配置文件），然后发出带有添加的声明的新令牌以及任何声称ACS发出你想要保留的声明。

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

来源

2013-02-12 21:50:39

显然，您的RP-STS可以坐在尽可能多的RP前面。 – 2013-02-12 21:52:01

丰富的Azure ACS安全令牌

回答

相关问题