Transport Security Overview
Transport security mechanisms in Windows Communication Foundation (WCF) depend on the binding and transport being used. For example, when using the WSHttpBinding class, the transport is HTTP, and the primary mechanism for securing the transport is Secure Sockets Layer (SSL) over HTTP, commonly called HTTPS. This topic discusses the major transport security mechanisms used in the WCF system-provided bindings.
When SSL security is used with .NET Framework 3.5 and later an WCF client uses both the intermediate certificates in its certificate store and the intermediate certificates received during SSL negotiation to perform certificate chain validation on the service's certificate. .NET Framework 3.0 only uses the intermediate certificates installed in the local certificate store.
When transport security is used, the P:System.Treading.Thread.CurrentPrincipal property may be overwritten. To prevent this from happening set the P:System.ServiceModel.Description.ServiceAuthorizationBehavior.PrincipalPermission to None. ServiceAuthorizationBehavior is a service behavior that can be set on the service description.
By default, the BasicHttpBinding class does not provide security. This binding is designed for interoperability with Web service providers that do not implement security. However, you can switch on security by setting the Mode property to any value except None. To enable transport security, set the property to Transport.
The BasicHttpBinding class is primarily used to interoperate with existing Web services, and many of those services are hosted by Internet Information Services (IIS). Consequently, the transport security for this binding is designed for seamless interoperation with IIS sites. This is done by setting the security mode to Transport and then setting the client credential type. The credential type values correspond to IIS directory security mechanisms. The following code shows the mode being set and the credential type set to Windows. You can use this configuration when both client and server are on the same Windows domain.
BasicHttpBinding b = new BasicHttpBinding(); b.Security.Mode = BasicHttpSecurityMode.Transport ; b.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
Or, in configuration:
<bindings> <basicHttpBinding> <binding name="SecurityByTransport"> <security mode="Transport"> <transport clientCredentialType="Windows" /> </security> </binding> </basicHttpBinding> </bindings>
The following sections discuss other client credential types.
This corresponds to the Basic authentication method in IIS. When using this mode, the IIS server must be configured with Windows user accounts and appropriate NTFS file system permissions. For more information about IIS 6.0, see Enabling Basic Authentication and Configuring the Realm Name. For more information about IIS 7.0, see IIS 7.0 Beta: Configure Basic Authentication.
IIS has an option to require clients to log on with a certificate. The feature also enables IIS to map a client certificate to a Windows account. For more information about IIS 6.0, see Enabling Client Certificates in IIS 6.0. For more information about IIS 7.0, see IIS 7.0 Beta: Configuring Server Certificates in IIS 7.0.
Digest authentication is similar to Basic authentication, but offers the advantage of sending the credentials as a hash, instead of in clear text. For more information about IIS 6.0, see Digest Authentication in IIS 6.0. For more information about IIS 7.0, see IIS 7.0 Beta: Configure Digest Authentication.
This corresponds to integrated Windows authentication in IIS. When set to this value, the server is also expected to exist on a Windows domain that uses the Kerberos protocol as its domain controller. If the server is not on a Kerberos-backed domain, or if the Kerberos system fails, you can use the NT LAN Manager (NTLM) value described in the next section. For more information about IIS 6.0, see Integrated Windows Authentication in IIS 6.0. For more information about IIS 7.0, see IIS 7.0 Beta: Configuring Server Certificates in IIS 7.0.
This enables the server to use NTLM for authentication if the Kerberos protocol fails. For more information about configuring IIS in IIS 6.0, see Forcing NTLM Authentication. For IIS 7.0, the Windows authentication includes NTLM authentication. For more information, see IIS 7.0 Beta: Configuring Server Certificates in IIS 7.0.
The WSHttpBinding class is designed for interoperation with services that implement WS-* specifications. The transport security for this binding is Secure Sockets Layer (SSL) over HTTP, or HTTPS. To create an WCF application that uses SSL, use IIS to host the application. Alternatively, if you are creating a self-hosted application, use the HttpCfg.exe tool to bind an X.509 certificate to a specific port on a computer. The port number is specified as part of the WCF application as an endpoint address. When using transport mode, the endpoint address must include the HTTPS protocol or an exception will be thrown at run time. For more information, see HTTP Transport Security.
For client authentication, set the ClientCredentialType property of the HttpTransportSecurity class to one of the HttpClientCredentialType enumeration values. The enumeration values are identical to the client credential types for BasicHttpBinding and are designed to be hosted with IIS services.
The following example shows the binding being used with a client credential type of Windows.
This binding provides only message-level security, not transport-level security.
The NetTcpBinding class uses TCP for message transport. Security for the transport mode is provided by implementing Transport Layer Security (TLS) over TCP. The TLS implementation is provided by the operating system.
You can also specify the client's credential type by setting the ClientCredentialType property of the TcpTransportSecurity class to one of the TcpClientCredentialType values, as shown in the following code.
If you are using Windows security, a certificate is not required.
The following code uses the thumbprint of the certificate, which uniquely identifies it. For more information about certificates, see Working with Certificates.
NetTcpBinding b = new NetTcpBinding(); b.Security.Mode = SecurityMode.Transport; b.Security.Transport.ClientCredentialType = TcpClientCredentialType.Certificate; EndpointAddress a = new EndpointAddress("net.tcp://contoso.com/TcpAddress"); ChannelFactory<ICalculator> cf = new ChannelFactory<ICalculator>(b, a); cf.Credentials.ClientCertificate.SetCertificate( StoreLocation.LocalMachine, StoreName.My, X509FindType.FindByThumbprint, "0000000000000000000000000000000000000000");
Alternatively, specify the certificate in the client's configuration using a <clientCredentials> element in the behaviors section.
The NetNamedPipeBinding class is designed for efficient intra-machine communication; that is, for processes running on the same computer, although named pipe channels can be created between two computers on the same network. This binding provides only transport-level security. When creating applications using this binding, the endpoint addresses must include "net.pipe" as the protocol of the endpoint address.
The NetPeerTcpBinding class is a secure transport that is designed for efficient communication using the peer-to-peer networking feature. As indicated by the name of the class and binding, TCP is the protocol. When the security mode is set to Transport, the binding implements TLS over TCP. For more information about the peer-to-peer feature, see Peer-to-Peer Networking.
For a complete discussion of transport security with Message Queuing (previously called MSMQ), see Securing Messages Using Transport Security.