What's the difference between Transport security & Message security in WCF

Question

I'm looking into WCF & Security. There are several security modes but the big picture is that there are 2 main "layers" you can secure : Transport or Message.

Can someone explain this in more depth please? What do I have to imagine when I'm securing Transport, how does it work, etc.

Answer 1

it is pretty much as you'd expect, transport security secures the transport - e.g. SSL over HTTP, whereas message security secures messages. Here's an msdn overview for reasons to use message security: http://msdn.microsoft.com/en-us/library/ms733137.aspx

and an overview for transport: http://msdn.microsoft.com/en-us/library/ms729700.aspx

(From the message security link): Windows Communication Foundation (WCF) has two major modes for providing security (Transport and Message) and a third mode (TransportWithMessageCredential) that combines the two. This topic discusses message security and the reasons to use it.

What Is Message Security?

Message security uses the WS-Security specification to secure messages. The WS-Securityspecification describes enhancements to SOAP messaging to ensure confidentiality, integrity, and authentication at the SOAP message level (instead of the transport level).

In brief, message security differs from transport security by encapsulating the security credentials and claims with every message along with any message protection (signing or encryption). Applying the security directly to the message by modifying its content allows the secured message to be self-containing with respect to the security aspects. This enables some scenarios that are not possible when transport security is used.

Reasons to Use Message Security

In message-level security, all of the security information is encapsulated in the message. Securing the message with message-level security instead of transport-level security has the following advantages: • End-to-end security. Transport security, such as Secure Sockets Layer (SSL) only secures messages when the communication is point-to-point. If the message is routed to one or more SOAP intermediaries (for example a router) before reaching the ultimate receiver, the message itself is not protected once an intermediary reads it from the wire. Additionally, the client authentication information is available only to the first intermediary and must be re-transmitted to the ultimate receiver in out-of-band fashion, if necessary. This applies even if the entire route uses SSL security between individual hops. Because message security works directly with the message and secures the XML in it, the security stays with the message regardless of how many intermediaries are involved before it reaches the ultimate receiver. This enables a true end-to-end security scenario.

• Increased flexibility. Parts of the message, instead of the entire message, can be signed or encrypted. This means that intermediaries can view the parts of the message that are intended for them. If the sender needs to make part of the information in the message visible to the intermediaries but wants to ensure that it is not tampered with, it can just sign it but leave it unencrypted. Since the signature is part of the message, the ultimate receiver can verify that the information in the message was received intact. One scenario might have a SOAP intermediary service that routes message according the Action header value. By default, WCF does not encrypt the Action value but signs it if message security is used. Therefore, this information is available to all intermediaries, but no one can change it.

• Support for multiple transports. You can send secured messages over many different transports, such as named pipes and TCP, without having to rely on the protocol for security. With transport-level security, all the security information is scoped to a single particular transport connection and is not available from the message content itself. Message security makes the message secure regardless of what transport you use to transmit the message, and the security context is directly embedded inside the message.

• Support for a wide set of credentials and claims. The message security is based on the WS-Security specification, which provides an extensible framework capable of transmitting any type of claim inside the SOAP message. Unlike transport security, the set of authentication mechanisms, or claims, that you can use is not limited by the transport capabilities. WCF message security includes multiple types of authentication and claim transmission and can be extended to support additional types as necessary. For those reasons, for example, a federated credentials scenario is not possible without message security. For more information about federation scenarios WCF supports, see Federation and Issued Tokens.

Answer 2

Transport security, such as Secure Sockets Layer (SSL) only secures messages when the communication is point-to-point. If the message is routed to one or more SOAP intermediaries (for example a router) before reaching the ultimate receiver, the message itself is not protected once an intermediary reads it from the wire.

Misleading. A network router or switch (OSI Layer 2 and 3) will not have access to the message content if encrypted with Transport layer security (Server side SSL certificate) since the service side SSL certificate is needed to decrypt the message. Transport layer security secures the message between the client and intended destination IP address since only the destination service provider is assumed to have the SSL private certificate which is required to decrypt the message. A SOAP intermediary would only be able to read the content if the SOAP intermediary (i.e. ESB) was in fact the intended message destination that actually establishes the encrypted transport channel with the client, ensuring a secure channel from client to server regardless of the number of network hops, routers and switches, etc (OSI layers 2 and 3).

Message Level security would add security to the message and could encrypt parts of a message if a middleware ESB (intended SOAP Intermediary) needed to read parts of a message to make routing decisions (Content Based Routing) but shouldn't be able to read other parts of a message that should only be accessed by downstream systems.