"Invalid or expired security context token" when running after a debugging restart

Question

I have a WCF App that I am coding. I start and stop it several times as I change things and then run the service call again.

Since I need session info I am using wsHttpBinding.

Before I moved to wsHttpBinding I was using basicHttpBinding and I could stop the service, make changes and re-start it. Then I could run my WCF test client (WCF Storm) against the endpoint and it would still run fine.

Now it tells me:

The message could not be processed. This is most likely because the action 'http://tempuri.org/IMyService/MyOperation' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.

This means I have to refresh my connection and re-setup my service call (which gets annoying after several hundred times.).

I read that the security timeout is 10 minutes. I am re-running in less that 2 minutes, so I don't think it is a time out issue.

My guess is that the token expires for the obvious reason that I have killed and restarted the service.

The thing is that I don't need the security stuff at all (I only need the session stuff or I would be using BasicHttpBinding

Is there anyway to make my WCF Service not care about Security Context Tokens?

Note: My test client defaults to wsHttpBinding and has security set. But I assume that it is setting this because my service is publishing that it needs security.

Things I have tried:

• I have tried a configuration similar to what I found Here

  <bindings>
      <wsHttpBinding>
          <binding name="WsEventLogBinding">
              <security mode="Message">
                  <message establishSecurityContext="false" />
              </security>
           </binding>
      </wsHttpBinding>
  </bindings>
  

But I don't really know what this means or if it is what I need (which is no security at all (for now)).

This did not remove the issue.

• Setting <security mode="None"> This did not help.

Caldeira

would you be able to post the solution to a file sharing site? This way we can attempt to replicate the problem and try a number of different solutions. thx – Yippee

also, have you looked at this: #4767602 – Yippee

Answer 1

At first, you're true : basicHttpBinding does not support this due to the connectionless /stateless nature of the HTTP protocol.

But I think there is something wrong in your WCF understanding.

Session is a generic concept in WCF. It can be security-based session, in which both ends of communication have agreed upon a specific secure conversation or a realiable session in which messages can be configured to be delivered in order and exactly once, ensuring messages are received even when messages travel across multiple nodes during the conversation.

Both modes allow you to select InstanceContextMode.PerSession. Is this really what do you want ?

WCF security relies on mutual authentication ; If both parties trust the other's credentials (based upon claims), then a secure context can be established in which all messages are exchanged in confidentiality, and all messages are signed to protect their integrity. The security session is unique and you can't reuse it in another conversation.

Here is the problem with your context: the problem is not on Server Side but on Client Side. Because something have to be kept on client and on service, rebuilding the service will flush the whole WCF context on the service (all instances & sessions will be disposed) .There is no general data store associated with WCF sessions (one difference with asp.net session), so a restart will drop everything. However, the client still believe to be authenticated because of its "invalid" context.

To solve this, there is a checkbox for this scenario on the default Wcf Test Client: "Start a new proxy". On WCf Storm, there is a general config in Under the hood/Miscellaneous "always create new proxy".

Note : On production, you will never have this scenario because your service will always be up.

If you follow me you may want to try reliable Session. You can test but I'm not sure this will work.

<wsHttpBinding>
    <binding name="wsHttpBindingConfiguration">
        <security mode="None" />
        <reliableSession enabled="true" />
    </binding>
</wsHttpBinding>

Important Note : I don't know your WCF level, but in WCF, Clients and Services must have synchronized configurations (same security, session settings, ...)

Napoli

Answer 2

wsHttpBinding has security enabled by default. Try using this on your binding configuration to disable security:

<security mode="None">
   <transport clientCredentialType="None" />
    <message establishSecurityContext="false" />
</security>

Also, you error is wsHttpBinding related. If you use sessions and restart the server, the reported security error message will appear.

According to MSDN:

A reliable session implements the WS-ReliableMessaging protocol and an in-memory transfer window to mask SOAP message-level failures and re-establishes connections in the case of transport failures.

and

The reliable session is between the sender and receiver SOAP endpoints, regardless of the number of transport connections required for connectivity between them. In short, TCP reliability ends where the transport connection ends, whereas a reliable session provides end-to-end reliability.

Sounds like the expected behaviour.

Raster

Answer 3

You can use basic http binding with TransportCredentialOnly security mode

Gormandize

That does not give any session info though... The whole reason I went to the more advanced binding is to get session info. – Caldeira

Answer 4

Security mode None should do the job.

<bindings>
    <wsHttpBinding>
        <binding name="WsEventLogBinding">
            <security mode="None" />
         </binding>
    </wsHttpBinding>
</bindings>

Dont forget to apply the bindingConfiguration="WsEventLogBinding" on your endpoint.

Cliff