Geek Answers Handbook

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

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

However, one endpoint where my Login () method is implemented never throws this exception, even though it has transport security (naturally, it does not require credentials).

Why does the Clock Clock mechanism not work for this endpoint? Maybe this is because clientCredentialType is set to No?

As an example, here is 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>
+5
source share
2 answers

Security mode - security mode = "Transport" - does not include a timestamp in the message, which causes the MaxClockSkew check to ignore the message and does not throw a security exception. Change security mode to security mode = "TransportWithMessageCredential", which includes timestamps and enable the MaxClockSkew check to check the message for a time delta.

+2
source

Other people have a similar problem:

Running MaxClockSkew when accessing the WCF service

Therefore, I do not think this is a problem with your configuration.

, , , .

, , , .

+1

More articles:


All Articles