Security in WCF

The first step to securing a WCF service is defining the security policy. Once you have established requirements for authentication, authorization, and message protection it is a matter of service configuration to enforce it.

Your binding selection will influence the available configuration options for the service security policy. When you expose a service endpoint you select a binding that represents the appropriate communication protocol and message encoding format. For example, for intranet communications or systems behind the firewall, TCP protocol with binary message encoding is usually preferred. For Internet access, HTTP protocol is a typical choice using text or MTOM encoding (depending on the message size).

A standard set of bindings satisfy these protocol and encoding choices. NetTcpBinding is the right choice for binary TCP communications that cross machine boundaries,BasicHttpBinding is the right choice for HTTP communications that must support legacy Web service protocols, and WSHttpBinding or WSFederationHttpBinding are the right choice for Web services that can leverage a richer set of standards including those for secure communications (the latter is used for federated security scenarios).

Beyond bindings, behaviors also provide information about client and service credentials, and affect how authorization is handled.

You can configure bindings and behaviors declaratively or through the runtime object model—but in the following sections I'll focus on how you declaratively configure core security settings.

Default Security Settings
Each binding has a default set of security settings. Consider the following service endpoint that supports NetTcpBinding.

NetTcpBinding is secure by default. Specifically, callers must provide Windows credentials for authentication and all message packets are signed and encrypted over TCP protocol. Look at the expanded binding configuration illustrating these default settings.

When the security mode is set to message security, you can customize the default security settings for NetTcpBinding by configuring different values forclientCredentialType or algorithm suite. Other bindings such as WSHttpBinding also allow you to determine if a secure session will be established and control how service credentials are negotiated. Each of the standard WCF bindings supports only relevant security options for their typical usage. In the next sections, I'll review some of the security-specific binding options available, and how you configure them.

Security Mode
Across all service bindings there are five possible security modes:

• None. Turns security off.
• Transport. Uses transport security for mutual authentication and message protection.
• Message. Uses message security for mutual authentication and message protection.
• Both. Allows you to supply settings for transport and message-level security (only MSMQ supports this).
• TransportWithMessageCredential. Credentials are passed with the message and message protection and server authentication are provided by the transport layer.
• TransportCredentialOnly. Client credentials are passed with the transport layer and no message protection is applied.

You can turn off security completely, or allocate authentication and message protection between transport and message-level security. Each transport protocol (TCP, IPC, MSMQ, or HTTP) has its own mechanism for passing credentials and handling message protection. Message security supports passing credentials as part of the SOAP message using interoperable standards, and also makes it possible to protect the message independent of transport all the way through to the ultimate message receiver. Transport message protection is only good from point to point.

To control the security mode used for a particular binding, set the mode property for the binding's section. For Transport or modes that use transport security, the section should be expanded. You can see this illustrated in the section shown earlier. For Message mode, settings are supplied in the expanded section. For example, this snippet illustrates how to require UserName credentials be passed with the message.

Client Credential Type
The choice of client credential type depends on the security mode in place. For transport security you can require a Windows credential or certificate—and there are variations on how Windows credentials are passed via TCP, HTTP and MSMQ. Message security supports any of the following settings for clientCredentialType:

• None
• Windows
• UserName
• Certificate
• IssuedToken

BasicHttpBinding only supports UserName and Certificate credentials since it is intended to be interoperable with Basic Security Profile per WS-I.

Protection Level
By default, all secure WCF bindings will encrypt and sign messages. You cannot disable this for transport security, however, for message security you may wish to disable this for debugging purposes, or when an alternate method of protection is used such as IPSec.

Protection-level settings are controlled by the contract. You can specify protection level for all operations in the service contract using the ServiceContractAttribute. The following example illustrates disabling encryption.

   [ServiceContract(Name="HelloIndigoContract",        Namespace= "http://www.thatindigogirl.com/2006/06/Samples",        ProtectionLevel=ProtectionLevel.Sign)]    public interface IHelloIndigoService    {       string HelloIndigo(string inputString);    } 

For more granular control, you can also indicate message protection per operation using the OperationContractAttribute.

   [ServiceContract(Name="HelloIndigoContract",        Namespace=http://www.thatindigogirl.com/2006/06/Samples]       public interface IHelloIndigoService    {       [OperationContract(ProtectionLevel= ProtectionLevel.Sign)]       string HelloIndigo(string inputString);    } 

You can also control protection level on message contracts providing granular control over specific headers or body elements.

ProtectionLevel options are: None, Sign, and EncryptAndSign. None disables message protection. EncryptAndSign provides full message protection and is the default behavior. Sign indicates the message should be signed but not encrypted.

The ProtectionLevel property serves a dual role. First, it specifies the minimum requirements for message protection. If the property is not specified, the default behavior is to encrypt and sign, but not enforce those settings on the binding. By specifying a value for the property using one of the attributes I mentioned, messages that don't meet the requirement will be rejected for not satisfying the security policy. The second role is to control how message-level protection is applied (since it has no direct affect on transport protection).