Sensitive Data

The threats of network eavesdropping or information disclosure at intermediate application nodes must be addressed if your Web service request or response messages convey sensitive application data, for example, credit card numbers , employee details, and so on.

In a closed environment where you are in control of both endpoints, you can use SSL or IPSec to provide transport layer encryption. In other environments and where messages are routed through intermediate application modes, a message level solution is required. The WS-Security standard defines a confidentiality service based on the World Wide Web Consortium (W3C) XML Encryption standard that allows you to encrypt some or all of a SOAP message before it is transmitted.

XML Encryption

You can encrypt all or part of a SOAP message in three different ways:

• Asymmetric encryption using X.509 certificates

• Symmetric encryption using shared keys

• Symmetric encryption using custom binary tokens

Asymmetric Encryption Using X.509 Certificates

With this approach, the consumer uses the public key portion of an X.509 certificate to encrypt the SOAP message. This can only be decrypted by the service that owns the corresponding private key.

The Web service must be able to access the associated private key. By default, WSE searches for X.509 certificates in the local machine store. You can use the <x509> configuration element in Web.config to set the store location to the current user store as follows .

 <configuration>   <microsoft.web.services>     <security>       <x509 storeLocation="CurrentUser" />    </security>   </microsoft.web.services> </configuration> 

If you use the user store, the user profile of the Web service's process account must be loaded. If you run your Web service using the default ASPNET least privileged local account, version 1.1 of the .NET Framework loads the user profile for this account, which makes the user key store accessible.

For Web services built using version 1.0 of the .NET Framework, the ASPNET user profile is not loaded. In this scenario, you have two options.

• Run your Web service using a custom least privileged account with which you have previously interactively logged on to the Web server to create a user profile.

• Store the key in the local machine store and grant access to your Web service process account. On Windows 2000, this is the ASPNET account by default. On Windows Server 2003, it is the Network Service account by default.

  To grant access, use Windows Explorer to configure an ACL on the following folder that grants full control to the Web service process account.

   \Documents and Settings\All Users\Application Data\                                               Microsoft\Crypto\RSA\MachineKeys 

For more information, see the "Managing X.509 Certificates," "Encrypting a SOAP Message Using an X.509 Certificate," and "Decrypting a SOAP Message Using an X.509 Certificate" sections in the WSE documentation.

Symmetric Encryption Using Shared Keys

With symmetric encryption, the Web service and its consumer share a secret key to encrypt and decrypt the SOAP message. This encryption is faster than asymmetric encryption although the consumer and the service provider must use some out-of- band mechanism to share the key.

For more information, see the "Encrypting a SOAP Message Using a Shared Key" and "Decrypting a SOAP Message Using a Shared Key" sections in the WSE documentation.

Symmetric Encryption Using Custom Binary Tokens

You can also use WSE to define a custom binary token to encapsulate the custom security credentials used to encrypt and decrypt messages. Your code needs two classes. The sender class must be derived from the BinarySecurityToken class to encapsulate the custom security credentials and encrypt the message. The recipient class must be derived from DecryptionkeyProvider class to retrieve the key and decrypt the message.

For more information, see the "Encrypting a SOAP Message Using a Custom Binary Security Token" and "Decrypting a SOAP Message Using a Custom Binary Security Token" sections in the WSE documentation.

Encrypting Parts of a Message

By default, WSE encrypts the entire SOAP body and none of the SOAP header information. However, you can also use WSE to programmatically encrypt and decrypt portions of a message.

For more information, see the "Specifying the Parts of a SOAP Message that are Signed or Encrypted" section in the WSE documentation.