Logo
CAR REVIEW
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
PREGNANCY
 
 
Windows Server

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

7/1/2011 6:22:53 PM
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 ModeSupported HTTP Binding(s)Description
NonebasicHttpBinding wsHttpBindingNo transport or message security. Anonymous access. All data is sent in clear-text format across the wire.
TransportbasicHttpBinding wsHttpBindingSecurity 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.
MessagebasicHttpBinding wsHttpBindingMessage-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 CredentialbasicHttpBinding wsHttpBindingTransport security is implemented via HTTPS, and the message is authenticated using x.509 or username/password.
Transport CredentialOnlybasicHttpBindingThis 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.

Other -----------------
- Microsoft PowerPoint 2010 : Adding a Digital Signature to a Macro Project & Assigning a Macro to a Toolbar or Ribbon
- Microsoft PowerPoint 2010 : Expanding PowerPoint Functionality - Controlling a Macro
- Windows Server 2008 R2 : Configuring Folder Security, Access, and Replication - Configure Offline File Caching
- Windows Server 2008 R2 : Configuring Folder Security, Access, and Replication - Share Folders
- Windows Server 2008 R2 : Configuring Folder Security, Access, and Replication - Implement Permissions
- Microsoft Dynamics CRM 2011 : Working with Leads and Opportunities - Creating an Opportunity
- Microsoft Dynamics CRM 2011 : Qualifying a Lead & Disqualifying a Lead
- Microsoft Dynamics CRM 2011 : Understanding Leads and Opportunities & Creating a Lead and Tracking Lead Sources
- Performing an Exchange Server 2003 Installation
- Planning a Microsoft Exchange Server 2003 Infrastructure : Preparing Forests and Domains
- Planning a Microsoft Exchange Server 2003 Infrastructure : Installation Considerations
- SharePoint 2010 : Securing Information - Securing Sites
- SharePoint 2010 : Securing Information - Securing Site Collections
- WCF and BizTalk 2009 (part 2) - Publishing Your WCF Service from the Command Line & Consuming WCF Services
- WCF and BizTalk 2009 (part 1) - Exploring the Built-in WCF Adapter Transport Support & Using the WCF Service Publishing Wizard
- SQL Server 2008 : Working with Synonyms
- SQL Server 2008 : Working with Views -Partitioned Views, Updateable Views & Indexed Views
- SQL Server 2008 : Post-Installation - Preproduction Tasks
- Microsoft PowerPoint 2010 : Expanding PowerPoint Functionality - Simplifying Tasks with Macros
- Microsoft PowerPoint 2010 : Enhancing a Presentation with VBA & Setting Developer Options
 
 
Most view of day
- Windows Phone 7 Programming Model : Asynchronous Programming - Background Threads
- Maintaining Dynamics GP : Safeguarding data by Backing Up everything
- Windows Phone 8 : Configuring Basic Device Settings - Battery Saver
- Sharepoint 2013 : Integrating Apps for Office with SharePoint (part 2) - Apps for Office Integrated with an App for SharePoint
- BizTalk Server 2009 : Use The Business Rule Engine (part 1)
- Microsoft Project 2010 : Fine-Tuning Task Details (part 6) - Entering Deadline Dates
- Integrating SharePoint 2013 with the Office Applications (part 3) - Microsoft Excel
- Games and Windows 7 : Using the Games Explorer (part 1)
- Windows Server 2012 : Enabling advanced features using ADAC (part 2) - Configuring fine-grained password policies
- SQL Server 2008 R2 : Creating and Managing Stored Procedures - Startup Procedures
Top 10
- Microsoft Lync Server 2013 : Director Troubleshooting (part 3) - Synthetic Transactions,Telnet
- Microsoft Lync Server 2013 : Director Troubleshooting (part 2) - DNS Records, Logs
- Microsoft Lync Server 2013 : Director Troubleshooting (part 1) - Redirects, Certificates
- Microsoft Lync Server 2013 : Administration of the Director Role (part 4) - Services Management, Client Version Filter
- Microsoft Lync Server 2013 : Administration of the Director Role (part 3) - Topology Status
- Microsoft Lync Server 2013 : Administration of the Director Role (part 2) - Ports,Firewall Rules
- Microsoft Lync Server 2013 : Administration of the Director Role (part 1) - Services
- Microsoft Lync Server 2013 : Configuring the Director (part 2) - Web Services Ports,Reverse Proxy
- Microsoft Lync Server 2013 : Configuring the Director (part 1) - SRV Records, Web Services FQDN Overrides
- Sharepoint 2013 : SharePoint Designer 2013 (part 2) - Locking Down SharePoint Designer
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro