Consumer Policy for Username questions


Our environment is webMethods 7.1.2

I am trying to consume a 3rd party web service that requires WS Security Username (basic auth).

Using the built in comsumer policy it partially generates the correct security header however the server requires a “nonce” and “created” parameter.

Is there any parameters I can add to the policy file so that webMethods generates these parameters?

In webMethods 6.5 I assume you have to build the security headers manually. Do you have to do the same thing hear as well? If so, how would one do that with the “soapClient” connector?

Does anyone have any examples on how to do this in IS 7.1.x?

Here is an example header that works as generated from SOAPUI.

<wsse:Security soapenv:mustUnderstand=“1” xmlns:wsse="[URL=“”][/size][/URL][SIZE=1]“>
<wsu:Timestamp wsu:Id=“Timestamp-2” xmlns:wsu=”
<wsse:UsernameToken wsu:Id=“UsernameToken-1” xmlns:wsu=”
<wsse:Password Type="">test</wsse:Password>
<wsse:Nonce EncodingType="">nZatpDBPeTxZyeOCS/bsXA==</wsse:Nonce>


Hi ,

after consuming the WSDL.go to WS-secutry tab for u r connector just add WS-secutry and in properties tab select consumer username and save.



Thanks for the response, but that’s not what I was asking. I already have the WS Security username Policy added.

What I was asking is, is there a way to modify or create by own WS Sercurity policy that adds a “nonce” parameter to the header?


And for that matter…puts the timestamp in the correct order in the header. I swear…if webMethods could incorrectly follow a standard…they do. Sorry…venting.


Basically, from my research, there is no built-in support to add the “nonce” header element to a WS security policy. Nor is specifying the order in which security elements are added to the header.

Someone correct me on this if I am completely wrong.

I had though perhaps I could create my own custom policy and add it…no such luck…at least under IS 7.1.2.

I have not looked into 8.X at all yet to see if webMethods has any better support for WSS standards. I’m not expecting anything better.

Keeping in mind this was a Proof-of-concept project and I did not complete a fully functional service…here is my solution.

Despite being somewhat disappointed in webMethods support, I ended up not utilizing a web service descriptor at all. I manually coded a web service “connector” from scratch using the “pub.client:soapHTTP” service to invoke it.

The service builds the entire SOAP message from scratch using the services in “pub.soap.utils”.