Forum Discussion

sworisbreathing's avatar
sworisbreathing
New Contributor
15 years ago

Security Headers incomplete

Hi,

I'm having an issue with WS-Security in the SoapUI plugin for Netbeans, version 2.5.1 on NB 6.5.  My web service is configured to use username tokens with passwordtext.  I have a couple users with blank passwords (guest accounts), and every time I try to add one to the SoapUI project, it takes a good bit of mucking about with the project before I can generate a header with the and tags.  Eventually I get it to work, but after the third or fourth user, I still haven't figured out what the exact procedure is, and I'm wondering if there's an issue with the plugin itself (or possibly the documentation).

I know this question has been asked several times and answered in many ways, but I've tried what was suggested both in the forum postings and on the documentation pages at http://www.soapui.org/userguide/requests.html#WS_Security and http://www.soapui.org/userguide/projects/wss.html and still it happens when I add a new user.

So here's the procedure I followed.  Can someone tell me what I'm doing wrong?

1) Add a new user to the web service's authentication system.  Username is "Guest", no password.
2) Edit the "Outgoing WS-Security Configurations" in the SoapUI project.  Add a new outgoing WS-Security configuration.  It's named "Guest".  The default username/alias is set to Guest.  I don't touch the password field at all, but do check the "Must Understand" box.
3) With the new "Guest" configuration selected, I click the "Adds a new WSS Entry" button, select Username, and fill in the following settings:  I use "Guest" in the username box, don't touch the password box, uncheck the nonce and created boxes (my web service doesn't require them), and select "PasswordText" in the password type dropdown.
4) Save the SoapUI project.
5) open a web request.  Click the "Aut" button and select the "Guest" outgoing wss.  Then click the "Send Request" button.
6) Server tosses back a SOAP fault saying that it can't process the wsse:Security header.
7) Check the RAW tab of the request.  Sure enough, there's a header with no contents.
Select a different outgoing WSS that I'd gotten to work previously.  Re-send and it works correctly.
9) Select the "Guest" outgoing WSS and re-send.  Same fault as in step 6.

I don't remember all the steps that I took to get it working.  Among them are that I entered a bogus password for the guest security configuration, re-sent the request, and then deleted the password and re-sent.

So, I have a couple questions/concerns here with respect to the security documentation.  The first is that I count four different places to enter a username and password: the project's security configurations tab, the usernametoken editor for the security configuration, the service endpoint editor, and finally the Aut button.  Could someone please clarify which of these I need to touch and which I can ignore?

Also, considering that it worked after I edited the password fields and then deleted them, I'm wondering if the password boxes' default values are null instead of empty string, and if that's preventing the header from being populated with the required elements until I edit the contents of a password box. Just a thought.

If anyone can shed some light on any of this, it would be much appreciated.

1 Reply

  • After further testing, I'm leaning towards the null-values-in-the-password-box hypothesis.  I tried it on a new project with the same security system.  This time, in the project's outgoing WS-Security Configurations, I set up a single Usernametoken configuration (see attached) and did not touch the default password box.

    The first time I sent a request, I got the same header problem.  I closed the request, double-clicked in the "default password" box (see attached), and then pressed "enter".

    I then re-opened the request, re-selected the "root" authentication and sent the request.  It worked correctly this time.


    I then tested with a fresh SoapUI project.  This time I double-clicked the "default password" box and hit "enter" as soon as I created the outgoing ws-security configuration.  The request worked correctly the first time I tried it.

    I'm going to file a bug report for this.