Why doesn't my WCF endpoint throw a Max Clock Skew exception?

Question

With almost all of the (secure) WCF service endpoints in my application, if the client's system clock is set too far in the future or past, I get an exception from WCFs Clock Skew mechanism (described here: http://www.danrigsby.com/blog/index.php/2008/08/26/changing-the-default-clock-skew-in-wcf/).

However the one endpoint where my Login() method is implemented never throws this exception even though it has transport security enabled (naturally no credentials are required for it).

Why isn't the "Clock Skew mechanism" working for this endpoint? Maybe it's because clientCredentialType is set to "None"?

As an example, here's a simplified version of my configuration:

<services>
    <service name="Foo">
        <endpoint address=""
            binding="wsHttpBinding"
            bindingConfiguration="binding1"
            contract="IFoo" />
    </service>
</services>

<bindings>
    <wsHttpBinding> 
        <binding name="binding1" maxReceivedMessageSize="100000000">
            <readerQuotas maxDepth="1000000000" maxArrayLength="1000000000" maxStringContentLength="1000000000" />
            <security mode="Transport">
                <transport clientCredentialType ="None"/>
            </security>
            <reliableSession enabled="false" />
        </binding>
    </wsHttpBinding>    
</bindings>     

Answer 1

Other people have a similar problem:

http://stackoverflow.com/questions/3386216/triggering-maxclockskew-when-accessing-wcf-service

So I do not think that it is a problem with your configuration.

It appears to be, that if it does not use machine time, it does not check if there is a difference in time between the machines.

You could program your way around it, send the client machine time as a parameter in your login method, if it is different, throw an exception.

Answer 2

The security mode - security mode="Transport" - does not include time stamp in the message which cause the MaxClockSkew validation to ignore the message and not throws a security exception. Change the security mode to security mode="TransportWithMessageCredential" which include time stamps and allow the MaxClockSkew validation to test the message for time delta.