Service Virtualization

Expand all | Collapse all

WS-Security Order of Processing the Headers

  • 1.  WS-Security Order of Processing the Headers

    Posted 10-30-2018 09:40 AM

    In the "Virtual HTTPS Listener" Step Filters, I've added the Data Protocol Filter which processes the request for Signature Verification and Timestamp receipt. When i make a request from SoapUI, this works as expected.

     

    In the scenario where the order of Signature and Timestamp is interchanged, the VSM throws and exception as follows

     

    WSDoAllReceiver: security processing failed (actions mismatch) : Message results contains [Signature, Timestamp], but you have configured [Timestamp, Signature]

     

    I need the "Virtual HTTPS Listener" to verify the WS-Headers irrespective of th order in which the Timestamp and Signature are sent in the request.

     

    Any help is highly appreciated. Thank in advance.



  • 2.  Re: WS-Security Order of Processing the Headers

    Broadcom Employee
    Posted 10-30-2018 10:36 AM

    As far as I know, the order matters in the VSM. If you are switching the order then, the request need to be changed accordingly also.



  • 3.  Re: WS-Security Order of Processing the Headers

    Posted 10-30-2018 11:37 AM

    The Live Server accepts the request irrespective of the Order and the team expects the Virtual Service also to behave the same way. Is there a way to achieve this?



  • 4.  Re: WS-Security Order of Processing the Headers

    Broadcom Employee
    Posted 10-30-2018 01:27 PM

    If you can ignore the header information and just use Web Services Soap DPH then that will work.

     

    Another way is to create request arguments from the headers using "Request Data Manager" DPH or "Generic XML Payload Parser" DPH but these will be used in the transaction matching.

     

    If you have further questions, please open a support case.



  • 5.  Re: WS-Security Order of Processing the Headers

    Broadcom Employee
    Posted 10-30-2018 03:34 PM

    Yes, I concur with Prema that it is worthwhile to investigate if you really need the data from the security header to be able to select the correct response for an incoming request. The simplest solutions are always the best.

     

    But in case you cannot go with simplest, some thoughts below:

     

     

       

    •   For this data protocol handler DevTest uses the Apache Foundation implementation of the Oasis Web Service Security specification. And processing the security attributes in order they are defined/expected is important and is defined as such in the Oasis standard. As the Apache Foundation implementation adheres to the Oasis standard I don’t see how development could make it behave differently (but ultimately that is not my call and you can explore that route if you open a support issue).

     

     

       

    •   What intrigues me is that you get requests which can have these different security structures. Code executes always in the same order, so I guess you have 2 different kinds of clients calling this virtual server? Do you have information on the clients? Is it the same component that produces these 2 different WS Security structures? If not then you could think of providing 2 virtual services, basically copies of each other, except for the configuration of the WS Security DPH.

     

     

       

    •   If that doesn’t work then I would try the following.

     

     

     

    Let me first explain that best practice would be to place all your data protocol handlers in the Listen step. This is where they functionally belong where they work on the incoming request object (focusing primarily on the operation and the arguments) and transform that object more and more towards a structure that is similar to the structure of the transactions defined in the virtual service image such that proper matching can take place.

     

     

     

    But a DPH is just a filter, you need to tell it what it needs to filter to do its job – i.e. a lisa.vse.request object – and as such you can add it to a Do Nothing step just as well.

     

     

      1.  Listen step

     

       

    •   Add a scriptable DPH with some code added that tries to figure out the order of the security attributes. Sets a property securityAttributeOrder with either value “Signature-TimeStamp” or with value “TimeStamp-Signature”

       

    •   Add an assertion:

     

    If securityAttributeOrder == “Signature-TimeStamp” then go to 2.a

     

       

    •   Add an assertion:

     

    If securityAttributeOrder == “TimeStamp-Signature” then go to 2.b

     

       

    •   Next: Fail the test

     

    (this should never happen)

     

     

    2.a. Do Nothing step

     

       

    •   Add a WS Security DPH configured with attribute order Signature first, then TimeStamp

     

    Let it filter in {{lisa.vse.request}} (by default it will filter in the .rsp property)

     

       

    •   Add a SOAP DPH

     

    Let it filter in {{lisa.vse.request}} (by default it will filter in the .rsp property)

     

       

    •   Add any other needed DPHs

       

    •   Next: Router Step

     

    2.a. Do Nothing step

     

       

    •   Add a WS Security DPH configured with attribute order TimeStamp first, then Signature

     

    Let it filter in {{lisa.vse.request}} (by default it will filter in the .rsp property)

     

       

    •   Add a SOAP DPH

     

    Let it filter in {{lisa.vse.request}} (by default it will filter in the .rsp property)

     

       

    •   Add any other needed DPHs

       

    •   Next: Router Step

     

    Hope this helps,

     

    Cheers,

    Danny



  • 6.  Re: WS-Security Order of Processing the Headers

    Posted 10-31-2018 01:09 AM

    Thanks you Danny and Prema, for your detailed explanation. I'll look into this and get back if i have any more questions.