Back from Vietnam. I survived the first 6 days without any stomach trouble, but then oh boy... for another 5 consecutive days I was in deep shit sort of speak. Long live Coca Cola!.
Okay we ran into the TimeStampHasCreationTimeInFuture, cool. Now it's not possible to extend the default bindings with the maxClockSkew setting, so you have to resort to custom bindings.
We are using basicHttpBinding for maximum interoperability, so creating a similar custom binding given this default binding here:
<basicHttpBinding>
<binding name="basic">
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName"/>
</security>
</binding>
</basicHttpBinding>
is strait forward converting this into a custom binding like this:
<customBinding>
<binding name="basic">
<security authenticationMode="UserNameOverTransport">
<localClientSettings maxClockSkew="00:10:00"/>
<localServiceSettings maxClockSkew="00:10:00"/>
</security>
<textMessageEncoding messageVersion="Soap11"/>
<httpsTransport/>
</binding>
</customBinding>
First you apply the security element which enables you to set the maxClockSkew values.
MaxClockSkew has a default value of 5 minutes and using svcutil to generate the client config, it stays that way ;-), correct svcutil does not pick up the server side values so you would have to set them manually afterwards.
Next we setup the mandatory encoding element and the soap version, in our case we use text encoding and soap 1.1 for maximum interoperability with external clients.
We finish our custom binding with specifying the mandatory transport element, which in our case is HTTPS securing a username token.
Off topic:
Say you're not concerned about interoperability but instead are picking a battles with the paranoid it-guys responsible for the all the firewalls in the company. These guys tends to lock down every port but port 80, 443. <rant>They even close port 1433 behind firewalls forcing us to write "rpc" services! don't get me started. ;-)</rant>
In situations like that I would recommend using a custom binding also but with a binary encoding instead.
For example given the above bindings you could build your custom binding exactly the same way but with a binary message encoding instead.
<customBinding>
<binding name="basic">
<security authenticationMode="UserNameOverTransport">
<localClientSettings maxClockSkew="00:10:00"/>
<localServiceSettings maxClockSkew="00:10:00"/>
</security>
<binaryMessageEncoding />
<httpsTransport/>
</binding>
</customBinding>
Performance is optimal with the binary encoder and you keep the it-guys happy.
"As long as you're going to be thinking anyway, THINK BIG."
- Donald Trump
9:38:38 PM 
|
