WCF STS Token Expiration Problem

Question

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?

score 0 · Answer 1 · answered Sep 01 '09 at 16:12

0

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

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

answered Sep 01 '09 at 16:12

Shiraz Bhaiji

64,065
34
143
252

Yeah, I have configured message logging. The message contains the valid element with a valid NotValidOnOrAfter attribute. It is just getting ignored on the client side. – Doanair Sep 01 '09 at 17:10
That is what I thought, but I tried parsing it manually and it parses into DateTime just fine... Here is what the client receives from the server: ((GenericXmlSecurityToken)token).TokenXml.InnerXml == – Doanair Sep 01 '09 at 19:40
In your question you have "NotValidOnOrAfter" in the token it is "NotOnOrAfter", could that be the problem? – Shiraz Bhaiji Sep 02 '09 at 12:22
Yes, that was a typing mistake. – Doanair Sep 03 '09 at 22:14

WCF STS Token Expiration Problem

1 Answers1