Section 10.3. Transfer Security
10.3. Transfer SecurityBoth authentication and authorization deal with two local aspects of securityhow (and to what extent) to grant access to the caller once the message was received by the service. In this respect WCF services are not much different from traditional client-server classes. But both authentication and authorization are predicated on secure delivery of the message itself. The transfer of the message from the client to the service has to be secure, and without it, both authentication and authorization are moot. Transfer security has three essential aspects to it, and all three aspects must be enforced to provide for secure services. Message integrity deals with how to ensure the message itself was not tampered with en route from the client to the service. A malicious party or intermediary could in practice intercept the message and modify its content; for example, providing wrong account numbers in case of a transfer operation in a banking service. Message privacy deals with ensuring the confidentiality of message, so that no third party can even read the content of the message. Privacy complements integrity. Without it, even if the malicious party does not tamper with the message, it can still cause harm by gleaning sensitive information such as account numbers from the message. Finally, transfer security must provide for mutual authentication; that is, ensuring the client that only the proper service is able to read the context of the messagein other words, that the client connects to the correct service. Once the credentials in the message are received, the service must authenticate the credentials locally. Mutual authentication also needs to detect and eliminate replay attacks and denial of service attacks (DOS). In both cases a malicious party could replay a valid message to the service or even just bogus invalid messages but in such a frequency as to degrade the service's availability. 10.3.1. Transfer Security ModesWCF supports five different ways of accomplishing the three aspects of transfer security. Choosing the correct transfer security mode is perhaps the prime decision made in the context of securing a service. The five transfer security modes are None, Transport security, Message security, Mixed, and Both. 10.3.1.1. None transfer security modeAs its name implies, the None transfer security mode has transfer security completely turned off. No client credentials are provided to the service, and the message itself is wide open to any malicious party to do with it as it pleases. Obviously, setting transfer security to None is highly unadvisable. 10.3.1.2. Transport securityWhen configured for Transport security, WCF uses a secure transport. The available secure transports are HTTPS, TCP, IPC, and MSMQ. Transport security encrypts all communication on the channel, and thus provides for integrity, privacy, and mutual authentication. Integrity is provided because without knowing the encryption key, any attempt to modify the message will corrupt it so that it will become useless. Privacy is provided because no party other than the recipient can see the content of the message. Mutual authentication is partly supported because the client's credentials are encrypted along with the rest of the message, and only the intended recipient of the message can read it, so the client need not be concerned with message rerouting to malicious endpoints, as those will not be able to use the message. Once the message is decrypted, the service can read the credentials and authenticate the client. Transfer security requires the client and the service to negotiate the details of the encryption, but that is done automatically as part of the communication protocol in the respective binding. Transfer security can benefit from hardware acceleration done on the network card so as to avoid burdening the host machine CPU with the encryption and decryption of the messages. Hardware acceleration obviously caters to high throughput and it may even make the security overhead unnoticeable. Transport security is the simplest way of achieving message security and the most performant one. Its main downside it that it can only guarantee transfer security point-to-point, meaning when the client connects directly to the service. Having multiple intermediaries between the client and the service renders transport security questionable, as those intermediaries may not be secure. Consequently, transport security is often used by intranet applications only, where you can ensure a single hop between the client and the service in a controlled environment.
10.3.1.3. Message securityThe Message transfer security mode simply encrypts the message itself. By encrypting the message, you gain integrity, privacy, and enable mutual authentication for the same reason that transport security provides them when the communication channel is encrypted. However, encrypting the message rather than the transport enables the service to communicate securely over nonsecure transports, such as HTTP. Because of that, message security provides for end-to-end security, regardless of the number of intermediaries involved in transferring the message and regardless of whether or not the transport is secure. In addition, message security is based on a set of industry standards designed for both interoperability and thwarting of common attacks such as replays and DOS, and the support WCF offers is both rich and extensible. The downside of message security is that it may introduce call latency due to its inherit overhead. Message security is typically used by Internet applications, where the call patterns are less chatty and the transport is not necessarily secure. 10.3.1.4. Mixed transfer securityThe Mixed transfer security mode uses Transport security for message integrity and privacy as well as service authentication, and it uses Message security for securing the client credentials. The Mixed mode tries to combine the advantages of both Transport and Message security by benefiting from secure transport and even hardware acceleration offered by Transport security to cater to high throughput, and from the extensibility and richer type of client credential types offered by the Message security. The downside of the Mixed mode is that it is only secure point-to-point as a result of the use of Transport security. Application developers rarely need to use the Mixed mode, but it is available for advanced cases. 10.3.1.5. Both transfer securityAs its name implies, the Both transfer security mode uses both Transport security and Message security. The message itself is secured using Message security, and then it is transferred to the service over a secure transport. The Both mode maximizes security, yet it may be overkill for most applications, with the exception perhaps of disconnected applications where its additional latency will go unnoticed. 10.3.2. Transfer Security Mode ConfigurationConfiguring the transfer security mode is done in the binding, and both the client and the service must use the same transfer security mode, and of course comply with its requirements. Like any other binding configuration, you can configure transfer security either programmatically or administratively in a config file. All bindings (with the exception of the peer network binding) offer a construction parameter indicting the transfer security mode, and all bindings offer a Security property with a Mode property identifying the configured mode using a dedicated enumeration. As shown in Table 10-1, not all bindings support all transfer security modes, and the supported modes are driven by the target scenario for the binding.
The intranet bindings (NetTcpBinding, NetNamedPipeBinding, and NetMsmqBinding) all default to Transport security. The reason for that is that the intranet is a relatively secure environment compared with the Internet, and Transport security yields the better performance. Note that the three transport protocols (TCP, IPC, and MSMQ) are also inherently secure transports, and no special programming is required on behalf of the service or client developer. However, the intranet bindings can also be configured for the None transfer mode; that is, they can be used on the same transports, only without security. Note that the NetNamedPipeBinding only supports None and Transport securitythere is no sense in using Message security over IPC, since with IPC you have exactly one hop from the client to the service. Also note that only the NetMsmqBinding supports the Both mode. The Internet bindings all default to Message security, to enable them to be used over nonsecure transports; that is, HTTP. Note that while the WSHttpBinding can be configured for Transport security, the WSDualHttpBinding cannot. The reason is that this binding uses a separate HTTP channel to connect the service to the callback client, and that channel to the client-hosted callback object cannot be easily made to use HTTPS, unlike a service that is likely to be hosted in a real web server. With one noticeable exception, all of the WCF bindings are configured with some kind of transfer security and are therefore secure by default. Only BasicHttpBinding defaults to having no security. The reason is that the basic binding is designed to make a WCF service look like a legacy ASMX service, and ASMX is unsecured by default. That said, you can and should configure the BasicHttpBinding to use transfer security such as Message security. 10.3.2.1. Specific bindings configurationThe BasicHttpBinding uses the BasicHttpSecurityMode enum for transfer mode configuration. The enum is available via the Mode property of the Security property of the binding: public enum BasicHttpSecurityMode { None, Transport, Message, TransportWithMessageCredential, TransportCredentialOnly } public sealed class BasicHttpSecurity { public BasicHttpSecurityMode Mode {get;set;} //More members } public class BasicHttpBinding : Binding,... { public BasicHttpBinding( ); public BasicHttpBinding(BasicHttpSecurityMode securityMode); public BasicHttpSecurity Security {get;} //More members } Security is of the type BasicHttpSecurity. One of the constructors of BasicHttpBinding takes the BasicHttpSecurityMode enum as a parameter. To secure the basic binding for Message security, you can either construct it secured or set the security mode post-construction. Consequently, in Example 10-1 binding1 and binding2 are equivalent. Example 10-1. Programmatically securing the basic binding
Instead of programmatic settings, you can use a config file as in Example 10-2. Example 10-2. Administratively securing the basic binding
The rest of the bindings all use their own enumerations and dedicated security classes, yet they are configured just as in Examples 10-1 or 10-2. For example, the NetTcpBinding, NetPeerTcpBinding, and WSHttpBinding all use the SecurityMode enum, defined as: public enum SecurityMode { None, Transport, Message, TransportWithMessageCredential//Mixed } Not all of these bindings offer a matching constructor parameter, but they all offer a Security property. The NetNamedPipeBinding uses the NetNamedPipeSecurityMode enum that supports only None and Transport: public enum NetNamedPipeSecurityMode { None, Transport } The WSDualHttpBinding uses the enum WSDualHttpSecurityMode that supports only None and Message: public enum WSDualHttpSecurityMode { None, Message } The NetMsmqBinding uses the NetMsmqSecurityMode enum: public enum NetMsmqSecurityMode { None, Transport, Message, Both } NetMsmqSecurityMode is the only enum that offers the Both transfer mode. The reason that almost every binding has its dedicated enum for security mode is that the designers of WCF security opted for increased safety at the expense of overall complexity. They could have defined just a single all-inclusive enum with values corresponding to all possible transfer security modes, but then it would have been possible at compile time to assign invalid values such as Message security for the NetNamedPipeBinding or Transport for the WSDualHttpBinding. By opting for specialized enums, configuring security becomes less error-prone, yet there are more moving parts to come to terms with. 10.3.3. Transport Security and CredentialsWCF lets you select from a number of possible client credentials types. The client can identify itself using a classic username and password, or the client can use a Windows security token. Windows credentials can then be authenticated using NTLM or Kerberos when available. The client can use an X509 certificate, or the client can choose to provide no credentials at all and be anonymous. When configuring transfer security as Transport security, not all bindings support all client credential types, as shown in Table 10-2.
Which binding supports which credentials type is largely a product of the target scenario the binding is designed for. For example, all of the intranet bindings default to Windows credentials since they are used in a Windows environment, and the BasicHttpBinding defaults to no credentials, just as with a classic ASMX web service. The WSFederationHttpBinding and WSDualHttpBinding cannot use Transport security at all. 10.3.4. Message Security and CredentialsWhen it comes to using Message transfer security, WCF lets applications use the same type of credentials as with Transport security, with the addition of the issued token credential type. When configured for Message security, not all bindings support all client credentials types, as shown in Table 10-3.
While it makes sense that all intranet bindings that support Message security will default to Windows credentials, it is interesting to note that the Internet bindings (WSHttpBinding and WSDualHttpBinding) also default to Windows credentials, even though (as discussed later on), Internet applications rarely use Windows credentials over HTTP. The reason for this is to enable developers to securely use these bindings out of the box, without resorting first to custom credentials stores.
|
