Logic first, WCF security later?

Question

I'm working on a WCF service that will be communicating over net.tcp to n instances of a client app (that is being developed by another programmer in my office).

At the moment I am using net.tcp without any security as I felt setting this up at this stage wasn't necessary, at least not until we are closer to rolling out.

During the development of a WCF application, is there any harm in using a standard binding (net.tcp in my case) without security, then once the business logic has been completed, implement all the security requirements? Are there any things I need to be aware of that may not function after the implementation of security?

Answer 1

Security should be thought about from the start, and not added on at the end.

Develop a plan for your security, and implement it as you go, rather then at the end.

Reference: Microsoft .NET: Architecting Applications for the Enterprise

http://www.amazon.com/Microsoft®-NET-Architecting-Applications-PRO-Developer/dp/073562609X

Answer 2

While your overall design should consider security from the very beginning, I don't think it's a good idea to couple your components to any particular security strategy. You may very well want to use some of your components in a non-secure manner or across a different protocol which offers different security options.

So my answer is yes and no. Yes you need to think about it from the beginning, but no you should not couple your components to your security needs.

That said, since you know that you'll be using net.tcp you should be aware that transport security is turned on by default for this binding.

For tons more information, see Juval Lowy's fantastic Programming WCF Services, chapter 10. Lowy, in his ServiceModelEx library (discussed at length in the book) provides a really nice framework that you can plug in after you've created your components. Even if it's not exactly what you're looking for you can customize it to suit your needs.

Answer 3

You have two choices, bake it in from the beginning, or slap it on at the end. With security in general I would say it really does not work in the icing so you have to make a mess of your cake to get it in there.

However, the way I see your question is you already know you need to do something to solve a security issue, you just have not decided what to do. In that case I would agree with Terry that you should then design around an abstraction that allows you to plugin the eventual solution.

If I were you I would probably do a threat model and use it to consider the inputs and risks presented by your service. This will help you decide what you should do eventually and if your abstraction covers all bases.