将安全令牌从一个依赖方委派给另一个依赖方

Question

我有一个WCF服务，它是使用WIF构建的自定义STS的依赖方。我的STS向我的客户端应用程序发出持有者密钥令牌。我创建了一个新的“后端”WCF服务，我需要从现有的“前端”服务中调用它。 如何使用前端服务中的传入安全令牌来调用后端服务，而无需从STS中检索新的？

到目前为止，在我的前端服务中，使用自定义Saml11SecurityTokenHandler访问传入的SamlSecurityToken没有问题。

之后，我尝试了两种不同的方法将带外令牌附加到目标后端服务上的服务调用：

1. 创建自定义IssuedSecurityTokenProvider
2. 使用ChannelFactoryOperations.CreateChannelWithIssuedToken

但是，这两种尝试都会导致错误。从我所知，它似乎是同样的死胡同， - 他们不接受签署的SamlSecurityToken。似乎即使这两个方法都接受基本的SecurityToken类，它们只有在给定GenericXmlSecurityToken实例而不是SamlSecurityToken时才起作用。

更新： 这是一个code sample和exception details的子弹＃1

更新2： 在做了一些更多的研究之后，我能找到的最接近的一篇文章是关于使用Identity Delegation用于WIF / ADFS的文章，它基本上只使用ActAs令牌，其中前端服务将使用令牌向STS发出请求从客户端应用程序收到。这需要更新我们的自定义STS，我们希望此时不要这样做。我开始怀疑我在图中说明的方法是否对WIF或WS-Trust有效？

Answer 1

事实证明，前端服务重用已发布令牌来调用后端服务的概念在WS-Trust协议的范围内是有效的。但是，对于绝大多数情况而言，它不应被视为一种良好做法。这是由于安全性和可扩展性问题。在安全方面，这样做会迫使依赖方使用相同的令牌加密算法/密钥，并且还会降低您对SAML令牌的受众限制进行身份验证的能力。这正是更新WS-Trust以支持具有ONBEHALFOF和ACTAS令牌的身份委派的原因。利用其中任何一种都有助于以更安全和更健壮的方式处理这种确切的情况。似乎WIF API的设计遵循这一思路，这解释了为什么没有直接的API可供前端服务重用传入的签名持有者密钥令牌来调用后端服务

总之，我对这个问题有两个答案：

一个。如果您是自定义STS的所有者，则可以通过以下步骤在默认WIF / WCF管道之外实现此方案：

1. 在客户端请求程序应用程序中，使用WSTrustChannel或IssuedSecurityTokenProvider从STS手动检索令牌。请注意，令牌类型将是GenericXmlSecurityToken，或者是某种派生。
2. 将带外令牌发送到前端服务。通过带外，我的意思是将其作为额外的合同字段，邮件标题或任何其他方式发送。
3. 在前端服务中，您可以使用ChannelFactory.CreateChannelWithIssuedToken（）或创建自定义IssuedSecurityTokenProvider，轻松使用带外令牌来调用后端服务。使用传入引导令牌时，这是不可能的，因为WIF将始终创建一个特定类型的引导令牌，例如SamlSecurityToken。 ChannelFactory和IssueSecurityTokenProvider都只能使用GenericXmlSecurityToken！

B中。无论您是开箱即用的STS还是自定义STS，只要它支持ActAs或OnBehalfOf，您就可以使用适当的身份委派。

我的结论主要基于以下来源。我希望这最终有助于其他有类似要求的人。

http://www.cloudidentity.com/blog/2008/09/07/delegation-or-traversing-multilayer-architectures/ （对ACTAS / ONBEHALFOF与令牌重用的惊人解释）

http://msdn.microsoft.com/en-us/library/ee748487.aspx（向下滚动以查找ACTAS和BEHALFOF的比较）

http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html （当然是wstrust协议）