WCF Java clients and IncludeTimestamp

11
votes

So recently we exposed a service to a Java client. Our service utilizes transport security along with username/password validation.

When attempting to call our service the client was receiving an exception about security headers. Further research indicated that WCF expects a timestamp to be included in the SOAP header passed from client. If this is not present (or variance is greater than 5 minutes) it will throw an exception.

We also found that Java clients do not pass the timestamp WCF is expected. The only workaround we found was to implement the CustomBinding and set IncludeTimestamp to false. This allowed the client to successfully call the service.

Today while looking up best practices for security with WCF I see the following on MSDN:

Set SecurityBindingElement.IncludeTimestamp to True on Custom Bindings

When you create a custom binding, you must set IncludeTimestamp to true. Otherwise, if IncludeTimestamp is set to false, and the client is using an asymmetric key-based token such as an X509 certificate, the message will not be signed.

So, my question is what is the best practice when exposing WCF (and eventually Web API) services to the outside world while utilizing SSL (Transport) to non-.NET clients???

1
javawcfsecurity
There a lot of variations between different service toolkits, I'm not sure what best practice is. I found that HTTPS with username in message or with basic auth is compatible with most toolkits. Even then, like you found, WCF errs on the more restrictive side, while Java toolkits are more lax. WCF keeps adding more flags to custom bindings to resolve these issues. – Sergey

1 Answers

1
votes

Best practice is only valid when it can be enforced. If you have no control over the client, and they cannot send a timestamp, then by all means set includetimestamp to false.