Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

I've written recently about some peculiar behaviour in SoapUI when using Setup Scripts and also about using testrunner.sh and project properties to to run SoapUI tests via the command line. Those articles were informative in their own right but they didn't cover one important part that many web services usually (and should!) have - authentication. So I'm going to tackle that here, or specifically how to make your SoapUI test cases authenticate to a web service.

If you're reading this post you probably have come across this error when using testrunner.sh...
 SOAP Error
<TITLE>Error 401--Unauthorized</TITLE>
<BODY bgcolor="white">
<FONT FACE=Helvetica><BR CLEAR=all>
<TABLE border=0 cellspacing=5><TR><TD><BR CLEAR=all>
<FONT FACE="Helvetica" COLOR="black" SIZE="3"><H2>Error 401--Unauthorized</H2>
<TABLE border=0 width=100% cellpadding=10><TR><TD VALIGN=top WIDTH=100% BGCOLOR=white><FONT FACE="Courier New"><FONT FACE="Helvetica" SIZE="3"><H3>From RFC 2068 <i>Hypertext Transfer Protocol -- HTTP/1.1</i>:</H3>
</FONT><FONT FACE="Helvetica" SIZE="3"><H4>10.4.2 401 Unauthorized</H4>
</FONT><P><FONT FACE="Courier New">The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in section 11.</FONT></P>

That error is simply due to SoapUI not authenticating to WebLogic (or another container) when sending a SOAP request. It's easily fixed, at least in the UI. However, when testing it is a good idea to be able to control what username and credentials are used for authentication, after all you may want to try different combinations of users and credentials that may have varying access rights, etc.

I found this article that talks about how to achieve this effect at the test suite level, but didn't like the implementation since it didn't use project properties to set the HTTP auth.

My version takes a slightly different approach, similar to what I described in my previously article on using SoapUI with project properties. I add a Setup Script to the Test Case. In addition I do a little bit more validation to ensure authentication happens or the test case fails if login details are not provided. For my testing, I only had one test case that was ran multiple times so this approach worked well. The script below can be easily updated to work with a suite if so required.

So first of all you need to open the Test Case Editor and click the Setup Script tab, that's where you add the code for the script.

This is the script I used...
import com.eviware.soapui.impl.wsdl.teststeps.*
def httpUser = testCase.project.getPropertyValue("httpUser")
def httpPasswd = testCase.project.getPropertyValue("httpPasswd")
assert httpUser != null
assert httpPasswd != null
for(testStep in testCase.getTestStepList()) {
if(testStep instanceof WsdlTestRequestStep) {
def headers = testStep.getHttpRequest().getRequestHeaders()
headers.put("Authorization", "Basic " + (httpUser + ":" + httpPasswd).bytes.encodeBase64().toString())

What the above script does is look for two project properties, httpUser and httpPasswd, makes sure they aren't null and then creates a HTTP Authorization header using those two properties.

Now to set those properties you pass them using the -P parameters to the testrunner.sh script like so:
testrunner.sh <options> -P httpUser=weblogic -P httpPasswd=MyPassword123

Not showing all the other options that are required for testrunner.sh for brevity.

So that's all there is to it. If you have multiple test cases that require authentication, copy/paste the above script into each of them, but at that point you probably should consider using a test suite setup script instead.


A quick disclaimer...

Although I put in a great effort into researching all the topics I cover, mistakes can happen. Use of any information from my blog posts should be at own risk and I do not hold any liability towards any information misuse or damages caused by following any of my posts.

All content and opinions expressed on this Blog are my own and do not represent the opinions of my employer (Oracle). Use of any information contained in this blog post/article is subject to this disclaimer.
Hi! You can search my blog here ⤵
NOTE: (2022) This Blog is no longer maintained and I will not be answering any emails or comments.

I am now focusing on Atari Gamer.