다음을 통해 공유

Faking Channel Security

  • 아티클

I occasionally see people asking how they can fake the security capabilities of a binding. These questions often start off with "I'm getting an error message that a message's required protection level is not being met". Now, I'm not precisely sure why you'd want to fake the security capabilities in this case. After all, the application developer is in charge of both specifying the protection requirements of the messages and choosing what channels to use. If they're getting this error message, then it more than likely means that this helpful check has detected a problem somewhere in their design. There are a few rare reasons why you'd want to fake this, but they mainly involve transmitting over specially secured networks. However, it turns out that faking security capabilities is exactly the same as legitimately specifying the capabilities of a custom channel so I might as well explain that!

Security capabilities are found by querying the channel stack with GetProperty for an instance of ISecurityCapabilities. This call should be supported on the binding element of channels that implement message or transport security. Transport channels should respond with something, even if it is to say that they don't support any kind of security. Everyone else can just delegate the call to their inner channel (which is typically what you do by default for any type you don't know about).

 public interface ISecurityCapabilities
{
   ProtectionLevel SupportedRequestProtectionLevel { get; }
   ProtectionLevel SupportedResponseProtectionLevel { get; }
   bool SupportsClientAuthentication { get; }
   bool SupportsClientWindowsIdentity { get; }
   bool SupportsServerAuthentication { get; }
}

The fields here should be self-explanatory, you either support a particular feature or you don't, but let's look at examples from some of the existing channels.

HTTP doesn't support any protection on requests and responses, neither encryption nor signing. HTTP supports client authentication when in any security mode but Anonymous. It only supports server authentication when using Negotiate security. Windows identities are supported whenever client authentication is.

On the other hand, HTTPS provides both encryption and signing for both requests and responses. HTTPS always does server authentication. It supports client authentication and Windows identities whenever HTTP would plus whenever client certificates are turned on. You can quickly get a sense of the differences between HTTP and HTTPS by looking at these values.

Message security is a little different because the channel needs to blend its capabilities with those of the underlying channel stack. For instance, messages are encrypted if either the security channel or any of the underlying channels performed that operation.

Next time: Securing Custom Headers, Version 1

Comments

  • Anonymous
    January 17, 2007
    I have an application hosted inside a Windows service that needs to be continuously running. Occasionally

  • Anonymous
    February 07, 2007
    How do I control whether the transport signs and encrypts messages? This answer ties into the article

  • Anonymous
    March 23, 2007
    I've created a custom implementation of GetProperty for my binding but now I'm getting errors when I

  • Anonymous
    March 28, 2008
    How do I use username credentials with IPSec? I'm told that I need to turn on security but my connection

  • Anonymous
    April 14, 2008
    There are cases when you need to transmit username/password credentials to WCF without transport security