Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Soap Fault: [InvalidSecurity]: An error occurred when verifying security for the message

khanchett
khanchett Posts: 5

I'm new to SOAtest and just trying to get a simple WSDL operation to go to an endpoint and return a response. We require a Basic authentication with a Username and Password, which I provide. I keep getting this error no matter how basic the operation request I use.

I am an avid SoapUI user and these work without a problem. I've compared the SoapUI raw request with the SOAtest request information and everything looks correct. I've even found the system clock can sometimes cause this error, but that didn't work either.

Not sure if rebooting will help, I will try that next although I believe I just came from a reboot. This did run once correctly but I cannot get it to run again.

PLEASE help! As this seems to be such a minor issue, but I'm not able to get any real work done. It's got me dead in the water.

I look forward to any help or suggestions to get this working.

Thanks a lot in advance!

Comments

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    An error occurred when verifying security for the message

    This is a Microsoft error message, typically returned from web services implemented using the .NET WCF web service stack. SOAtest will show the message from the SOAP Fault in the traffic viewer and Quality Task view.

    The actual reason for such errors is generally not returned back to the client for security reasons. In order to determine the actual reason (as opposed to you or I guessing) there should be a way to enable logging on the web service and then check those logs for the answer.

    I've even found the system clock can sometimes cause this error, but that didn't work either.

    I usually see something like this for web services that use WS-Security, where the request has a WS-Security header containing a timestamp. If the timing skew between the timestamp in the message and the server's clock is too great then this would trigger the service to return a security error. .NET WCF services have a "maxClockSkew" property that can be configured in its security configuration.

    We require a Basic authentication with a Username and Password, which I provide

    I'd recommend double checking that. For example, you were thinking system clock may be a factor but Basic Authentication doesn't involve any timestamps being sent in any requests. Maybe the authentication is really sent as something else like Digest or NTLM authentication?

    Something else you can try is by selecting the ".NET WCF HTTP" transport instead of the "HTTP 1.0/1.1" transport. If you provide the SOAP Client with a WSDL for your .NET web service then then SOAP Client will apply the message and transport security to the message automatically when the test is executed, including adding of any WS-Security headers. There are general username and password fields in the settings for the ".NET WCF HTTP" transport.

  • khanchett
    khanchett Posts: 5

    So 2 concerns I have is this:
    1. This did run the first time I opened them, then they wouldn't run again. I'm not sure if this may be due to the "nonce" thing or not?
    2. I can get these tests to run in SmartBear SoapUI with out any issue. If I incur this issue with SoapUI I can go in and "re-assign" the endpoint and autorization to "All Interface Requests and Test Requests". I'm not sure exactly what this is doing in the background. Would you know what this is comparable in SOAtest?

    Hopefully this gives you a little more information to go on than what was previously provided. I appreciate any help you can provide. ;)

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited July 2019

    This did run the first time I opened them, then they wouldn't run again. I'm not sure if this may be due to the "nonce" thing or not?

    How are you configuring the "nonce" in your request? I'm guessing this is in a UsernameToken in your SOAP message. Are you using a hard coded value or is it generated automatically? It needs to be randomly generated each time you send a request. If your UsernameToken also contains a timestamp/created value that needs to be generated each time too. Otherwise the UsernameToken will only work once. The nonce and timestamp are intended to thwart replay attacks.

    As you also mention the skew between the timestamp in the message and the server's clock can't be too great. If the server thinks the message was created in the future or too far in the past then it will reject it.

  • khanchett
    khanchett Posts: 5

    The nonce is automatically handled. I'm not sure if there is some sort of setting that needs to be done to work with it. I feel like the nonce may be the thing because the request worked one time and then didn't after. So the ultimate question is what setting needs to be updated to get this.

    Again, I use the SoapUI software and it works fine, so how they are handling that I'm not sure. I know my settings in SOAtest are correct, just can't find that last setting to get the request to work.

    Thanks again. I feel like this is a newbie issue. It's probably an easy fix that maybe I'm not explaining well.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited July 2019

    So the ultimate question is what setting needs to be updated to get this.

    Please keep in mind that no one can really know the answer here. Without knowing the reason logged by the service we can only guess what the problem is. Ideally you should try to get detail for the server side so that we are not guessing the "nonce" is the issue. Maybe it is or maybe it isn't.

    Without knowing how your test case is configured we can only guess what configuration setting you might have wrong and need to change. If it is the nonce then you will need to explain how that is being configured in your test. I couldn't tell you what to change if I don't know how your test is (mis)configured in the first place.

    If your issue is time sensitive, where you need a resolution right away, then I'd recommend contacting Parasoft Support. They could help look at the problem with you directly.

  • khanchett
    khanchett Posts: 5

    I have a support ticket established. This can be considered CLOSED.

    I do believe I have found the culprit. (Running through some more to make sure it's the true issue)

    It ended up being the SOAP Header needing to add WS-Security to the test. I guess SoapUI automatically grabs this from the WSDL and builds it out. Wasn't aware that we needed to build this before which confuses me that this ran at one time and I never touched these settings. Oh well, lesson learned and now I know to look at this.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited July 2019

    It ended up being the SOAP Header needing to add WS-Security to the test

    OK good. This is why I asked if you were using a UsernameToken. It is a WS-Security SOAP header where you typically have a "nonce" configured. I was asking how you were configuring the "nonce" (Literal view, Form Input, SOAP Headers tab, or somewhere else).

    SoapUI automatically grabs this from the WSDL and builds it out

    SOAtest can configure such things automatically too. Did you see my earlier comment about using the ".NET WCF HTTP" transport? If you do that then you don't actually have to configure the WS-Security header in your test. Instead, the SOAP header will be generated automatically at runtime by the .NET framework based on your WSDL definition.

  • khanchett
    khanchett Posts: 5

    I thought you were talking about the transport username, that is the same. As I recall during training this was all we needed to do, we never had to touch the header.

    Regardless I've learned more and know what to do now. Thanks for all the feedback.!