Working in secure channel with SOAP and WCF sometime could be a very complex activity.
BizTalk Server provides many adapters able to cover any requirement and in case of very complex challenge we can use the WCF-Custom adapter to implement more complex and specific binding settings with very high granularity.
The biggest issues are normally related to the binding (security), customization and troubleshooting.
Sometime we need to face very complex security challenges and the strategy to use to solve the challenge quick as possible is critical.
In case of complex binding the best strategy to use is using a .Net approach in the first step and switching in BizTalk in a second time.
We can use a classic sample as below, a mutual certificate authentication in SOAP 1.2 and TLS encryption with a Java service.
I see two main advantages using the .Net configuration file approach:
Visual Studio provides a very useful intellisense approach and it’s very easy to extend and change the binding and test it very quickly.
Documentation and support
In a security challenge the possibility to use the web resources in the web space is crucial, most of the documentation is related on using the WCF .Net approach and you will find a lot of samples using Web.config or App.Config file approach.
For that reason a .Net approach is faster and easier to use and test.
A binding section for mutual certificate via TLS looks as below.
And below the behaviour section.
findValue=”mydomain.westeurope.cloudapp.azure.com” storeLocation=”LocalMachine” storeName=”My” x509FindType=”FindBySubjectName” />
findValue=” mydomain -iso-400” storeLocation=”LocalMachine” storeName=”TrustedPeople” x509FindType=”FindBySubjectName” />
When we are sure about our tests and that everything is running we I can easily switch using BizTalk Server and create the custom bindings.
The WCF custom adapter in general provides the same sections, what we need to do is create a WCF-Custom adapter and a Static Solicit Response Send Port, after that we can easily insert our bindings and behaviors.
In case of specific settings we can import the bindings as well , a great feature offered by BizTalk is the possibility to import and export our bindings, in this way we can easily experiment very fast any complex binding and import this binding in our WCF-Custom adapter in a second time.
Sometime external services require very complex customization and we need to override protocol or messaging behaviour in the channel, for instance some service doesn’t accept the mustUnderstand in the SOAP header
or we need to impersonate a specific user by certificate in the header or just manage a custom SOAP header.
I’m my experience best strategy to use is developing the custom behaviour in a WCF .Net project, this is the faster way to test the WCF behavior without we need to manage GAC deployments, Host Instances restarts and so on.
when the WCF behavior works we can easily configure it in the BizTalk port.
Using a .Net approach we need to add the WCF behavior by reference.
Configure it in .config file and test/debug it.
When everything is working, we will be able to add the behavior in BizTalk adding the component in GAC and adding the behavior in the BizTalk port.
The WCF-Custom BizTalk Server adapter offers a very good level of customization, selecting the bindings and behavior tabs.
The most complex side in this area is the security and the messaging inspection, I recommend two things to do for troubleshooting, one using Fiddler or WireShark and the second the WCF logging, I recommend to use together as they compensate them each other.
Fiddler is a very powerful free tool, easy to use, just run it and use it.
In case of BizTalk Server we need to configure the framework to use Fiddler, at this point BizTalk offers many easy ways to do that.
By the port if we like to affect the port only.
By the adapter host handler if we want to affect to all the artefacts under it.
For deep level sniffing and we need to sniff Net TCP or other protocols I recommend WireShark, a bit more complex to use but this is the tool.
To configure the WCF logging we simply need to add the section below in the BizTalk configuration file to affect BizTalk services only, in the Machine config file if we want to affect all the services in the entire machine or in the Web.Config to affect the specific service.
<!– DIAGNOSTICS –>
type=”System.Diagnostics.DefaultTraceListener” name=”Default” >
name=”messages” traceOutputOptions=”None” >
propagateActivity=”true” name=”System.ServiceModel” switchValue=”Error,ActivityTracing“>
initializeData=”c:logsapp_tracelogClient.svclog” type=”System.Diagnostics.XmlWriterTraceListener, System, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089“
name=”ServiceModelTraceListener” traceOutputOptions=”Timestamp” >