How to fix the WCF maxClockSkew problem in a HTTPS Silverlight application context?_问答_开发者

Situation: Silverlight 4 app communicating with a server component through WCF, using basicHttpBinding and HTTPS.

Here is the binding used server side:

<basicHttpBinding>
<binding name="DefaultSecuredBinding" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647">
      <readerQuotas maxDepth="50" maxArrayLength="2147483647" maxStringContentLength="2147483647" />
      <security mode="TransportWithMessageCredential">
        <message clientCredentialType="UserName"/>
        <transport clientCredentialType="None" proxyCredentialType="None"/>
      </security>
    </binding>
</basicHttpBinding>

Notice that we use TransportWithMessageCredential as security mode. Certificate is correctly installed on IIS.

Application runs smoothly when running locally.

However, we now have external users connecting to our application. Some of them are experiencing difficulties, and looking inside the server logs, we discovered this error:

"MessageSecurityException" The security timestamp is stale because its expiration time ('2010-10-18T22:37:58.198Z') is in the past. Current time is '2010-10-18T22:43:18.850Z' and allowed clock skew is '00:05:00'.

We did the usual research on the topics on the web (StackoverFlow & Google... and Bing), to read more on the topic. We contacted the users to ensure that they were time offset with our server, which was later confirmed.

This MSDN article was the start: http://msdn.microsoft.com/en-us/library/aa738468.aspx

Which use a CustomBinding over an existing bin开发者_JAVA技巧ding and sets the MaxClockSkew property on the SecurityBindingElement of the custom binding. We implemented this solution, changing however the SymmetricSecurityBindingElement to a TransportSecurityBindingElement, since our binding for secure communication with Silverlight is basicHttpBinding with HTTPS.

Several articles on the web (including this MSDN article listed above) show code snippets that additionally set the maxClockSkew property to a bootstrap elements taken from ProtectionTokenParameters. I never succeeded to apply this part in our code, since TransportSecurityBindingElement doesn't seem to have any ProtectionTokenParameters.

Here is our code to wrap a binding with maxClockSkew:

protected virtual System.ServiceModel.Channels.Binding WrapClockSkew(System.ServiceModel.Channels.Binding currentBinding)
    {
        // Set the maximum difference in minutes
        int maxDifference = 300;

        // Create a custom binding based on an existing binding
        CustomBinding myCustomBinding = new CustomBinding(currentBinding);

        // Set the maxClockSkew
        var security = myCustomBinding.Elements.Find<TransportSecurityBindingElement>();
        if (security != null)
        {
            security.LocalClientSettings.MaxClockSkew = TimeSpan.FromMinutes(maxDifference);
            security.LocalServiceSettings.MaxClockSkew = TimeSpan.FromMinutes(maxDifference);
        }


        return myCustomBinding;
    }

The 'security.LocalClientSettings' may be useless here, since this code is for the server side.

This code didn't do the trick, we still had the same error message on server when we had more than 5 minutes difference with the server. I still had in mind that we did not apply the bootstrap trick of the MSDN code snippet.. so we continued our web search on the topic.

We found a neat wcf behavior that, we thought, would fix our problem.

It looked like it handles Bootstrap binding matters!

Here is a part where it searches for Token Parameters in a context of a TransportSecurityBindingElement:

//If the securityBindingElement's type is TransportSecurityBindingElement
if (securityBindingElement is TransportSecurityBindingElement)
{
foreach (SecurityTokenParameters securityTokenParameters in 
    securityBindingElement.EndpointSupportingTokenParameters.Endorsing)
{
    //Gets it from the EndpointSupportingTokenParameters.Endorsing property
    if (securityTokenParameters is SecureConversationSecurityTokenParameters)
    {
        secureConversationSecurityTokenParameters =
            securityTokenParameters as SecureConversationSecurityTokenParameters;

        break;
    }
}
}

Note the 'securityBindingElement.EndpointSupportingTokenParameters.Endorsing'... In our situation (basicHttpBinding, TransportWithMessageCredential, Https...), this collection is however empty!

So, no way to retrieve the securityTokenParameters, thus impossible to set the maxClockSkew.

Questions:

Are our bindings incorrect in a SL + WCF + HTTPS context?
Is it normal to not find any way to set the maxClockSkew on a bootstrap element in a TransportSecurityBindingElement?
Are we the only company doing HTTPS Silverlight app with customers that might not be on the exact same time (with +- 5 minutes offset) ?
Why does it seem to be quite an adventure to fix such trivial configuration?

Any help would be appreciated!

The following code snippet lets you set the maxClockSkew on the TransportSecurityBindingElement. My solution is an Outlook Add-in + WCF operating in http and https contexts, so although not the same context as yours its similar.

Your bindings look correct to me.

Here's the code snippet

WSHttpBinding wsSecureBinding = new WSHttpBinding(SecurityMode.TransportWithMessageCredential, false);
wsSecureBinding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
wsSecureBinding.Security.Message.EstablishSecurityContext = true;
wsSecureBinding.Security.Message.NegotiateServiceCredential = true;
wsSecureBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;
wsSecureBinding.ReaderQuotas.MaxStringContentLength = 500000;
wsSecureBinding.ReceiveTimeout =
wsSecureBinding.SendTimeout = new TimeSpan(0, 5, 0);
CustomBinding secureCustomBinding = new CustomBinding(wsSecureBinding);
TimeSpan clockSkew = new TimeSpan(0, 15, 0);

TransportSecurityBindingElement tsecurity = secureCustomBinding.Elements.Find();
SecureConversationSecurityTokenParameters secureTokenParams = (SecureConversationSecurityTokenParameters)tsecurity.EndpointSupportingTokenParameters.Endorsing.OfType().FirstOrDefault();
if (secureTokenParams != null)
{
    SecurityBindingElement bootstrap = secureTokenParams.BootstrapSecurityBindingElement;
    // Set the MaxClockSkew on the bootstrap element.
    bootstrap.LocalClientSettings.MaxClockSkew = clockSkew;
    bootstrap.LocalServiceSettings.MaxClockSkew = clockSkew;
}

The clock skew only matters as you are using UserName client credentials and some users either like their computer clocks not being the correct time, or they don't care
Yes, WCF configuration is always an adventure you'd rather not do.

We are running into the same problem here!!! For further discussion, if this post can help, the code where it searches for Token Parameter is taken from this site

http://issues.castleproject.org/_persistent/MaxClockSkewBehavior.cs?file=44-1075&v=0&c=true

Have you tried changing to custom binding in config (instead of code) and changing maxClockSkew there? See e.g. config samples in http://social.msdn.microsoft.com/forums/en-US/wcf/thread/0e8c30ab-e5a0-40b1-9722-c1b20a09c8ad/