none
Security context token invalid errors

    Question

  • I am sporadically getting the following errors on my web site when calling my WCF service:

    • An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.System.ServiceModel.FaultExceptionThe message could not be processed. This is most likely because the action 'http://tempuri.org/JobService/SearchJobReportsByCandidateId' 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.
    • An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.System.ServiceModel.FaultExceptionThe security context token is expired or is not valid. The message was not processed.

    The service config is as follows:

    <behaviors>
    <serviceBehaviors>
        <behavior name="StandardBehaviour">
         <serviceCredentials>
          <serviceCertificate findValue="localhost" storeName="My"
              x509FindType="FindBySubjectName" />
          <clientCertificate>
           <authentication certificateValidationMode="PeerOrChainTrust" revocationMode="NoCheck"/>
          </clientCertificate>
          <userNameAuthentication userNamePasswordValidationMode="Custom"
              customUserNamePasswordValidatorType="My.CustomUserNameValidator, My.Policy" />
         </serviceCredentials>
         <serviceAuthorization principalPermissionMode="Custom">
          <authorizationPolicies>
           <add policyType="My.CustomAuthorizationPolicy, My.Policy" />
          </authorizationPolicies>
         </serviceAuthorization>
        </behavior>
            <behavior name="UnsecuredBehaviour">
              <serviceCredentials>
                <clientCertificate>
                  <authentication certificateValidationMode="PeerOrChainTrust"
                    revocationMode="NoCheck" />
                </clientCertificate>
                <serviceCertificate findValue="localhost" storeName="My" x509FindType="FindBySubjectName" />
              </serviceCredentials>
            </behavior>
       </serviceBehaviors>
      </behaviors>
      <bindings>
       <netTcpBinding>
            <binding name="StandardBinding" transactionFlow="true"  maxReceivedMessageSize="65536000">
         <security mode="Message">
          <transport clientCredentialType="Certificate" />
          <message clientCredentialType="UserName" />
         </security>
      </binding>
            <binding name="UnsecuredBinding" transactionFlow="true" maxReceivedMessageSize="65536000">
              <security mode="None">
              </security>
            </binding>
       </netTcpBinding>
      </bindings>
      <services>
       <service behaviorConfiguration="StandardBehaviour" name="My.WebService">
        <endpoint address="net.tcp://localhost:0000/My.WebService"
           binding="netTcpBinding" bindingConfiguration="StandardBinding"
           name="ServiceEndpoint" contract="My.IWebService">
         <identity>
          <certificateReference storeName="My" x509FindType="FindBySubjectName"
              findValue="localhost" />
         </identity>
        </endpoint>
       </service>

    ...

    The error occurs occasionally, if the user clicks back on the browser and performs the action again, it works correctly. What could be the cause of the problem? Do I need to set some timeout values?

    Friday, January 11, 2008 12:21 AM

Answers

  • Well, we found the source of these errors, at least in our case.  In our AD, we had logonHours specified for this user preventing logging on after hours.  So when she left her account logged in and locked over night, her SCT got invalidated.

     

    The next day the proxy would fail as it was using this cached and invalidated token.  I still strongly feel that WCF should automatically renegotiate a new token.  We don't explicitly deal with the initial token negotiation, why then can WCF not renegotiate the token when needed?

     

    Also, a statement I made earlier was incorrect.  I said that rebuilding the proxy did not work, but I have evidence now that it does (i.e. it will generate a new valid token).  What we've done now is put in place an automatic retry and proxy rebuild when an error occurs on any call to the service.  This has been tested, and seems to be working fine.

     

    Thursday, July 31, 2008 4:13 PM

All replies

  • anybody got any ideas?

     

    Monday, January 21, 2008 11:03 PM
  • Do you get any solution for this problem? I am facing the same problem. I would be greatful if you share the solution with me.

    Nagesh
    Tuesday, January 29, 2008 3:24 PM
  • Bump.  We are having the same issue as well.  Why does the token become invalid?  Can someone at least point us in the general direction?

    Tuesday, February 05, 2008 5:47 AM
  • I had same problem. When I didn't send message from client to service for more than 15 hours - default timeout then this exception was thrown from proxy. I tried to change some timrouts but without any positive results. So my 'solution' was to create background thread and periodically pinging service - calling some dummy method. During this calls WCF was able to reestablish security token authomatically so proxy token has never expired.

     

    I hope that there is some better solution then this one.

    Thursday, February 14, 2008 10:15 AM
  •  

    So did any of you have any luck? Are you still having these issues? If any of you implemented any solution to eliminate these errors, please let us know. We are getting the same error(s) as well.
    Thursday, June 12, 2008 11:54 AM
  • We're getting the same error... the strange thing is that when we receive this error we've tried rebuilding the entire proxy and trying again, but get the exact same error thrown: "security context token is expired or is not valid".  Something somewhere is caching this expired token, and it is not renewing properly.

     

    In the stack trace of the thrown error, WCF is internally calling RenewKey and RenewToken... one would think this should get a new (non-expired) token, but this is obviously not happening.

     

    Stack trace:
    at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
    at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
    at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)
    at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.RenewTokenCore(TimeSpan timeout, SecurityToken tokenToBeRenewed)
    at System.IdentityModel.Selectors.SecurityTokenProvider.RenewToken(TimeSpan timeout, SecurityToken tokenToBeRenewed)
    at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.RenewKey(TimeSpan timeout)
    at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.SecureOutgoingMessage(Message& message, TimeSpan timeout)
    at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityRequestSessionChannel.Request(Message message, TimeSpan timeout)
    at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
    at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
    at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
    at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
    at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

     

    We are not doing anything particularly complicated, this is quite a straightforward application.  Everything works fine until the application is left idle for many hours.  We've implemented a multi-attempt retry, including completely rebuilding the service proxy, but nothing seems to prevent this error from being raised.

     

    Hopefully someone has some suggestions.  We can certainly implement a "ping the server" solution, but would rather find the root of the problem if at all possible.

    Monday, July 14, 2008 7:09 PM
  • Hi,

      Please check if the time on the client and the time on the server are aproximatelly equal. I've spent about 3 hours to figure this problem out, I had also exactly the same error as you have.

     

    Greetings,

    Dan

    Tuesday, July 15, 2008 7:07 AM
  • Yes, the client and server have the same time.  They are both on our local network and use the same time server.

    Tuesday, July 15, 2008 6:55 PM
  • Dan, to ensure I'm understanding you right, you had this problem and it was because of the client/server times being out of sync.  Fixing this time sync problem got rid of your errors, correct?

     

    In our case, the client/server times are in sync, so this doesn't apply to our particular case.

     

    Does anyone have any experiences that might help us understand why this error is happening for us?  If the security token expires, why isn't a new token being renegotiated automatically?

    Friday, July 25, 2008 5:14 PM
  • Well, we found the source of these errors, at least in our case.  In our AD, we had logonHours specified for this user preventing logging on after hours.  So when she left her account logged in and locked over night, her SCT got invalidated.

     

    The next day the proxy would fail as it was using this cached and invalidated token.  I still strongly feel that WCF should automatically renegotiate a new token.  We don't explicitly deal with the initial token negotiation, why then can WCF not renegotiate the token when needed?

     

    Also, a statement I made earlier was incorrect.  I said that rebuilding the proxy did not work, but I have evidence now that it does (i.e. it will generate a new valid token).  What we've done now is put in place an automatic retry and proxy rebuild when an error occurs on any call to the service.  This has been tested, and seems to be working fine.

     

    Thursday, July 31, 2008 4:13 PM
  • I was also facing same problem.
    For that check client and server binding is same or not?

    Tuesday, October 13, 2009 12:02 PM
  • How did you automate the "proxy rebuild"?
    If this post is helpful, please mark it as such!
    Dave Black, MCPD, MCTS
    http://dave-black.blogspot.com
    Thursday, July 28, 2011 5:42 PM