Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

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

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
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
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server