A well-written service has an appropriate level of
security. Windows Communication Foundation makes it very easy to
implement security at multiple levels of the communication stack by
configuring endpoint behaviors and bindings.
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.
Windows Server 2008
support Windows Activation Service (WAS). This will allow you to
leverage IIS as a host for non-HTTP endpoints.
|
|
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.
Table 1. Security Modes for HTTP Bindings
Security Mode | Supported HTTP Binding(s) | Description |
---|
None | basicHttpBinding wsHttpBinding | No transport or message security. Anonymous access. All data is sent in clear-text format across the wire. |
Transport | basicHttpBinding wsHttpBinding | Security
occurs at the transport later. For example, basicHttpBinding and
wsHttpBinding rely on SSL to encrypt the message contents. This type of
security mode can encrypt data across only one communication channel. If
the messages get routed to other services, each communication channel
must ensure the contents are secured appropriately.
When using transport security, there are multiple credential types
supported including Basic, Digest, Ntlm, Windows, and Certificate. |
Message | basicHttpBinding wsHttpBinding | Message-level
security involves additional attributes added to the SOAP message to
support encryption, identification, or both. Messages security can be
implemented via x.509 certificates, username/password, and Windows or
issued tokens. (Windows and issued tokens are supported by wsHttpBinding
only.)
When using message security, you can provide identification by either
username or certificate. To secure the credentials, an optional
algorithmSuite mode can be specified. The default algorithmSuite is
Basic256 encryption. There are many supported encryption algorithms.
Review the MSDN documentation for a full list. |
TransportWith Message Credential | basicHttpBinding wsHttpBinding | Transport security is implemented via HTTPS, and the message is authenticated using x.509 or username/password. |
Transport CredentialOnly | basicHttpBinding | This
security mode relies on the transport to authenticate the user. It does
not provide message confidentiality or integrity. This should be used
only when another form of transport encryption is used such as IPSec. |
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.
makecert.exe is a development tool only. It should not be used for production deployments.
|
|
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.