To the traditional commonplace security aspects of authentication, authorization, transfer security, and identity management, I would like to add one that is less technical and conventional, but to me just as important: what is your business’s approach, or even your personal approach, to security? That is, what is your security policy? I believe that in the vast majority of cases, applications simply cannot afford not to be secured. And while security carries with it performance and throughput penalties, these should be of no concern. Simply put, it costs to live. Paying the security penalty is an unavoidable part of designing and administering modern connected applications. Gone are the days when developers could afford not to care about security and deploy applications that relied on the ambient security of the target environment, such as physical security provided by employee access cards or firewalls.

Since most developers cannot afford to become full-time security experts (nor should they), the approach I advocate for overall security policy is simple: crank security all the way up until someone complains. If the resulting application performance and throughput are still adequate with the maximum security level, leave it at that level. Only if the resulting performance is inadequate should you engage in detailed threat analysis to find out what you can trade in security in exchange for performance. In my experience, you will rarely need to actually go this route; most developers should never need to compromise security this way.

The security strategies described in this chapter follow my overall security policy. WCF’s overall approach to security is very much aligned with my own, and I will explicitly point out the few places it is not (and how to rectify it). With the noticeable exception of the BasicHttpBinding, WCF is secured by default, and even the BasicHttpBinding can easily be secured. All other WCF bindings by default authenticate all callers to the service and rely on transfer security.