Richard Seroter's Architecture Musings

Article Series on BizTalk WCF: Part II, Security Patterns

Written by

Richard Seroter

in

, , ,

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: ,

Comments

4 responses to “Article Series on BizTalk WCF: Part II, Security Patterns”

  1. chris restall Avatar
    chris restall

    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.

    Reply
  2. Richard Seroter Avatar
    Richard Seroter

    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?

    Reply
  3. Nicolas Avatar
    Nicolas

    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?

    Reply
    1. Richard Seroter Avatar
      Richard Seroter

      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.

      Reply

Leave a comment

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

More posts