Wcf Transport VS Message

WCF Transport vs Message

Security in WCF actually consists of several features. The difference between those two is how are messages signed and encrypted.

Transport security provides only point-to-point channel security. It means that HTTPS establish secure channel only between client and server exposed to client. But if this server is just a load balancer or reverse proxy server it has direct access to content of the message.

Message security provides end-to-end channel security. It means that security is part of transferred data and only intended destination can decrypt the data (load balancer or proxy sees only encrypted message). Message security in most cases also uses certificates to provide encryption and signing but it is usually slower because transport security can use HW acceleration.

In advanced scenarios these methods can be combined. For example you can have communication to your load balancer secured by HTTPS because you trust your internal network after load balancer but in the same time you can have the message signed (message security) so you can prove that it wasn't changed.

Another difference between those two is that transport security is related to single transport protocol whereas message security is independent on transport protocol.

Message security is based on interoperable protocols (but be aware that not every configuration in WCF is interoperable). WCF supports at least partially these protocols:

  • WS-Security 1.0 and 1.1 - basic rules for encryption, signing, token transport, timestamps, etc.
  • UserName token profile 1.0 - definition of token used for transporting user name and password. This specification is implemented only partially because WCF out of the box doesn't support digested password and requires using this token either with transport or message encryption.
  • X509 token profile 1.1 - definition of token used for transporting certificates.
  • Kerberos token profile 1.1 - definition of token used for transporting Kerberos tickets.
  • SAML 1.1 token profile 1.0 and 1.1 - definition of token used for federated security. SAML 2.0 is provided by WIF.
  • WS-SecurityPolicy 1.1 and 1.2 - provides support for defining security assertion in WSDL.
  • WS-SecureConversation 1.3 and Feb. 2005 - provides support for security session where credentials are exchanged only during first call and rest of the communication uses unique security token.
  • WS-Trust 1.3 and Feb. 2005 - provides support for federated scenarios and Security token services (STS).

WCF also supports WS-I Basic Security Profile 1.0 which is just subset of former protocols with prescribed configuration.

For non interoperable features WCF offers features like Windows security or TLSNego and SPNego (both should be generally interoperable but their are not available in many SOAP stacks) for service credentials exchange.

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

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.

WCF Transport & Message level Security

In WCF the two security models as you presented effect two different things you can secure the transport (tcp or http) or the message (the protocol).

Transport security is depended on the binding selected but provides you the ability to secure you transport in the case of wsHttpBinding you can use SSL. Transport security provide a limited selection of authentication like basic, certificate, digest, windows, and ntlm but there are more and they re entirely depended on the transport.

Message security on the other hand it provides you the ability to go full end-to-end security (with transport security), increased flexibility like secure only parts of a message, it support multiple transports and various credentials and claims.

There is also a third type of security mode called TransportWithMessageCredential which incorporate both.

Transport security has the following advantages:

  • Does not require that the communicating parties understand XML-level
    security concepts. This can improve the interoperability, for
    example, when HTTPS is used to secure the communication.
  • Generally improved performance.
  • Hardware accelerators are available.
  • Streaming is possible.

Transport security has the following disadvantages:

  • Hop-to-hop only.
  • Limited and inextensible set of credentials.
  • Transport-dependent.

Message security has the following disadvantages:

  • Performance
  • Cannot use message streaming.
  • Requires implementation of XML-level security mechanisms and support
    for WS-Security specification. This might affect the
    interoperability.

My suggestion would be for you to visit the Developer Network security section for WCF

There are numerous examples there and plenty of help online too.

I hope this explains things for you if you need further details just let us know.

Which transport security or message security?

First of all, both approaches are secure and will suffice for 90% of cases. Transport security secures your channel of communication, but doesn't encrypt your actual message. Message security encrypts your actual message, so servers that the message is passed through can not see the message contents and will need a private key to decrypt your messages. So one could argue message security is safer, at least its more suitable for internet communication. Some good links on WCF security:
Message Security in WCF and patterns & practices Improving Web Services Security Guide

netTcpBinding uses Transport security by default, but that doesn't mean you can't use Message security with it. Transport security has less computation overhead than Message security (where each message is encrypted) thus it has better performance. One caveat of using netTcpBinding over the internet is that it may not be guaranteed to work at all times (in the past I have successfully set up netTcpBinding over the internet though) since it uses some ports for message transmission that are not always guaranteed to be left open by network routers and firewalls (over the internet, your messages will be going through many routers and firewalls.) For internet communication, consider one of the HTTP bindings such as basicHttpBinding or wsHttpBinding which also supports message security.

You can use Message security like in other bindings:

<netTcpBinding>
<binding name="securedBinding">
<security mode="Message">
</security>
</binding>
</netTcpBinding>

and then set the bindingConfiguration on your endpoints to securedBinding.

And on the machine hosting your service (the server):

<behavoirs>
<serviceBehavior>
<behavior name="securityBehaviour">
<serviceCredentials>
<serviceCertificate
findValue="serviceCert"
storeLocation="LocalMachine"
storeName="My"
x509FindType="FindBySubjectName" />
</serviceCredentials>
</behavoir>
</serviceBehavior>
</behavoirs>
<services>
<service name="Service1" behaviorConfiguration="securityBehaviour">
<endpoint address="" binding="netTcpBinding" contract="IService1" bindingConfiguration="securedBinding">
</endpoint>
</service>
</services>

If you have limited clients and you know who they are, you can use self signed certificates. However if you want optimal security with many unknown clients consuming your service you're best off buying one from a known CA. You then need to install the server certificates on the server machine. Here is an article on how to secure your services with certificates, the blog also has some other useful WCF security articles that you may want to read.

Transport-level vs message-level security

I think I see what he's getting at. Say like this:

Web client ---> Presentation web server ---> web service call to database

In this case you're depending on the middle server encrypting the data again before it gets to the database. If the message was encrypted instead, only the back end would know how to read it, so the middle doesn't matter.

What are the differences between security mode=Transport and security mode=TransportCredentialOnly

Check here:
http://developers.de/blogs/damir_dobric/archive/2006/07/31/890.aspx
and
http://msdn.microsoft.com/en-us/library/ff648505.aspx

Transport seems to require HTTPS to encrypt credentials and throws an exception if there is no SSL. TransportCredentialOnly will send the credentials in plain text and unencrypted and is recommended for testing ONLY!

Good Luck!!

WCF Security Message vs Transport speed

This is going to depend on your scenario, but here are some performance comparisons with benchmarks.



Related Topics



Leave a reply



Submit