We Keep Coding

Generating SOAP Action Header on Wcf-Custom Send Port

I am in the process of creating a Send Port in Biztalk, that uses the Wcf-Custom adapter for sending SOAP requests.
So far I have been testing the SOAP requests in Visual Studio, using C# code from the System-ServiceModel namespace. See code below:
/ CODEGEN: Generating message contract since the operation transferPayments is neither RPC nor document wrapped.
[System.ServiceModel.OperationContractAttribute(Action="urn:CorporateService:transferPayment", ReplyAction="*")]
[System.ServiceModel.XmlSerializerFormatAttribute()]
transferPaymentsResponse transferPayments(transferPayment1 request);
[System.ServiceModel.OperationContractAttribute(Action="urn:CorporateService:transferPayment", ReplyAction="*")]
System.Threading.Tasks.Task<transferPaymentsResponse> transferPaymentsAsync(transferPayment1 request);
I need to add this "transferPayment" action to the SOAP Action Header field in the adapter.
Using the provided example, I've come up with this
<BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Operation Name="TransferPayment" Action="http://bankconnect.dk/schema/2014/CorporateService/TransferPayment" />
</BtsActionMapping>
Where "http://bankconnect.dk/schema/2014" is the namespace, "CorporateService" is the service, and "TransferPayment" is the action. I'm unsure if this is the correct way to go about implementing this.
My question how I should format the SOAP Action Headers, so that they correspond to the c# code used.

I'd suggest you use the BizTalk WCF Service Consume Wizard to generate the schema's inside BizTalk. This would make all the possible Actions for you.

SOAP Security advice required

Ahead of a full 3rd Party penetration test, one of our clients has performed a preliminary security audit against our system.
This has revealed a handful of potential exploits that we are happy to deal with, but there is one item in the report that I'm not sure I agree with but I've been unable to convince them.
They have reported that they have been able to send a message which has been tampered with to one of our soap-based web services and that it has reported an error. This, they suggest, implies that the server has attempted to process the message.
So the request looks something like this :-
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://example.com/soap/envelope/]]>><" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<tns:SomeMethod xmlns:tns="http://example.com/"/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Note the encoded ]]>>< inserted into the xmlns:SOAP-ENV attribute.
The response from the server is :-
<soap:Body>
<soap:Fault>
<faultcode>soap:VersionMismatch</faultcode>
<faultstring>Possible SOAP version mismatch: Envelope namespace http://example.com/soap/envelope/]]>>< was unexpected. Expecting http://example.com/soap/envelope/.</faultstring>
<detail />
</soap:Fault>
</soap:Body>
Their argument is that this shows that the payload has been inserted into an XML document and so has been processed (presumably exposing us to things like XXE exploits) and the fact that the error is a SOAP error rather than a generic 500 error proves this.
I'm not convinced that this is the case but I'm struggling to convince the client of this. According to this (https://msdn.microsoft.com/en-us/library/aa480498.aspx) article the XmlSerializer is responsible for serialising and deserialising the SOAP Xml to parmeters and so this is rejecting the bad SOAP envelope.
Can anyone confirm whether we have a security issue? And if it is how we should fix it?

Can anyone confirm whether we have a security issue? And if it is how we should fix it?
There is no security issue.
Different SOAP processors will produce different error messages for this example, though the SOAP protocol recommends the "SOAP version mismatch" fault. In my experience of 10+ years working with XML, SOAP, and other web services protocols, it is perfectly legitimate what his SOAP processor does. It simply rejects the SOAP-ENV:Envelope qualified tag based on the XML namespace mismatch, because the xmlns binding URI simply differs from the expected URI:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://example.com/soap/envelope/]]>><"
In fact, this XML is perfectly legit. And it should be rejected by the SOAP processor with a SOAP version mismatch fault.

Handling custom soap header in WCF Service

I am creating WCF Service to receive a message (strings). It has soap request has header as shown below. I went thru so many example that I found on internet, but I could not understand any of those thoroughly.
I found this article is very helpful but still could not make it works
http://weblogs.asp.net/paolopia/handling-custom-soap-headers-via-wcf-behaviors
After reading several article, I come to know that I need to handle the following area (a)SOAP Header (b) Message Inspector (c) Client Context and (d) Server Context class
How do I handle mustUnderstand header
I need to capture value passed messageid, ReplyTo, To, From, Action
The following soap message need to be consumed
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
<soapenv:Header>
<a:Action s:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b</a:Action>
<a:From><a:Address>urn:oid:1.2.3.4.5.6.1234567.10.70.142.2</a:Address>
</a:From>
<a:MessageID>urn:uuid:3a40ebfe-2abc-4de9-b6f6-06c7962f6050</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To>https://localhost/MyWCFService/Service.asmx</a:To>
</soapenv:Header>
...

If you are creating a WCF Service and you try inspect the SOAP message, you can implement the IDispatchMessageInspector Interface Also, for WCF client refer to IClientMessageInspector Interface
These are some usefull links:
http://ianpicknell.blogspot.com.tr/2011/03/implementing-idispatchmessageinspector.html
How to use IDispatchMessageInspector in a WCF Service?

LinkedIn API 401 Unauthorised when using Field Selectors

I am attempting to get specific information from the user's profile via the LinkedIn API.
The URL I am using for the GET call is the following:
http://api.linkedin.com/v1/people/~:(id,first-name,last-name,industry,headline,public-profile-url)
When attempting this I get a "401 Unauthorized" response from the server. However, when I do a GET to http://api.linkedin.com/v1/people/~ within the same function with the same auth keys, etc. it works just fine.
The error presented in the response is as follows:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<error>
<status>401</status>
<timestamp>1316082986700</timestamp>
<request-id>SVWTG5ARQM</request-id>
<error-code>0</error-code>
<message>[unauthorized].</message>
</error>
Any ideas of why this might be happening? Anything would be greatly appreciated.

It is likely your OAuth library is buggy. Can you view the full request and response?
I would make sure your Authorization / OAuth header has the same signature as the one generated from this tool:
https://developer.linkedin.com/oauth-test-console
If not, you'll need to get a new library, update/fix your library, etc.
If yes, then that is weird. Come back and we'll go from there :)

Semi-custom WCF proxy returns zeros, despite valid data coming back on wire

There is a series of SOAP services which I wish to call (across a series of services), and while the end points are well defined & documented, there is no WSDL data... so I decided to build my own.
In order to do so, I built a test WCF service which matches the known interface of the service I wish to call.
I then saved the WSDL it exposed, changed the base address the WSDL references, created my proxy (with wsdl.exe), added it to a test client project, and can successfully create a proxy and make calls which causes the SOAP service to send the expected response... only this expected response is not picked up by the proxy and returned to the calling code.
When looking at the back and forth traffic... I can clearly see that the service is replying with what I want.
Any suggestions as to how I might troubleshoot this and get the proxy to pickup the data?
Given the replies are effectively identical, I'm forced to look back at the differences between what my client is sending and another sends.
A known working app sends it's XML blob starting with the following:
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
While my client immediately starts with the envelope (without the xml tag, and with one less namespace):
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
The other difference is that the message within the body is prefixed by a namespace in theirs, while mine it is not... though both define this namespace within the tag.
Ala:
<s:Body>
<u:DoSomething xmlns:u="urn:http://some.namespace.org" />
</s:Body>
VS:
<s:Body>
<DoSomething xmlns="urn:http://some.namespace.org" />
</s:Body>

This is not a namespace:
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
It's setting the encoding style for the envelope which, even though it's not required per the SOAP spec, may be required by the specific implementation you're talking to. Do you have enough control over what you're sending from the client to get that put on there?
Other than that, the XML PI is not required and I think you're definitely on the right track looking at the body XML. This is almost always the case of some kind of namespace mismatch somewhere. Are you 100% positive the namespace URIs are identical?

The most likely problem is the VS version using a "default" XML namespace. There are soap parsers that I've worked which don't work correctly when using an un-aliased (default) namespaces. If you know using the u: alias works with the service, your proxy should also generate it even when every tag inside the s:Body element is prefixed with the alias.