2

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

在此处输入图像描述

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

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

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

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

更新：这是一个代码示例和项目符号 #1的异常详细信息

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

4

1 回答 1

1

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

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

A. 如果您是自己定制的 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协议）

于 2014-05-29T16:14:00.390 回答