WCF STS 令牌过期问题

发布于 2024-08-03 18:22:21 字数 2801 浏览 7 评论 0原文

我有一个受安全对话保护的 WCF 服务 (FooService)。还有一个 STS (StsService),为调用 FooService 的客户端提供令牌。代币的有效期为 15 分钟。 STS 是定制的(没有日内瓦)。客户端还具有一些自定义 WCF 扩展,以允许在客户端的生命周期内跨多个服务重复使用令牌。

当在 FooService 的通道上调用“Open”时,客户端向 STS 请求令牌。 STS 工作正常,发出令牌并向客户端提供有效的 RSTR。客户端接收反序列化的令牌(作为 GenericXmlSecurityToken 对象)。

问题

当客户端收到 GenericXmlSecurityToken 实例时,到期日期设置不正确。在 RSTR 中,有一个 SAML 标记 ,它具有有效的到期日期,但由于某种原因,WCF 似乎没有解析该标记并使用 NotOnOrAfter

这是 STS(服务器端)的绑定:

    <binding name="stsBinding" receiveTimeout="infinite" 
sendTimeout="infinite">
      <security authenticationMode="SecureConversation" requireSecurityContextCancellation="true">
        <localClientSettings maxClockSkew="23:59:59" />
        <localServiceSettings maxClockSkew="23:59:59" 
inactivityTimeout="00:02:00" />
        <secureConversationBootstrap 
authenticationMode="UserNameForSslNegotiated">
          <localClientSettings maxClockSkew="23:59:59" />
          <localServiceSettings maxClockSkew="23:59:59" />
        </secureConversationBootstrap>
      </security>
      <binaryMessageEncoding />

这是客户端绑定:

<binding name="stsBinding"
     closeTimeout="00:02:00"
     openTimeout="00:02:00"
     sendTimeout="00:02:00">
      <security authenticationMode="SecureConversation" requireSecurityContextCancellation="true">
        <localClientSettings maxClockSkew="23:59:59" />
        <localServiceSettings maxClockSkew="23:59:59" 
inactivityTimeout="00:02:00" />
        <secureConversationBootstrap 
authenticationMode="UserNameForSslNegotiated">
          <localClientSettings maxClockSkew="23:59:59" />
      <localServiceSettings maxClockSkew="23:59:59" />
    </secureConversationBootstrap>
  </security>
  <binaryMessageEncoding />
  <tcpTransport maxReceivedMessageSize="2097152"
                maxBufferSize="2097152" maxPendingConnections="10"
                listenBacklog="10" />
</binding>

我尝试了几种方法来显示正确的到期日期......但似乎没有任何效果。尝试实现自定义序列化器。找不到 的任何踪迹。还尝试直接调用 STS,然后将令牌提供回 WCF。该解决方案有效,直接调用 STS 并将响应反序列化为有效的 SecurityToken,但是当将其提供回 WCF 时,通道上的“Open”调用会在 2 分钟后超时。没有错误消息,跟踪日志中没有任何内容...

在客户端,令牌具有 SAML 断言。如果我查看:((GenericXmlSecurityToken)token).TokenXml.InnerXml,这就是我所看到的:

<saml:Conditions 
NotBefore="2009-09-01T19:36:54.669Z" 
NotOnOrAfter="2009-09-01T19:41:54.669Z" 
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
</saml:Conditions>

甚至尝试单步执行 .NET Framework 源代码,但无法在 Windows 7 上使用 VS 2008 SP1 执行此操作不工作!嗯!

有什么想法吗?

I have a WCF service (FooService) protected by Secure Conversation. Also have an STS (StsService) that provides tokens to clients calling FooService. The tokens are good for 15 minutes. The STS is custom-build (no Geneva). The client also has some custom WCF extensions to allow re-use of the token across several services during the lifetime of the client.

The client requests a token from the STS when "Open" on the channel to FooService is called. The STS works fine, issues the token and provides a valid RSTR back to the client. The client receives the de-serialized token (as a GenericXmlSecurityToken object).

Problem:

When the client receives the GenericXmlSecurityToken instance, the expiration date is NOT set correctly. In the RSTR, there is a SAML tag <saml:Conditions> which has the valid expiration date BUT, for some reason, WCF does not seem to be parsing the tag and using the value of NotOnOrAfter.

Here is the binding for the STS (server-side):

    <binding name="stsBinding" receiveTimeout="infinite" 
sendTimeout="infinite">
      <security authenticationMode="SecureConversation" requireSecurityContextCancellation="true">
        <localClientSettings maxClockSkew="23:59:59" />
        <localServiceSettings maxClockSkew="23:59:59" 
inactivityTimeout="00:02:00" />
        <secureConversationBootstrap 
authenticationMode="UserNameForSslNegotiated">
          <localClientSettings maxClockSkew="23:59:59" />
          <localServiceSettings maxClockSkew="23:59:59" />
        </secureConversationBootstrap>
      </security>
      <binaryMessageEncoding />

Here is the client-side binding:

<binding name="stsBinding"
     closeTimeout="00:02:00"
     openTimeout="00:02:00"
     sendTimeout="00:02:00">
      <security authenticationMode="SecureConversation" requireSecurityContextCancellation="true">
        <localClientSettings maxClockSkew="23:59:59" />
        <localServiceSettings maxClockSkew="23:59:59" 
inactivityTimeout="00:02:00" />
        <secureConversationBootstrap 
authenticationMode="UserNameForSslNegotiated">
          <localClientSettings maxClockSkew="23:59:59" />
      <localServiceSettings maxClockSkew="23:59:59" />
    </secureConversationBootstrap>
  </security>
  <binaryMessageEncoding />
  <tcpTransport maxReceivedMessageSize="2097152"
                maxBufferSize="2097152" maxPendingConnections="10"
                listenBacklog="10" />
</binding>

I have tried several things to get the correct expiration date to show-up... but nothings seems to work. Tried implementing a custom Serializer. Could not find any trace of <saml:Conditions>. Also tried calling the STS directly, then providing the token back to WCF. That solution worked, calling the STS directly and de-serializing the response into a valid SecurityToken, but when it is provided back to WCF, the "Open" call on the channel times-out after 2 mintues. No error message, nothing in the trace log...

On the client-side, the token has the SAML assertion. If I look at: ((GenericXmlSecurityToken)token).TokenXml.InnerXml, this is what I see:

<saml:Conditions 
NotBefore="2009-09-01T19:36:54.669Z" 
NotOnOrAfter="2009-09-01T19:41:54.669Z" 
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
</saml:Conditions>

Even tried stepping through the .NET Framework source, but cannot do that with VS 2008 SP1 on Windows 7. DOES NOT WORK! Arg!

Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

孤蝉 2024-08-10 18:22:21

您可以尝试配置消息日志记录,以检查实际发送的内容。

http://msdn.microsoft.com/en-us/library/ms730064。 ASPX

You could try configuring message logging, to check what is actually being sent.

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文