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角色来管理证书颁发机构。
设置自己的证书服务，但不对证书进行签名。