SOAP Header on WS-Security response - web-services

Question

Is SOAP Header obligatory on WS-Security Response? If so, why?
I am wondering because my client complains about no SOAP Header in server's response (which in fact is missing), and there is no way to configure it.
I am using a bit obsolete technology (Axis2+Rampart 1.4).
This is security policy:
<wsp:Policy wsu:Id="SigOnly" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:AsymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:TripleDesRsa15/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body/>
</sp:SignedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

Answer 1

Response policy was applied. The problem lied in Rampart's code - it expected the header as defined in WS-Security 1.1, but the server was using WS-Security 1.0, where this header is not obligatory.
It required to shadow org.apache.rampart.util.RampartUtil class
with local one, with redefined isSecHeaderRequired so that it always returns False on incoming messages.
This complies with WS-Security 1.0 standard, which does not say a word wheter the header is required. WS-Security 1.1 requires the header implicitly when a Signature was used (https://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf, chapter 8.5.1)

Answer 2

As Barbara already pointed out. The reason is that the policy applied on client side does not match the one on the server side.
E.g. the tag
<sp:IncludeTimestamp/>
in your policy causes the client to send out the request with a wsse tag in the SOAP header like this
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soapenv:mustUnderstand="true">
....
<wsu:Timestamp wsu:Id="TS-F89FADB76552899AC314938177135681">
<wsu:Created>2017-05-03T13:21:53.566Z</wsu:Created>
<wsu:Expires>2017-05-03T13:26:53.566Z</wsu:Expires>
</wsu:Timestamp>
...
</wsse:UsernameToken>
</wsse:Security>
And by the policy the client expects to receive from the server a <wsu:Timestamp> tag underneath a <wsse> tag in the response so that it can check the timestamp policy on client side. If the server does not produce an answer that matches the policy (e.g. because the server is producing the response SOAP message using a different policy.) then the acceptance of the response fails.
In my case the server was responding with an empty SOAP header (without a <wsse> tag at all). This resulted in the following exception:
org.apache.axis2.AxisFault: Missing wsse:Security header in request
at org.apache.rampart.handler.RampartReceiver.setFaultCodeAndThrowAxisFault(RampartReceiver.java:186)
at org.apache.rampart.handler.RampartReceiver.invoke(RampartReceiver.java:99)
....
Changing the policy on client side to something the server was configured to return did the job.

Answer 3

This may seem obvious, but if you want a client with this policy applied to not throw an exception on the response, yes, the response must contain a Security header in the SOAP message and that header must contain a Timestamp and Signature.
I'm assuming that the request policy is applied on the server since you didn't get a MustUnderstand failure in the response. Are you sure that the response policy is also applied?