0

I have a WCF (.NET 4.0) service running on IIS 7.5. I need to accept a request from a Java client that I have no control over. According to the guy on the client side they put the content into a soap envelope, sign it and post it as text over HTTPS. Sounds simple enough but this error is showing up in the trace log:

The message with Action 'xxxxxxx' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

relevant config:

<basicHttpBinding>
<binding name="XXhttpBinding">
  <security mode="Transport">
  </security>
</binding>
</basicHttpBinding>

<service name="XXXWcfLib.XXMessageService" behaviorConfiguration="XXBehavior">
<endpoint address="ProcessMessage" binding="basicHttpBinding"    bindingConfiguration="XXhttpBinding" contract="XXXWcfLib.IXXMessageService"   name="ProcessMessage">
      <identity>
        <dns value="localhost" />
      </identity>
    </endpoint>
    <host>
      <baseAddresses>
        <add baseAddress="https://sub.domain.com/XXService/XXXService.svc" />
      </baseAddresses>
    </host>
 </service>

ServiceContract interface:

<OperationContract()>
Function ProcessMessage(ByVal Message As String) As String

Edit:

Header from java client's post:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <SOAP-SEC:Signature SOAP:mustUnderstand="1" xmlns:SOAP-   SEC="http://schemas.xmlsoap.org/soap/security/2000-12"  xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">       </CanonicalizationMethod>
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1">   </SignatureMethod>
        <Reference URI="#Body">
        <Transforms>
           <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
        <DigestValue>----------------------</DigestValue>
      </Reference>
    </SignedInfo>
  <SignatureValue>---------------------</SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509Certificate></X509Certificate>
      <X509IssuerSerial>
        <X509IssuerName>-------------------</X509IssuerName>
        <X509SerialNumber>################</X509SerialNumber>
      </X509IssuerSerial>
    </X509Data>
  </KeyInfo>
</Signature>
</SOAP-SEC:Signature>
<To s:mustUnderstand="1"    xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">https://sub.domain.com/xxse rvice/xxservice.svc/ProcessMessage</To>
<Action s:mustUnderstand="1"  xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">appaction</Action>
</s:Header>
Jacob
  • 505
  • 3
  • 8
  • 23
  • 1
    I would suggest you build a sample .NET client and try to invoke your service and inspect the raw request made with Fiddler and then compare it with the Java clients request to find out the difference. – Rajesh Aug 16 '12 at 08:57

1 Answers1

0

I ended up changing my Interface to:

  <OperationContract()>
    Function ProcessMessage(ByVal Message As Stream) As String

I then handled the validation the message manually in my implementation.

Jacob
  • 505
  • 3
  • 8
  • 23