BizTalk 2009 : Wcf Adapters: Standardizing Your Integration Endpoints - Securing Your Endpoints

A common mistake by developers, though, is to leave security to the last minute before an application is about to launch. Although WCF configuration makes security easier than ever, there are also lots of configuration settings that have performance and design impacts on the end solution. Leaving security to the last minute may result in a service not working as expected.

1. Transport, Message, or Mixed?

Depending on the WCF binding, multiple security options and configurations are available. Typically, most developers will use either basicHttpBinding or wsHttpBinding as their binding because these are easily hosted in IIS. Others, such as netTcpBinding or netNamedPipeBinding, rely on a service host, such as a custom Windows service, to host the endpoint.

When determining how to publish your endpoint, there are multiple security modes that you'll want to consider. The BizTalk WCF Service Publishing Wizard typically publishes to an HTTP endpoint in IIS. Table 1 lists the different modes of security the HTTP bindings support.

When deploying your endpoint, you need to consider who will be accessing your solution and by what transport(s). This is especially important for BizTalk endpoints. Most non-BizTalk services are typically point-to-point, meaning that when a client calls a service, the service processes the request by performing some business logic or accessing a database and returns the results to the client. BizTalk, on the other hand, being an integration tier, typically routes between many services.

There are three important aspects of security that need to be considered when choosing your security mode:

• Integrity: The message was delivered from a trustworthy source and has not been modified.

• Confidentiality: The message was delivered in an encrypted format.

• Authentication: The message has been authenticated, either via transport or message level.

Relying only on transport-level security to implement integrity, confidentiality, and authentication is not always the best way to expose services. Message-level security provides the ability to flow the message integrity, confidentiality, and authentication across many endpoints. If only transport security is used, then each communication channel must implement their own security, and the original requestor's credentials are lost.

The TransportWithMessageCredential security mode uses a good balance of both transport and message security options and is often a choice for many organizations. Offloading the confidentiality of the message to the transport via HTTPS is often faster than implementing encryption within the WCF message. But instead of relying on IIS to enforce authentication, leave IIS with Anonymous access enabled, and attach the source credentials as part of the SOAP message. This provides the benefit of being able to forward the message credentials onto the next endpoint if necessary. Although this can offer flexibility, it also introduces a performance hit because WCF needs to perform additional functionality. Consider your environment and performance needs when implementing this security mode.

2. Using makecert to Implement Message-Level Encryption

Using a certificate to implement confidentiality at the message level is a good way to be transport-agnostic. The encrypted message can travel over multiple endpoints without having to be decrypted by individual services.

To implement certificate encryption during development, you'll need to use a tool called makecert to generate the certificates. makecert is a utility published as part of the Windows SDK and Visual Studio.

First, you'll need to create a Trusted Root Authority certificate. Once created, you will be able to create a second x.509 certificate derived from the Trusted Root Authority certificate to encrypt the message. To create the Trusted Root Authority certificate, type the following at a command prompt:

makecert -pe -n "CN=My Root Authority" -ss root -sr LocalMachine -a sha1 

    -sky signature -r

Here is an explanation of the command-line parameters in this example:

-pe marks the private key as exportable.

-n "CN=<name>" is the common name of the root authority.

-ss root stores the generated certificate in the Trusted Root Authorities container.

-sr LocalMachine specifies that the store is located on the local computer.

-a sha1 specifies SHA1 is to be used for encryption.

-sky signature specifies the key type.

-r makes a self-signed certificate.

Now that you have the root authority, you can create another certificate, signed by your root authority, to use for encrypting the message. To do this, type the following at a command prompt:

makecert -pe -n "CN=certsample" -ss my -sr LocalMachine -a sha1 

    -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "My Root Authority" -is root 

    -ir localmachine 

    -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

Again, the command-line parameters are as follows:

-pe marks the private key as exportable.

-n "CN=<name>" is the common name of the certificate.

-ss my stores the generated certificate in the Personal container.

-sr LocalMachine specifies that the store is located on the local computer.

-a sha1 specifies SHA1 is to be used for encryption.

-sky signature specifies the keytype.

-eku 1.3.6.1.5.5.7.3.1 specifies the certificate is used for server authentication.

-in "My Root Authority" specifies the root authority.

-is root specifies the root authority is located in the Trusted Root Authorities container.

-ir localmachine specifies the root authority is located on the local machine.

-sp "Microsoft RSA SChannel Cryptographic Provider" specifies who the certificated is encrypted by.

-sy 12 specifies the provider type.

Now that both certificates have been created, they can be used to encrypt WCF messages.