0

我们正在考虑将 ACS 作为我们的联合 STS。我们可以将我们自己的自定义 STS 配置为 IP-STS，以及 Facebook、Live 和 Google 等“内置”身份提供者。然而，我们得到的索赔相当“差”。ACS 中的声明转换仅在非常简单的场景中有所帮助。
我们正在寻找处理“遗失索赔”情况的最佳实践。我们认为我们需要在 ACS 前面放置一个“装饰 STS”。当 ACS 返回一个安全令牌时，这个装饰器可以用额外的声明“丰富”安全令牌。如果只是缺少声明，它可以设置一些用户界面来要求用户（一次）完成她的个人资料。这样，无论用户来自哪里，我们都有应用程序需要的声明。这是一个好主意吗 ？在这种情况下，“最佳实践”是什么？（ACS 似乎不允许任何程序化扩展。）

4

2 回答 2

3

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

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

  1. 当 RP 发送登录请求时，将该请求的详细信息（例如原始 RP 的域和回复地址、任何 RP 上下文等）打包到 wctx 中，并创建一个到 ACS 的 this 登录请求。
  2. When ACS sends a token back to the RP-STS, unpack the context, add any value needed (such as prompting the user for more details or looking up a profile) and then issue a new token with the added claims and any claims ACS issued that you want to keep.

What you're effectively doing in this case is outsourcing the authentication to Google/FB/etc. to ACS because you don't want to deal with those protocols, and then adding your own value after authentication is complete. From ACS's point of view, there is only one RP registered: your RP-STS. From your actual RP's perspective, there is only one identity provider: your RP-STS.

于 2013-02-12T21:50:39.173 回答
1

我认为答案实际上取决于确切的情况。ACS 并非旨在管理配置文件，因此它可以和应该做什么，关于传出索赔或多或少受到设计的限制 - 它是一个中间人，在所有但一个情况下。

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

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

我在这里写过后者

于 2013-02-09T16:14:19.370 回答