Design Considerations

The key issue to consider at design time is what binding you will choose for your particular scenario. Choosing an appropriate binding is important from a security perspective because it drives your security choices—for example, transfer security—which in turn determine the confidentiality, integrity, and authentication of your messages. Additionally, you need to consider your authentication and authorization options and decide which option makes sense for your scenario.

When designing your WCF service, you should:

• Consider exposing different endpoints.
• If you need to support ASMX clients, use basicHttpBinding.
• If you are migrating from DCOM, use netTcpBinding.
• If you need to support legacy WSE clients, use a customBinding in WCF.
• If you require interoperability with non-Microsoft clients, use bindings that are targeted for interoperability.
• If your non-Microsoft clients understand the WS* stack, use ws2007HttpBinding or wsHttpBinding.
• Consider transport security as your preferred security mode.
• Know your authentication options.
• Know your authorization options.
• Know your binding options.
• Choose the right binding for your scenario.

Each of these guidelines is described in the following sections.

Consider exposing different endpoints

Consider exposing multiple endpoints to support different authentication schemes or protocols, or to support ASP.NET Web Services (ASMX) clients. This approach gives you flexibility as you will only have to develop the service once, while still providing clients with the endpoint that matches their security requirements.

If you need to support ASMX clients, use basicHttpBinding

If you have an ASMX client base, consider using basicHttpBinding in your service because it can be consumed by both WCF and legacy clients. basicHttpbinding is a flexible way to provide support for existing legacy clients, as it does not require that they be upgraded to WCF. Additionally, basicHttpbinding provides a wide range of authentication schemes. Transport security supports Basic, Digest, Windows, and certificate authentication; message security supports username and certificate authentication. To use basicHttpBinding, create an endpoint with binding configuration set to use basicHttpBinding. Security mode is turned off by default. To enable security and authentication, you will need to create a binding configuration and then configure the endpoint to use the binding.

If you are migrating from DCOM, consider using netTcpBinding

If you are migrating from DCOM, consider using netTcpBinding. Because netTcpBinding uses binary encoding and the TCP protocol, it provides the best performance for .NET-to-.NET cross-machine communication. Consider the following when choosing netTcpBinding:

• It supports transactions and reliable messaging.
• It supports a wide range of authentication schemes.
• If you use transport security mode, you can use Windows and certificate authentication.
• If you use message or mixed-mode security, you can use Windows, issue token, username, and certificate authentication.
• You can host in Internet Information Services (IIS) 7.0 or a Windows service. You can also host in IIS 6.0, but you have to activate the host W3wp process before using the service.

If you need to support legacy WSE clients, use a custom binding in WCF

If you have a Web Services Enhancements (WSE) client base, you need to use a custom binding in your service in order to support WSE legacy clients. This will provide interoperability for existing clients without requiring the clients to migrate to WCF. The following table shows the mapping of the WSE bindings to WCF binding elements.

WSE	WCF
anonymousForCertificateSecurity	anonymousForCertficate
kerberosSecurity or mutualCertificateSecurity11	MutualCertificate
usernameOverTransportSecurity	UserNameOverTransport
usernameForCertificateSecurity	usernameForCertificateSecurity

To create a custom binding to support WSE clients:

1. Add a customBinding to your WCF service.
2. Specify a name for your custom binding.
3. Specify an authentication mode that maps to the authentication used in your previous WSE service.
4. Specify that WCF uses the August 2004 version of the WS-Addressing specification.
5. Configure the WCF endpoint to use the custom binding.

Additional Resources

For detailed information on how to configure customBinding, see How to: Configure WCF Services to Interoperate with WSE 3.0 Clients.

If you require interoperability with non-Microsoft clients, use bindings that are targeted for interoperability

The following bindings are targeted for interoperability:

• basicHttpBinding
• wsHttpBinding
• ws2007HttpBinding
• ws2007FederationHttpBinding
• wsFederationHttpBinding

If your non-Microsoft clients understand the WS* stack, use ws2007HttpBinding or wsHttpBinding

If you need to support non-Microsoft clients that understand the WS* stack, use ws2007HttpBinding or wsHttpBinding.

Consider transport security as your preferred security mode

Consider transport security as your preferred security mode, as it provides confidentiality, integrity, and authenticity and may result in better performance. If you use message security or mixed-mode security, consider profiling and testing your application to assess its performance and scalability characteristics, to confirm that it meets your business requirements.

Know your authentication options

Understand the authentication options that map to your particular deployment scenario.

Internet

• Username authentication with the SQL Server membership provider. If your users are not in Active Directory, consider using the SQL Server membership provider. This will give you a store that can be easily created and deployed. Configure message security or mixed-mode security to protect your users’ credentials.
• Basic authentication with Windows. If your users are already in Active Directory or in local machine accounts, consider using Basic authentication. Use transport security to secure the communication channel and protect your credentials.
• Username authentication with a custom store. If your users are in a custom store, consider using username authentication with a custom validator in order to validate user credentials against your custom store. Unlike the other scenarios, you will have to write custom code to validate your users’ credentials. Use message or mixed-mode security to protect your users’ credentials.
• Certificate authentication with certificates. If your clients are partners or mobile clients connecting over a virtual private network (VPN) in a peer-to-peer authentication scenario, consider using certificate authentication. If your users have Windows accounts in your domain, you can map the certificates to the Windows accounts and enable authorization checks based on Windows roles. Certificate authentication requires that you manage certificates; however, it allows seamless authentication for clients outside your firewall. Use transport security to secure the communication channel and protect your credentials.

Intranet

• Username authentication with the SQL Server membership provider. If your users are not in Active Directory, consider using the SQL Server membership provider. This will give you a store that can be easily created and deployed. Use transport security to secure the communication channel and protect your credentials.
• Windows authentication with Windows. If your users are already in Active Directory or in local machine accounts, consider using Windows authentication to leverage this infrastructure. Windows authentication also gives you the benefits of using Windows roles for authorization checks. Use transport security to secure the communication channel and protect your credentials. Consider that local machine accounts configure authentication with the NTLM protocol, which is prone to brute-force attacks. For more secure peer-to-peer authentication, consider using certificate authentication.
• Username authentication with a custom store. If your users are in a custom store, consider using username authentication with a custom validator in order to validate user credentials against your custom store. Unlike the other scenarios, you will have to write custom code to validate your users’ credentials. Use message or mixed-mode security to protect your users’ credentials.
• Certificate authentication with certificates. If your clients are partners or mobile clients connecting over a VPN in a peer-to-peer authentication scenario, consider using certificate authentication. If your users have Windows accounts in your domain, you can map the certificates to the Windows accounts and enable authorization checks based on Windows roles. Certificate authentication requires that you manage certificates; however, it allows seamless authentication for clients outside your firewall. Use transport security to secure the communication channel and protect your credentials.

Know your authorization options

Know your authorization options and choose the most appropriate option for your particular scenario. First decide if you want to use resource-based or role-based authorization. Resource-based authorization uses access control lists (ACLs) on the resource to authorize the original caller. Role-based allows you to authorize access to service operations or resources based on the group a user is in.

• If you choose to use role-based authorization, you can store your roles in Windows groups or in ASP.NET roles.
• If you are using Active Directory, consider using Windows groups based on ease of maintenance and the fact that you maintain both roles and credentials in the Active Directory store. If you are not using Active Directory, consider using ASP.NET roles and the ASP.NET Role Provider.

Your authorization strategy may also be influenced by your choice of authentication as follows:

• Resource-based authorization

  • If you are using certificate authentication, you will need to map the certificates to Windows groups.
  • If you are using username authentication, you will need to perform protocol transition.
  • Windows authentication will work with resource-based authorization by default.
  • Basic authentication will work with resource-based authorization by default.

  Note

  You need to impersonate for resource-based authorization.

• Role-based authorization

  • If you are using certificate authentication, you will need to map the certificates to Windows groups.
  • If you are using username authentication with Windows groups, you will need to perform protocol transition.
  • Username authentication will work with ASP.NET roles by default.
  • Windows authentication will work with Windows groups by default.
  • Basic authentication will work with Windows groups by default.

Know your binding options

Know your binding options and choose the most appropriate option for your particular scenario. A thorough understanding of your binding options enables you to design more reliable and secure WCF applications.

The following table summarizes common bindings.

Binding	Description
basicHttpBinding	Represents a binding that configures and exposes 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. By default, basicHttpBinding has security disabled.
wsHttpBinding	Defines a secure, reliable, interoperable binding suitable for non-duplex service contracts. The binding implements the following specifications: WS-Reliable Messaging for reliability, and WS-Security for message security and authentication. The transport is HTTP, and message encoding is text/XML encoding. By default, it provides message security using Windows authentication.
ws2007HttpBinding	Defines a secure, reliable, interoperable binding suitable for non-duplex service contracts. The binding implements the following specifications: WS-Reliable Messaging for reliability, and WS-Security for message security and authentication. The transport is HTTP, and message encoding is text/XML encoding. ws2007HttpBinding provides binding similar to wsHttpBinding but uses the standard for OASIS (Organization for the Advancement of Structured Information Standards). By default, ws2007HttpBinding provides message security using Windows authentication.
netTcpBinding	Specifies a secure, reliable, optimized binding suitable for cross-machine communication. By default, it generates a run-time communication stack with transport security and Windows authentication as default security settings. netTcpBinding uses the Transmission Control Protocol (TCP) for message delivery, and binary message encoding.
netNamedPipeBinding	Defines a binding that is secure, reliable, and optimized for cross-process communication on the same machine. By default, netNamedPipeBinding generates a run-time communication stack with WS-ReliableMessaging for reliability, transport security for transfer security, named pipes for message delivery, and binary message encoding. netNamedPipeBinding is not secured by default.
netMsmqBinding	Defines a queued binding suitable for cross-machine communication.
wsFederationHttpBinding	Defines a binding that supports federated security. wsFederationHttpBinding helps in implementing federation, which is the ability to flow and share identities across multiple enterprises or trust domains for authentication and authorization. WCF implements federation over message and mixed-mode security but not over transport security. Services configured with this binding must use the HTTP protocol as transport.
ws2007FederationHttpBinding	Defines a binding that derives from wsFederationHttpBinding and supports federated security. ws2007FederationHttpBinding helps in implementing. WCF implements federation over message and mixed-mode security but not over transport security. Services configured with this binding must use the HTTP protocol as transport. ws2007FederationHttpBinding provides binding similar to ws2007FederationHttpBinding but uses the OASIS standard.
wsDualHttpBinding	Defines a secure, reliable, and interoperable binding that is suitable for duplex service contracts or communication through Simple Object Access Protocol (SOAP) intermediaries.
customBinding	Allows you to create a custom binding with full control over the message stack.

For more information on bindings, see Windows Communication Foundation Bindings.

Choose the right binding for your scenario

Use the following recommendations as a rule of thumb when choosing a binding option. You can fine-tune your selection based on your unique needs and your infrastructure limitations.

• 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 IIS 5.0 or IIS 6.0.
• If your service will be called by 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.
• 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 message 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 allows you to host your service in IIS 7.0 or a Windows service. You can also host in IIS 6.0, but you must activate the host W3wp process before using the service.
• If you need to support WCF clients on the same machine as your service, consider using netNamedPipeBinding. netNamedPipeBinding provides a secure and reliable binding environment for cross-process communication on the same machine. Use this binding when you want to make use of the Named Pipe protocol and provide full support for SOAP security, transactions, and reliability. netNamedPipeBinding allows you to host your service in IIS 7.0 or a Windows service. You can also host in IIS 6.0, but you must activate the host W3wp process before using the service.
• If you need to support disconnected queuing, use netMsmqBinding. Queuing is provided by using Microsoft Message Queuing (MSMQ) as a transport, which enables support for disconnected operations, failure isolation, and load leveling. You can use netMsmqBinding when the client and the service do not have to be online at the same time. You can also manage any number of incoming messages by using load leveling. MSMQ supports failure isolation, meaning that messages can fail without affecting the processing of other messages. netMsmqBinding allows you to host your service in IIS 7.0 or a Windows service. You can also host in IIS 6.0, but you must activate the host W3wp process before using the service.
• If you need to support a duplex service, use wsDualHttpBinding. A duplex service is a service that uses duplex message patterns, which provides the ability for a service to communicate back to the client via a callback. You can also use this binding to support communication via SOAP intermediaries.