Configuration Management

  • Article

patterns & practices Developer Center

  • How to: Encrypt Sensitive Data in Your Configuration Files
  • How to: Run Your Service Under a Specific Identity
  • How to: Create a Service Account for Your WCF Service
  • How to: Stop Clients from Referencing Your Service
  • How to: Protect Against Message Replay Attacks

How to: Encrypt Sensitive Data in Your Configuration Files

Encrypt configuration sections that contain sensitive data such as SQL connection strings. Use DPAPI to encrypt the sensitive data in the configuration file on your WCF server machine. To encrypt sensitive data in your configuration files, use the aspnet_regiis.exe tool with the -pe (provider encryption) option.

For example, to encrypt the connectionStrings section, using the DPAPI provider with the machine key store (the default configuration), run the following command from a command prompt:

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

The aspnet_regiis settings 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.

The Microsoft .NET Framework supports the following protected configuration providers:

  • RSAProtectedConfigurationProvider. This is the default provider. It uses the RSA public key encryption to encrypt and decrypt data. Use this provider to encrypt configuration files for use on multiple WCF services in a Web farm.
  • DPAPIProtectedConfigurationProvider. This provider uses the Windows Data Protection API (DPAPI) to encrypt and decrypt data. Use this provider to encrypt configuration files for use on a single Windows Server.

You do not need to take any special steps for decryption because the .NET run time takes care of this for you.

Additional Resources

How to: Run Your Service Under a Specific Identity

Running your WCF service with a specific identity helps to isolate the service, allows you to restrict service resources to your application's account, and allows you to use Windows auditing to track the application's activity separately from other applications or services.

If your service is hosted in IIS 6.0, use IIS Manager to create an application pool running as a specific identity. Use IIS Manager to assign your WCF service to that application pool. This would enable your WCF service to run under the security context of the specific identity.

If your service is hosted in a Windows service, configure the Windows service to run using the specific identity. This would enable the WCF service to run under the security context of the specific identity.

Additional Resources

How to: Create a Service Account for Your WCF Service

Running your WCF service with a specific identity, such as a service account, helps to isolate the service. It allows you to restrict service resources to your application's account, and allows you to use Windows auditing to track the application's activity separately from other applications or services.

Perform the following steps to create a service account to run your WCF service:

  1. Create a Windows account.

  2. Run the following aspnet_regiis.exe command to assign the relevant ASP.NET permissions to the account:

    aspnet_regiis.exe -ga machineName\userName

    Note

    This step is required when your application needs to run in ASP.NET compatibility mode; otherwise you can skip this step.

  3. Use the Local Security Policy tool to grant the Windows account the Deny logon locally user right.

    This reduces the privileges of the account and prevents anyone from logging on to Windows locally with this account.

Additional Resources

How to: Stop Clients from Referencing Your Service

If you want to block clients from accessing the Web Services Description Language (WSDL) of your service, you should remove all metadata exchange (mex) endpoints and set the httpGetEnabled and httpsGetEnabled attributes to false. If the metadata is exposed, unwanted clients will be able to generate proxy files (e.g., using SvcUtil.exe) and inspect potentially sensitive methods and parameters offered by the service.

To stop your clients from referencing your service, stop your service from publishing its metadata. To do this, remove all the mex endpoints from your service configuration and configure httpGetEnabled and httpsGetEnabled to false in the ServiceBehavior section as shown below:

 <serviceMetadata httpGetEnabled="False" httpsGetEnabled="False"/>

Additional Resources

How to: Protect Against Message Replay Attacks

A replay attack occurs when an attacker copies a stream of messages between two parties and replays the stream to one or more of the parties. To protect against message replay attacks, enable replay detection in the service.

Perform the following steps to enable replay detection:

  1. Create a customBinding Element.
  2. Create a <security> element.
  3. Create a localClientSettings element or localServiceSettings element.
  4. Set the following attribute values, as appropriate: detectReplays, maxClockSkew, replayWindow, and replayCacheSize.

The following example sets the attributes of both a <localServiceSettings> and a <localClientSettings> element:

<customBinding>
  <binding name="NewBinding0">
   <textMessageEncoding />
    <security>
     <localClientSettings 
      replayCacheSize="800000" 
      maxClockSkew="00:03:00"
      replayWindow="00:03:00" />
     <localServiceSettings 
      replayCacheSize="800000" 
      maxClockSkew="00:03:00"
      replayWindow="00:03:00" />
    <secureConversationBootstrap />
   </security>
  <httpTransport />
 </binding>
</customBinding>

Additional Resources