Deployment Considerations

  • Article

patterns & practices Developer Center

To avoid introducing vulnerabilities when you deploy your WCF application into a production environment, follow these guidelines:

  • 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.
  • Protect sensitive data in your configuration files.

Do not use temporary certificates in production

Use temporary certificates when you are developing and testing your WCF service. Temporary certificates are less expensive than production certificates and are easier to create. Once you are ready to deploy, replace your temporary certificate with a production certificate provided by a certificate authority (CA).

Temporary certificates can be created by using the makecert utility. If you are deploying a WCF service for a real-world production environment, use a certificate provided by a CA such as Microsoft Windows Server 2003 Certificate Server or a third party.

Additional Resources

If you are using Kerberos authentication or delegation, create an SPN

If you are using Kerberos authentication, create a service principle name (SPN). Without an SPN, the Kerberos authentication will stop working when you switch from a machine account, such as Network Service, to a domain account.

Only SPNs can be configured for delegation in the Active Directory. In a production scenario using delegation, where you want to run the WCF service using a low-privileged custom domain account, you need to create an SPN for that account in order to enable delegation

To create an SPN for a domain account, run the Setspn tool from a command prompt as follows:

setspn -A HTTP/webservername domain\customAccountName 
setspn -A HTTP/webservername.fullyqualifieddomainname domain\customAccountName

This creates an SPN for the custom domain account (domain\customAccountName) and associates the account with the HTTP service on the specified WCF server. By running the command twice as shown above, you can associate the account with the NetBIOS server name and the fully qualified domain name (FQDN) of the server. This ensures that the SPN is established correctly even if your environment does not consistently use FQDNs.

Additional Resources

Use IIS to host your WCF service wherever possible

Use Internet Information Services (IIS) to host your WCF service because it provides a large number of features for efficient service management and scalability. IIS 6.0 only supports bindings over HTTP, so if you need to use TCP, MSMQ, or named pipes, you should host in a Windows service instead. IIS 7.0 supports all of the commonly used transport protocols such as HTTP, TCP, MSMQ, and named pipes. By using IIS as your WCF service host, you can take full advantage of IIS features such as process recycling, idle shutdown, process health monitoring, and message-based activation.

Perform the following steps when you want to develop and deploy a WCF service that is hosted in IIS:

  1. Ensure that IIS, WCF, and the WCF activation component are correctly installed and registered.
  2. Create a new IIS application, or reuse an existing ASP.NET application.
  3. Create a .svc file for the WCF service.
  4. Deploy the service implementation to the IIS application.
  5. Configure the WCF service.

Additional Resources

Use a least-privileged account to run your WCF service

Use a least-privileged account to host your WCF service because it will reduce your application's attack surface and reduce the potential damage if you are attacked. If the service account requires additional access rights on infrastructure resources such as MSMQ, the event log, performance counters, and the file system, appropriate permissions should be given to these resources so that the WCF service can run successfully. If your service needs to access specific resources on behalf of the original caller, use impersonation and delegation to flow the caller's identity for a downstream authorization check.

In a development scenario, use the local network service account, which is a special built-in account that has reduced privileges. In a production scenario, create a least-privileged custom domain service account.

Additional Resources

Protect sensitive data in your configuration files

Protect the sensitive data, such as SQL connection strings, in your configuration files by encrypting it. Connection strings stored in plaintext are dangerous, because an attacker that can compromise a server will be able to read those connection strings. Even if a machine is not compromised, connection strings stored in plaintext are accessible to administrators and any other users with sufficient privileges on the host machine and/or Windows domain.

Use DPAPI to encrypt the sensitive data in the configuration file on your WCF server machine. To encrypt the <connectionStrings> section by using the DPAPI provider with the machine-key store (the default configuration), run the following command from a command window:

aspnet_regiis -pe "connectionStrings" -app "/MachineDPAPI" -prov 
"DataProtectionConfigurationProvider"

The aspnet_regiis options are:

  • -pe — Specifies the configuration section to encrypt.
  • -app — Specifies your Web application's virtual path. If your application is nested, you need to specify the nested path from the root directory; for example, "/test/aspnet/MachineDPAPI".
  • -prov — Specifies the provider name.

If you need to encrypt configuration file data on multiple servers in a Web farm, use the RSA protected configuration provider because of the ease with which you can export RSA key containers.

Additional Resources