Can you test a certificate-secured WCF service with SoapUI? - wcf

I have a WCF service that is:
Using the BasicHttpBinding (if you can answer for WsHttpBinding even better!)
Using TransportWithMessageCredential Security
Using X.509 Certificates for Transport and Message security
I would like to be able to test this service with SoapUI.
However, when I attempt to do so it appears that SoapUI signs more of the message than WCF expects, leading to this error (detected in the Application log after enabling ServiceModel auditing):
CryptographicException: Unable to resolve the '#id-100' URI in the signature to compute the digest.
Alternatively, when I use a WsHttpBinding I get the exception:
MessageSecurityException: The message received over Transport security has unsigned 'To' header.
Similar issues have been raised before:
WCF rejects messages with additional signed elements
http://connect.microsoft.com/VisualStudio/feedback/details/481030/wcf-signed-parts
Getting WCF to accept unsigned 'To' Header
This does not strike me as a "Java talking to MS WCF" issue - I have a Java test client working without issue. Likewise, I can use WCFStorm to test the service. However, SoapUI has become a bit of a de facto test standard, particularly for non-Windows consumers.
So, has anyone managed to overcome these issues and test a certificate-secured WCF service using SoapUI?
Thanks
I believe this issue is irresolvable, based on my own testing and a 250 bounty not yielding an answer.
The "web.config" is generated dynamically, but it's effectively matching either of the following bindings:
<wsHttpBinding>
<binding name="WSHttpBinding_ITwoWayAsync" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"
bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="250000" maxReceivedMessageSize="250000"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="Certificate" proxyCredentialType="None" realm="" />
<message clientCredentialType="Certificate" negotiateServiceCredential="false"
establishSecurityContext="false"
algorithmSuite="Default" />
</security>
</binding>
</wsHttpBinding>
<basicHttpBinding>
<binding name="BasicHttpBinding_ITwoWayAsync" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"
bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="250000" maxReceivedMessageSize="250000"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="Certificate" proxyCredentialType="None" realm="" />
<message clientCredentialType="Certificate" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>

This was impossible with SoapUI and I had to use another tool called WCFStorm.

I had exactly the same issue. I haven't it working with BasicHttpBinding but do have it working with WsHttpBinding. I had the error The message received over Transport security has unsigned 'To' header as well. I created a blogpost for solving this issue. Se the blogpost Connect SoapUI to WCF service certificate authentication for more information.
You have to set the parts in the signature. By default SoapUI signs the whole request but that isn’t the default by WCF so we have to set the parts that we want to sign. So add as Name “To”, Namespace “http://www.w3.org/2005/08/addressing” (this is my namespace but check yours) and set Encode to “Element”. Also check the WS-A panel in your request. Check addressing and set the default "To" checkbox.

I have been able to do this with a custom binding in WCF and a PFX certificate file. I had to use a custom binding because I needed to restrict access to one certificate - which is outside the scope of this question. My certificate pfx file had both the public key and the private key. The private key was password protected. I could not get to this work with any other certificate format.
In SoapUI, I go to File -> Preferences -> SSL Settings:
-->Keystore Name: path_to_PFX_file
-->KeyStore password: your_private_key_password
Here are my web.config settings which are pretty much the same as a basicHttpBinding:
<customBinding>
<binding name="MyServiceBindingConfiguration">
<security authenticationMode="UserNameOverTransport" includeTimestamp="false" requireDerivedKeys="false" securityHeaderLayout="Lax" messageProtectionOrder="SignBeforeEncrypt" messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10">
<localClientSettings maxClockSkew="00:30:00" />
<localServiceSettings maxClockSkew="00:30:00" />
<secureConversationBootstrap />
</security>
<textMessageEncoding messageVersion="Soap11">
<readerQuotas maxDepth="32" maxStringContentLength="524288" maxArrayLength="524288" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
</textMessageEncoding>
<httpsTransport requireClientCertificate="true" />
</binding>
</customBinding>
Hope this helps.

Related

WCF Binding Transport/Windows Binding Security Not Being Enforced

I'm in the process of adding SSL security with Windows authentication to a formerly unsecured IIS hosted WCF service application. To my surprise, I found that two of the service endpoints were already using a Binding with Transport and Windows security. This is confusing because the client applications consuming this service are not configured to use Transport security or Windows credentials. Here is the service config:
<binding name="LargeBuffer" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
...
<service behaviorConfiguration="WebServices.GCServiceBehavior"
name="WebServices.GCService">
<endpoint address="" binding="basicHttpBinding" name="GCSecuredEndpoint"
bindingName="largeBuffer" contract="WebServices.IGCService" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
When I use Visual Studio to generate the client proxy and configuration, it creates this:
<binding name="GCSecuredEndpoint" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
...
<endpoint address="http://devservices.mysite.com/GCService/GCService.svc"
binding="basicHttpBinding" bindingConfiguration="GCSecuredEndpoint"
contract="GCSvc.IGCService" name="GCSecuredEndpoint" />
Notice it's security mode="None" and Transport ClientCredentialType is None instead of Windows. When I call a method on the GCService it succeeds. I would expect it to first complain that I'm trying to access over http instead of https, but it doesn't. Next I would expect it to not authenticate or complain that the client endpoint doesn't match the service in terms of authentication, but it doesn't.
I have another service in the same application that I had just setup with Transport/Windows security just without all the buffer/readquota stuff. For starters, when I generate the client proxy/config in VS for this service, it automatically uses the https address, transport security, and windows authentication. If I manually change it to use None for both, as above, a call to one of the service methods does not succeed, as expected. Why is the GCService above working?
The server config has
bindingName="largeBuffer"
instead of
bindingConfiguration="LargeBuffer"
The LargeBuffer binding configuration was never being used.

WCF Service Reference Support Files Not Updating

I have a VS 2010 solution containing a WCF service project and a unit test project. The unit test project has a service reference to the WCF service.
Web.config for the WCF service project sets a number of binding attributes to other-than-default values:
web.config: (Specifically note maxBufferSize="20000000")
<basicHttpBinding>
<binding name="basicHttpBindingConfig" maxReceivedMessageSize="20000000" maxBufferSize="20000000" maxBufferPoolSize="20000000">
<readerQuotas maxDepth="32" maxArrayLength="200000000" maxStringContentLength="200000000"/>
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm"/>
</security>
</binding>
</basicHttpBinding>
While examining this issue, I came to realize that the unit test project's service reference support files do not contain the values I would expect (i.e. the values configured in the WCF service's web.config):
configuration.svcinfo:
(Specifically note maxBufferSize="65536")
<binding hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" messageEncoding="Text" name="BasicHttpBinding_IBishopService" textEncoding="utf-8" transferMode="Buffered">
<readerQuotas maxArrayLength="16384" maxBytesPerRead="4096" maxDepth="32" maxNameTableCharCount="16384" maxStringContentLength="8192" />
<security mode="None">
<message algorithmSuite="Default" clientCredentialType="UserName" />
<transport clientCredentialType="None" proxyCredentialType="None" realm="" />
</security>
</binding>
Deleting and re-creating the service reference or updating the service reference re-creates the files, but I still end up with the same values.
Why?
Update
Here's the app.config of the client
<binding name="BasicHttpBinding_IMyService" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="200000000" maxBufferPoolSize="200000000" maxReceivedMessageSize="200000000"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="200000000" maxArrayLength="200000000"
maxBytesPerRead="200000000" maxNameTableCharCount="200000000" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
Same issue here and no solution after half a day messing about with config files... Changing automatically generated files is usually frowned upon, so my feeling says that "there has got to be a better way, Dennis".
UPDATE: I got my problem fixed by removing the name attribute in the binding configuration.
So your current web.config is looking like this
<basicHttpBinding>
<binding name="basicHttpBindingConfig" maxReceivedMessageSize="20000000" maxBufferSize="20000000" maxBufferPoolSize="20000000">
<readerQuotas maxDepth="32" maxArrayLength="200000000" maxStringContentLength="200000000"/>
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm"/>
</security>
</binding>
</basicHttpBinding>
would become
<basicHttpBinding>
<binding maxReceivedMessageSize="20000000" maxBufferSize="20000000" maxBufferPoolSize="20000000">
<readerQuotas maxDepth="32" maxArrayLength="200000000" maxStringContentLength="200000000"/>
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm"/>
</security>
</binding>
</basicHttpBinding>
I think you only need to this at the client-side. By removing the name attribute, you essentially change the default basicHttpBinding configuration for your app, as far as I understand it. Credits for this solution here.
Another update: if you name your service configuration correctly (including the namespace) it will pick up the binding configuration. So instead of
<service name="ServiceName">
you need
<service name="My.Namespace.ServiceName">
That is correct behavior. Some information included in binding are specific to only one side of the configuration and both client and server can use completely different values. Also these values are defence against Denial of Service attach so service doesn't want to show them publicly.
Those values affects only processing of incoming messages so service configures how it will handle incoming requests and client configures how it will handle incoming responses. Requests and responses can have different characteristics and different configuration. There is no need for service to be configured to accept 1MB requests if it always receives only few KB requests and returns 1MB responses.
Btw. this is WCF specific feature not related to general web services and because of that there is no standardized way to describe this in WSDL.

Calling SOAP UI mock service with WCF: "The provided URI scheme 'https' is invalid; expected 'http'."

A colleague of mine gave me a copy of a mock service project for SOAP UI. I can open and run this mock service fine on my machine.
It is running at address: http://localhost:8088/mockShipmentInformationService
The WSDL is provided on address: http://localhost:8088/mockShipmentInformationService_SOAPBinding?WSDL
Using the WSDL provided, I added a Service Reference to the application project. In order to test the methods calling the service, I also added the service reference to the Unit testing project.
For both projects, the following is added to the app.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="ShipmentInformationService_SOAPBinding" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:8088/mockShipmentInformationService_SOAPBinding"
binding="basicHttpBinding" bindingConfiguration="ShipmentInformationService_SOAPBinding"
contract="ShipmentInformationService.ShipmentInformationService"
name="ShipmentInformationServicePort" />
</client>
</system.serviceModel>
As you can see, the URL is using the normal http protocol, not https. Also, my security mode is set to "none". Yet, I keep on getting the following error message, when attempting to call the service method:
The provided URI scheme 'https' is invalid; expected 'http'.
Parameter name: via
What gives? Might there be some URLs defined somewhere that are wreaking havoc? Where should I look?
I just discovered that it was all in the app.config files. The application project had a wrong URL in the applicationSettings section and the URL wasn't present there for the unit testing project. I can now at least call the service, although I am having some other issues now.

When does WCF NetTcpBinding need full trust on the client?

I'm using WCF to communicate to several servers.
For my local server netTcpBinding works like expected, no problems.
But when I try to connect to my remote server (Azure) using the following netTcpBinding in app.config, this will crash the application on initialization since the netTcpBinding can't be created without full trust.
This binding in the app.config file,
<bindings>
<netTcpBinding>
<binding name="NetTcpBinding_IService" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
transactionFlow="false" transferMode="Buffered" transactionProtocol="OleTransactions"
hostNameComparisonMode="StrongWildcard" listenBacklog="10" maxBufferPoolSize="524288"
maxBufferSize="65536" maxConnections="10" maxReceivedMessageSize="65536">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<reliableSession ordered="true" inactivityTimeout="00:10:00"
enabled="false" />
<security mode="Transport">
<transport clientCredentialType="None" protectionLevel="EncryptAndSign" />
<message clientCredentialType="Windows" />
</security>
</binding>
</netTcpBinding>
</bindings>
It will result in this error:
An error occurred creating the configuration section handler for "system.serviceModel/bindings": That assembly does not allow partially trusted callers. (K:\Somepath\Testing.exe.Config line 6)
The strange thing: In the app.config file I got client endpoints connecting to other netTcpBindings (without declaring them explizitely in the binding section).
Why do these generic netTcpBindings work in partial trust, but the one I showed above does not?
Or am I just confused by this error message and the problem is not about full trust?
Update: If I remove the <binding> section the stuff will run without problems. So I'm allowed to use netTcpBinding in partial trust, but I'm not allowed to modify the parameters? This is a pity since I'd like to have some form of encryption on my communication.
NetTcpBinding in general is not supported in partial trust environments.
While the basic communication works fine (as you've seen in other environments), features like TransportSecurity and ReliableMessaging (which you have on your sample configuration) are explicitly not supported on partial trust (it sucks, big time).

BizTalk WCF Send Port error - The header 'CoordinationContext' was not understood

I have a WCF-WSHttp Send Port set up with Enable Transactions checked, and I'm getting the following error when a message is sent:
The header 'CoordinationContext' from the namespace 'http://schemas.xmlsoap.org/ws/2004/10/wscoor' was not understood by the recipient of this message, causing the message to not be processed. This error typically indicates that the sender of this message has enabled a communication protocol that the receiver cannot process. Please ensure that the configuration of the client's binding is consistent with the service's binding.
If I uncheck the Enable Transactions box, the message is processed successfully. Can anyone help me get this working with transaction support?
Here's the binding info from the service's web.config (transactionFlow is set to true):
<bindings>
<wsHttpBinding>
<binding name="serviceBinding" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
bypassProxyOnLocal="false" transactionFlow="true" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<reliableSession ordered="true" inactivityTimeout="00:10:00"
enabled="false" />
<security mode="Transport">
<transport clientCredentialType="Ntlm" proxyCredentialType="None"
realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true"
establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
</bindings>
Thanks in advance!
It could be a problem with the setup of MSDTC, see http://msdn.microsoft.com/en-us/library/ms752261.aspx
Also check the event log for MSDTC related errors.
Turns out the problem was with the service itself. Although the bindings were configured properly with transactionFlow="true", the service contract was missing the following attribute to explicitly allow transactions:
[System.ServiceModel.TransactionFlowAttribute(System.ServiceModel.TransactionFlowOption.Allowed)]