CODEWITHSUNDEEP
.netwcfsecurity.net-4.0
mclark1129
mclark1129

Reputation: 7592

WCF Endpoint Security Best Practices on an Internal Network

In our organization we host many WCF services that communcate with each other on our internal network. Typically, we use netTcpBinding for these services for performance. Currently there is a debate as to whether or not enable security on the binding endpoints, and I wanted to find out if there were any specific guidelines available on determining if / when disabling security is appropriate.

I tend to favor leaving security on because

  1. It's the default setting, so it requires less configuration to use
  2. It's the default setting, so it was intended to be used more often than not
  3. It just "feels" more right to be more secure as opposed to less secure

The other side of the debate is:

  1. There's no reason to use the security assuming the network itself is secured
  2. It's less performant to use security
  3. Sometimes authentication to the service can be trickier if the client has its own clients which authenticate to it (I think this may be described as a 'Double-Hop' scenario)

I imagine no matter what the best practices are, the final answer is ultimately "it depends". However I would like to know which scenario should be favored in a production environment.

Upvotes: 1

Views: 532

Answers (3)

CodingWithSpike
CodingWithSpike

Reputation: 43738

It hadn't been mentioned yet, but I also tend to think of what kind of data you are passing around. If we are talking banking transactions or something critical, I would opt for as much security as possible. On the other hand if it is just data that is being displayed in some desktop app and isn't account numbers, social security numbers, credit card info, etc., then I see no problems with disabling it.

Also, is performance currently an issue? If there are SLA's defined and transaction times you have to meet, disabling security may be an OK thing to do.

It is so configurable because there are a lot of things to consider :)

Upvotes: 1

Kirk Broadhurst
Kirk Broadhurst

Reputation: 28728

You are right - 'it depends'.

Security is a nice thing to have but if you don't need it (i.e. you are working in a secure environment, don't need authentication) then it can have a significant overhead.

I recently worked on a project where we found that Windows Authentication was causing enormous overhead, a doubling or trebling of request size (large numbers of tiny requests). We simply turned off the authentication for a significant performance boost.

The nice thing about WCF is that security is completely configurable. Assuming you don't have any security dependencies in your code, you can very easily turn it on and off at a later date as necessary through configuration. Also assuming you're using configuration!

Upvotes: 1

Phil Degenhardt
Phil Degenhardt

Reputation: 7274

It sounds as if you already have the services running without security. So clearly somebody made the decision to go with your current configuration. I tend to rely very heavily on the 'If It Ain't Broken Don't Fix It' principle, so in your scenario changing the configuration of many WCF services would require a case to be made as to why the time and effort required should be invested to do so. Frankly, in your scenario the three points you raise in favor of security do not cut it for me.

This is quite a different scenario to making the decision for a new development or new environment. In that scenario, a default of 'Security On' (assuming minimal effort, cost and performance impact) would be my preferred option.

Upvotes: 1

Related Questions