Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

sometimes a programmer comes up with a brilliant idea to protect his/her webservice created with Windows Communication Foundation.

I would like to hear from you guys, which techniques do you use to protect your WCF service and avoid unauthorized users to consume it?

For example, you would:

  • avoid Impersonate, use it only if necessary
  • publish metadata information to prevent tampering
  • avoid memory consuption enforcing a maximum size quota
  • create a security context token to control number of sessions
share|improve this question
any final solution with full source code sample ? – Kiquenet Apr 16 '14 at 17:40
Maybe this is not up-to-date, but you could have a look in this technique, using ClientCredentials, passing user and password – Junior M Apr 28 '14 at 19:25

Yesterday, I found an article, a video and code about using API keys with WCF. I've got to lock down a publicly exposed web service as part of what we need to do in order to comply with PCI-DSS, and this looks like the right way to move forward. In the past, this app and webservice were used only by a VB4/5/6 (now .NET) desktop application, but the boss wants it opened up as a for-pay service to others.

One financial client used a scheme with a security information element in the SOAP header. This element had 4 attributes, one was the name of the application, the timestamp and guid elements were used to prevent replay attacks and the 4th attribute was a hash based on the name of the app, the timestamp and guid, along with a "secret" (think of a password) stored in the registry (for windows servers, or a special locked down file for unix-based servers, with different "passwords" for different application names). The "secret" (or password) was intended to prevent situations where a trojan in the datacenter would be able to make inappropriate calls, or respond to them. This was obviously not WCF as it had to support unix, windows and other operating systems in the data centers, but the technique was fascinating and could be used elsewhere. Because they used url-rewriting, the security information element would not show up in WSDLs, you had to know about it from documentation that only authorised folks received; if you added ?WSDL to the end of a webservice endpoint, you got a lie.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.