Article Series on BizTalk WCF: Part II, Security Patterns

UPDATE: I have since moved these articles to my own blog and they can be found here.

My second article on integrating Windows Communication Foundation with BizTalk Server is now online.  The one deals with all the various WCF security configurations and how BizTalk consumes each one.

Specifically, I address message vs. transport security, certificates, username tokens and declarative code-based security.  It was pleasing to see how gracefully BizTalk accommodated each security permutation I threw at it.

Series Summary
BizTalk and WCF: Part I, Operation Patterns Get the source code!
BizTalk and WCF: Part II, Security Patterns
BizTalk and WCF: Part III, Transaction Patterns
BizTalk and WCF: Part IV, Attachment Patterns
BizTalk and WCF: Part V, Publishing Operations Patterns Get the source code!
BizTalk and WCF: Part VI, Publishing Advanced Service Patterns
BizTalk and WCF: Part VII, About the BizTalk Adapter Pack Get the source code!
BizTalk and WCF: Part VIII, BizTalk Adapter Pack Service Model Patterns
BizTalk and WCF: Part IX, BizTalk Adapter Pack BizTalk Patterns

Technorati Tags: ,

Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

4 thoughts

  1. Hi Richard, Great series!

    I’m struggling a bit with a WCF service that is hosted in a windows service and called from a biztalk orchestration and was hoping perhaps you may have some insight. The only way it will work, on my devlopment server, is to set the Biztalk WCF netTcp transport properties in biztalk to:

    Security mode: Transport
    Transport client credential type: windows
    Transport protection level: EncryptAndSign.

    No other security combination works. Why do I have to use this combination?

    I’ve checked the config of the WCF service and there are no security/identity entries there. I’d like to test with “none” but it won’t seem to accept that.

    Is there something on the service side I have to add in the config? Is it because this is hosted in a windows service?

    When I deploy all of this on our build server, the Biztalk WCF netTcp transport properties set like above cause biztalk to just lock up (Running service instance never goes away and CPU goes through the roof). All other Biztalk WCF netTcp transport property combinations on the build server cause an immediate failure like my development box.

  2. Hi Chris,

    What error do you get with other security configurations? If you try hosting your service elsewhere (let’s say, self hosting) do you get the same behavior, or have you isolated it to the Windows service?

  3. Hello Richard, I am trying to understand if the send port will be “reused” for multiple orquestrations instances. Specifically, that once the “handshake” process is done with the wcf service, it will maintain the wshtttp reliable session context. I will like to know if the https process overhead will be done for each orquestration instance since we will be sending more than 10K messages per hour. I am afraid that for each orquestration instance there will be a new “instance” of the send port and the security handshake process will be done for each. Do you have any idea how does this work?

    1. Hi Nicholas, I would suspect that each send port instance is set up to do the handshake per request. That said, you can throttle how many send ports spawn for a given endpoint, so it’s not like you’d have 1000 simultaneous send port instances, unless you configured it that way. But, unless these are very long service calls, there really shouldn’t be a problem with the volume you mention.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.