When WCF services get consumed by .NET clients, framework takes care of what gets written onto the wire and all the complexity related to SOAP message serialization, security, etc. is hidden behind the scenes. One does not need to pay much attention to the underlying details. My current project gave me this fabulous opportunity to look under the hood because the WCF services are consumed by external business partner who will be implementing the client in Java. The business partner team has not involved the developers in the project yet, the business analyst is using the soapUI tool to test drive the services and was unable to connect to the service because of some authentication issues. Hence, I got assigned the task of investigating the problem. In this post, I will walk through some of the quirks in the soapUI tool and show how to make it work but first I will start with a little background of the different components/concepts.
The services are secured using Basic Authentication protocol over SSL which is pretty standard. In simple terms, the username/password credentials are from Windows Active Directory domain and need to be sent in the HTTP header.
soapUI is an open-source tool which can be used to test the SOAP based services. You can read more about it as well as download a free copy from the their website.
The problem was discovered in soapUI 4.5.0, it might exist in other versions of the tool as well but I have not verified yet.
Problem and the Solution
When a service method request is sent to the service the username and password credentials need to be sent in the HTTP header as part of the request. By default this does not happen and the following is the workaround on how to achieve this to make a successful call to WCF Service secured with Basic Authentication.
If you are new to using soapUI, it’s a pretty straight-forward and simple to use tool. You will need to create a new soapUI project using the WSDL for the service.
Following are two simple setting changes you need to make so that Username\Password credentials are sent as part of the request:
1. Open Preferences dialog for the tool using File > Preferences menu and check the “Authenticate Preemptively” checkbox on the “Http Settings” tab as shown on the screenshot below.
2. Specify username and password strictly as shown in the screenshot below. Username property must be set to username along with the domain name, e.g. Domain\Username and Password for the Password Property. Specifying domain name in the Domain property did not work, also specifying username without domain name did not yield the correct results.
Note: Service name, services methods and usernames are hidden in the screenshots for client privacy reasons.
For those curious how I figured this out. I used Fiddler to see the exact messages sent for successful calls made by .NET Client and then compared that message to the one sent by soapUI. I found that an extra piece of information was included for the successful and then trial/error led me to the successful call.
Mostly I use WCF Test Client provided with .NET Framework for quick testing on the services but it does not allow making calls to WCF Services secured using Basic Authentication (or at least I haven’t figured out a way yet) so soapUI can be handy to .NET Developers who are not planning to consumer the services from JAVA or some other language.