Overriding Protection for IPSec

How do I use username credentials with IPSec? I'm told that I need to turn on security but my connection is already secure.

WCF only permits username tokens to be transmitted over a binding that's secure. If a username and password are transmitted without some way of obscuring their values, then that essentially allows anyone that can read the message to steal those credentials. There are many meanings that could be applied to the word secure, but in this case the definition of secure is only that the binding promises to protect the data that's transmitted by providing confidentiality. IPSec is a way to provide security that's external to service. It can be used together with a binding that doesn’t ordinarily provide security, but the binding has no way of knowing that its security has been upgraded.

The mechanism for making security promises on a binding is ISecurityCapabilities. This interface defines the supported protection levels for transmitting messages as well as various other security properties. When security is externally provided, you can use this interface to pretend like the binding is more secure than it really is so that the security capabilities match the actual environment.

When using IPSec, requests and responses can be confidential and tamper-proof. This corresponds to a protection level of EncryptAndSign. This is implemented by wrapping the channel to provide a custom set of security capabilities from GetProperty. You'll want to get the ISecurityCapabilities from the underlying channel and then take the maximum of those capabilities together with the capabilities of your external security.

Next time: The Pipe DACL

Comments (2)
  1. Why doesn’t validation catch when the two sides of a reliable connection disagree about whether the session

  2. There are cases when you need to transmit username/password credentials to WCF without transport security

Comments are closed.

Skip to main content