WCF binding

 

How to choose the right WCF binding
Consider the following scenarios:
• If you need to support clients over the Internet, consider

using wsHttpBinding.
• If you need to expose your WCF service to legacy clients such

as an ASMX Web service,
use basicHttpBinding.
• If you need to support WCF clients within an intranet, consider

using netTcpBinding.
• If you need to support WCF clients on the same machine,

consider using
netNamedPipeBinding.
• If you need to support disconnected queued calls, use

netMsmqBinding.
• If you need to support bidirectional communication between the

WCF client and WCF
service, use wsDualHttpBinding or netTcpBinding.

How to handle exceptions in WCF
Use fault contracts to handle exceptions in WCF. By using the

FaultContract attribute in a
service contract, you can specify the possible faults that can

occur in your WCF service. This
prevents you from exposing any other exception details to the

clients.
• Apply the FaultContract attribute directly on a contract

operation, specifying the
exception type that can be thrown as shown in the following

example:
[OperationContract]
[FaultContract(typeof(DivideByZeroException))]

Use transport security for the following scenarios:
• You are sending a message directly from your application to a

WCF service and the message
will not be routed through intermediate systems.
• You have both the service and the client in an intranet.
Using transport security has the following advantages:
• It provides interoperability, meaning that communicating

parties do not need to understand
the WS-Security specification.
• It may result in better performance.
• Hardware accelerators can be used to further improve

performance.
Using transport security has the following disadvantages:
• Because security is applied on a point-to-point basis, there is

no provision for multiple hops
or routing through intermediate application nodes.
• It supports a limited set of credentials and claims compared to

message security.
• It is transport-dependent upon the underlying platform,

transport mechanism, and security
service provider such as NTLM or Kerberos.

Use message security for the following scenarios:
• You are sending a message to a WCF service, and the message is

likely to be forwarded to
other WCF services or may be routed through intermediate systems.
• Your WCF clients are accessing the WCF service over the

Internet, it’s possible that other
intermediate systems may be used in between, and security is your

top consideration.
Using message security has following advantages:
• It provides end-to-end security. Because message security

directly encrypts and signs the
message, having intermediaries does not break the security.
• It allows partial or selective message encryption and signing,

thus improving overall
application performance.
• Message security is transport-independent and can be used with

any transport protocol.
• It supports a wide set of credentials and claims, including

issue token, which enables
federated security.
Using message security has following disadvantages:
• This option may reduce performance compared to transport

security because each
individual message is encrypted and signed.
• It does not support interoperability with older ASP.NET Web

Services (ASMX) clients
because it requires both the client and service to support WS-

Security specifications.

Note: In an intranet scenario, it is recommended that you use

netTcpBinding unless you have a
specific requirement to use other bindings such as wsHttpBinding.

By default, netTcpBinding
uses binary encoding and transport security, which delivers

better performance.

Bindings Summary
Use the following binding summaries to help you choose the right

binding for your scenario.
basicHttpBinding
If your service needs to support legacy clients that expect an

ASMX Web service, consider using
basicHttpBinding. Because basicHttpBinding does not implement any

security by default, if you
require message or transport security, you should configure it

explicitly on this binding. Use
basicHttpBinding to expose endpoints that are able to communicate

with ASMX-based Web
services and clients and other services that conform to the WS-I

Basic Profile 1.1 specification.
When configuring transport security, basicHttpBinding defaults to

no credentials just like a
classic ASMX Web service. basicHttpBinding allows you to host

your service in Internet
Information Services (IIS) 5.0 or IIS 6.0.
wsHttpBinding
If your service will be called by WCF clients over the Internet,

consider using wsHttpBinding.
wsHttpBinding is a good choice for Internet scenarios in which

you do not have to support
legacy clients that expect an ASMX Web service. If you do need to

support legacy clients,
consider using basicHttpBinding instead. wsHttpBinding allows you

to host your service in IIS
5.0 or IIS 6.0.
netTcpBinding
If you need to support clients within your intranet, consider

using netTcpBinding.
netTcpBinding is a good choice for an intranet scenario if

transport performance is important
to you and it is acceptable to host the service in a Windows

service instead of in IIS.
netTcpBinding uses the TCP protocol and provides full support for

SOAP security, transactions,
and reliability. Use this binding when you want to provide a

secure and reliable binding
environment for .NET-to-.NET cross-machine communication.

netTcpBinding does not allow
you to host your service in IIS 5.0 or IIS 6.0; instead, host in

a Windows service or in IIS 7.0.

Message Validation
• If You Need to Validate Parameters, Use Parameter Inspectors
• Use Schemas with Message Inspectors to Validate Messages
• Use Regular Expressions in Schemas to Validate Format, Range,

or Length
• Implement the AfterReceiveRequest Method to Validate Inbound

Messages on the Service
• Implement the BeforeSendReply Method to Validate Outbound

Messages on the Service
• Implement the AfterReceiveReply Method to Validate Inbound

Messages on the Client
• Implement the BeforeSendRequest Method to Validate Outbound

Messages on the Client
• Validate Operation Parameters for Length, Range, Format, and

Type
• Do Not Rely on Client-side Validation
• Avoid User-supplied File Name and Path Input
• Do Not Echo Untrusted Input

Transport Security
• Use Transport Security When Possible
• If You Need to Support Clients in an Intranet, Use Transport

Security
• If You Need to Support Interoperability with Non-WCF Clients,

Use Transport Security
• Use a Hardware Accelerator When Using Transport Security

Proxy Considerations
• Publish Your WCF Service Metadata Only When Required
• If You Need to Publish Your WCF Service Metadata, Publish It

over the HTTPS Protocol
• If You Need to Publish Your WCF Service Metadata, Publish It

Using Secure Binding
• If You Turn Off Mutual Authentication, Be Aware of Service

Spoofing

Sensitive Data
• Avoid Plain-Text Passwords or Other Sensitive Data in

Configuration Files
• Use Platform Features to Manage Keys Where Possible
• Protect Sensitive Data Over the Network
• Do Not Cache Sensitive Data
• Minimize Exposure of Secrets in Memory
• Be Aware That basicHttpBinding Will Not Protect Sensitive Data

by Default
• Use Appropriately Sized Keys

Deployment Considerations
• Do Not Use Temporary Certificates in Production
• If You Are Using Kerberos Authentication or Delegation, Create

an SPN
• Use IIS to Host Your WCF Service Wherever Possible
• Use a Least-Privileged Account to Run Your WCF Service

1. Define the type to pass the details of SOAP faults as

exceptions from a service back to a
client.
[DataContract]
public class DatabaseFault
{
[DataMember]
public string DbOperation;
[DataMember]
public string DbReason
[DataMember]
public string DbMessage;
}
2. Use the FaultContract attribute in the ListCustomers method to

generate SOAP faults.
[ServiceContract]
public interface ICustomerService
{
// Get the list of customers
[FaultContract(typeof(DatabaseFault))]
[OperationContract]
List<string> ListCustomers();
…
}
3. Create and populate the DatabaseFault object with the details

of the exception in the
Service implementation class and then throw a FaultException

object with the
DatabaseFault object details.
catch(Exception e)
{ DatabaseFault df = new DatabaseFault();
df.DbOperation = "ExecuteReader";
df.DbReason = "Exception in querying the Northwind database.";
df.DbMessage = e.Message;
throw new FaultException<DatabaseFault>(df);
}

If your service is hosted in IIS 6.0, use IIS Manager to create

an application pool running
as an account identity. Use IIS Manager to assign your WCF

service to that application
pool.

尽管 WCF 模型旨在跨宿主环境和传输保持行为的一致性，但经常在一些方

案中，应用程序中不要求这种程度的灵活性。 WCF 的 ASP.NET 兼容模式

适用于具有以下特点的方案：不需要具有在 IIS 外部承载或通过 HTTP 之

外的协议进行通信的能力，但使用 ASP.NET Web 应用程序平台的所有功能

。

在默认的并行配置中，承载基础结构的 WCF 截获 WCF 消息并将其路由到

HTTP 管道之外；与此不同的是，在 ASP.NET 兼容模式中运行的 WCF 服务

完全参与 ASP.NET HTTP 请求生命周期。 在兼容模式中，WCF 服务通过

IHttpHandler 实现来使用 HTTP 管道，其方式类似于处理 ASPX 页和

ASMX Web 服务的请求。 因此，WCF 的行为在以下 ASP.NET 功能方面与

ASMX 相同：

•在 ASP.NET 兼容模式中运行的 HttpContext: WCF 服务可以访问

Current 以及与其关联的状态。

•基于文件的授权：在 ASP.NET 兼容模式中运行的 WCF 服务可以通过将文

件系统访问控制列表 (ACL) 附加到服务的 .svc 文件来获得保护。

•可配置的 URL 授权：当 WCF 服务在 ASP.NET 兼容模式中运行时，将对

WCF 请求强制执行 ASP.NET 的 URL 授权规则。

•HttpModuleCollection 扩展性：由于在 ASP.NET 兼容模式中运行的 WCF

服务完全参与 ASP.NET HTTP 请求生命周期，因此在 HTTP 管道中配置的

任何 HTTP 模块能够在服务调用前后的 WCF 请求上进行操作。

•ASP.NET 模拟：WCF 服务使用 ASP.NET 模拟线程的当前标识来运行，如

果已为应用程序启用 ASP.NET 模拟，则该标识可能与 IIS 进程标识不同

。 如果为某个特定服务操作同时启用 ASP.NET 模拟和 WCF 模拟，则服务

模拟最终使用从 WCF 获得的标识来运行。

承载于 IIS 中的 WCF 服务将其配置存储在应用程序 Web.config 文件中

。 承载于 IIS 中的服务使用与承载于 IIS 外部的 WCF 服务相同的配置

元素和语法。 但是，下面的约束对 IIS 承载环境是唯一的：

•承载于 IIS 中的服务的基址。

•通过将一组基址 URI 传递到 ServiceHost 构造函数或者通过在服务配置

中提供 <host> 元素，在 IIS 外部承载 WCF 服务的应用程序可以控制这

些服务的基址。 承载于 IIS 中的服务无法控制其基址；承载于 IIS 中的

服务的基址是其 .svc 文件的地址。

承载于 IIS 中时，任何终结点地址始终被认为相对于表示服务的 .svc 文

件的地址。 例如，如果 WCF 服务的基址是包含以下终结点配置的

http://localhost/Application1/MyService.svc。

复制
 <endpoint address="anotherEndpoint" .../>
这提供了一个可以在

“http://localhost/Application1/MyService.svc/anotherEndpoint”上

访问的终结点。

HTTP 传输安全
承载于 IIS 中的 WCF 服务可以使用 HTTP 传输安全（例如 HTTPS 和

HTTP 身份验证方案，如基本、摘要式和 Windows 集成身份验证），前提

是包含该服务的 IIS 虚拟目录支持这些设置。 所承载终结点的绑定上的

HTTP 传输安全设置必须与包含它的 IIS 虚拟目录上的传输安全设置匹配

。

例如，配置为使用 HTTP 摘要式身份验证的 WCF 终结点必须驻留在也配置

为允许 HTTP 摘要式身份验证的 IIS 虚拟目录中。 IIS 设置和 WCF 终结

点设置的不匹配组合会导致服务激活期间出错。

Perform the following steps to authenticate users by using a

client-side certificate:
1. Install the service certificate on the WCF service machine:
• If you are using message security, configure service

credentials to set the name
and location of the service certificate.
• If you are using transport security with wsHttpBinding, install

the service
certificate on Internet Information Services (IIS) and configure

the virtual
directory to require Secure Sockets Layer (SSL) and client

certificates.
2. Configure the service to use certificates for the client

credentials type, as shown in the
following example:
<wsHttpBinding>
<binding name="WSHttpBinding_ICalculator">
<security mode="Message">
<message clientCredentialType="Certificate" />
</security>
</binding>
</wsHttpBinding>
3. Install the service certificate on the client machine.
4. Configure the endpoint behavior to set the name and location

of the client certificate.
Note: Make sure that the root CA certificate is in the Trusted

Root Certification Authorities
location on both the server and client machines.

•如果 WCF 服务承载于某个 Windows 服务中，则使用“本地计算机”存储

区。 请注意，要将证书安装到本地计算机存储区，需要有管理员权限。

•如果服务或客户端是在某个用户帐户下运行的应用程序，则使用“当前用

户”存储区。

与计算机上的文件夹一样，存储区也受访问控制列表 (ACL) 保护。 在创

建由 Internet 信息服务 (IIS) 承载的服务时，ASP.NET 进程运行在

ASP.NET 帐户下。 该帐户必须有权访问包含服务所用证书的存储区。 每

个主要存储区都由一个默认访问列表保护，但这些列表是可以修改的。 如

果创建一个单独的角色访问存储区，则必须向该角色授予访问权限。

获取 X.509 证书
•选择执行下列操作之一：

从证书颁发机构（如 VeriSign Inc）购买证书。

设置自己的证书服务，并让证书颁发机构为证书签名。 Windows Server

2003、Windows 2000 Server、Windows 2000 Server Datacenter 和

Windows 2000 Datacenter Server 都提供支持公钥基础结构 (PKI) 的证

书服务。 在 Windows Server 2008 中，请使用Active Directory

Certificate Services角色来管理证书颁发机构。

设置自己的证书服务，但不对证书进行签名。