通过颁发令牌对STS进行身份验证

我正在联合具有各种区域和极其细化的权限的应用程序。每个不同的区域都有一个联合的WCF端点可以与服务器进行通信。由于细粒度的权限，包含所有权限的单个令牌可以大到1MB，也许更多。通过颁发令牌对STS进行身份验证

要求规定在初始登录过程之后，用户的用户名和密码凭证不能保存在我们的代码库中。权限不能组合以创建更小的集合。我们正在为我们的STS实施使用Thinktecture.IdentityServer。

我建议的解决方案是在STS中将每个端点分成它自己的领域，并且STS将返回一个具有为该领域指定的权限声明的标记。为了达到这个目的，我希望有一个Auth领域，它通过用户名/密码进行身份验证，并返回一个包含用户，租户和子组ID的令牌，然后可以将其用作向其他领域进行身份验证的凭据。

设置STS发布特定于领域的令牌已经实施。剩下的唯一要求是用户名/密码不在我们的代码库内。

是否可以通过提供先前从特定领域发布的令牌来配置STS以允许进行身份验证？有没有更好的解决办法，我没有来过？

来源

2013-08-06 psaxton

是的，您可以使用由STS B发出的令牌对STS A进行身份验证。必须将STS A配置为信任STS B作为已知的身份提供者。

随着思想STS我想你可以通过配置一个新的WSStar身份提供商来做到这一点。如果一个领域STS增加另一个领域STS作为身份提供者，它应该开始接受从该领域+证书颁发的令牌。

对于WCF，一个合理的无痛的方式设立颁发的令牌渠道与WIF CreateChannelWithIssuedToken扩展方法：

http://msdn.microsoft.com/en-us/library/ee517268.aspx

1MB是个很大的令牌确实如此。可能还有其他很好的理由在不同的领域中分裂为多个STS，但是您可以通过动态地通过依赖方的策略或权限存储来动态获取权限来解决问题，在该方面令牌被消耗而不是预先计算所有来自STS方面的细化权限。但我不知道你的具体应用这么说，所以请随时告诉我走开:)

来源

2013-08-08 01:40:58

我假设这将工作，如果STS A === STS B，并会尝试这一点。如果它可行，我会将其标记为接受的答案。关于在RP上使用权限存储，由于数据存储需求，目前这是不实际的。 – psaxton

你真正想要的是重新过期的过期令牌。我们不支持这一点。也没有计划这样做。

您可以将到期时间设置为适合您的值 - 然后再强制重新登录。

1 MB令牌不是一个好主意 - 您需要往返或创建会话关联。令牌旨在描述用户身份，而不是将每个可能的值转储到它们中。

为什么RP不通过服务调用从IdP加载authZ规则？

来源

2013-08-08 11:18:55 leastprivilege

目前，该计划将从auth领域发布〜12小时到期令牌，然后使用auth领域令牌作为对其他领域的认证。据了解，IdP不会允许续订auth领域令牌。关于“RP通过服务调用从IdP加载authZ规则：”这是我不熟悉的东西。你能提供一个指导或示例实施的链接吗？ – psaxton

而不是通过令牌传输您的authZ规则。创建一个web服务，RP可以检索它们。 – leastprivilege

要深入了解多米尼克正在接受的内容，您发布的令牌中的声明应该是一系列关于主体的属性：名称，职位，职级，部门，他们的工作项目等。声明不是权限，您的STS应该不代表正在使用令牌的RP进行授权决策。它应该是RP通过策略（规则集）运行委托人的一组索赔以作出授权决定。理论和实践之间存在差异，但至少理论上这是理论。 –

通过颁发令牌对STS进行身份验证

回答

相关问题