[SWS-524] Wss4j security header validation: make header elements check overriddable Created: 08/Jun/09 Updated: 04/May/12 Resolved: 17/Aug/09
|Project:||Spring Web Services|
|Reporter:||Nicholas Blair||Assignee:||Tareq Abedrabbo|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
My application uses a org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor with validationActions set simply to "UsernameToken" (additionally using SpringPlainTextPasswordValidationCallbackHandler as the validationCallbackHandler, but has no effect on the problem).
If a web service client sends a request and inside the WS-Security header they include the UsernameToken AND some other element (e.g. Timestamp, like WCF clients do), the validateMessage method always throws a Wss4jSecurityValidationException (line 509, with message of "Security processing failed (actions mismatch)").
On the preceding line is:
This is a reference to org.springframework.ws.soap.security.wss4j.Wss4JHandler - the implementation of which simply calls the super's (wss4j's WSHandler) checkReceiverResults.
If the size of the 2 vectors passed into org.apache.ws.security.handler.WSHandler#checkReceiverResults are different, the method always returns false, regardless of the status of each WSSecurityEngineResult (see line 291 - "if (ai >= size" is false, triggering the return false).
With this example configuration, and a properly formatted request that contains both UsernameToken and Timestamp, in this case those 2 vectors passed into that method have different sizes, as the prior call to securityEngine.processHeader returned the Vector named "results" which has 2 results.
The question is: where is the bug?
1. Does the WS-Security specification say that if you have more elements in the header than the endpoint expects, a soap fault should be raised?
It seems to me that the Timestamp (in my example case) is superfluous and likely can be ignored (unless the security specification says otherwise).
|Comment by Nicholas Blair [ 08/Jun/09 ]|
Line 291 in org.apache.ws.security.handler.WSHandler#checkReceiverResults doesn't fail in the first term of the if block ("ai>= size"), I think it is silently failing in the second term:
((Integer) actions.get(ai++)).intValue() != act
On the second iteration of the loop, ai is set to 1. The actions vector has size == 1.
|Comment by Tareq Abedrabbo [ 08/Jun/09 ]|
The WSHandler.checkReceiverResults is very strict in checking the existence and the order of the security headers. I believe XWSS has a similar behavior too (an unexpected security header results in an exception).
The somehow weird implementation of checkReceiverResults accounts for checking the existence and the order of the security elements, while ignoring the Signature Confirmation action (if any).
The good news is that Wss4j 1.5.8 is going to introduce an option that relaxes header verification (at least the order of elements, not sure yet what happens if there are more elements than expected). We've already planned to integrate this feature in the next release.
|Comment by Tareq Abedrabbo [ 08/Jun/09 ]|
I'm thinking that in order to allow custom header validation behavior, we could encapsulate that in a protected method (lines 508 - 510), just as we did for the other steps. What do you think Arjen?
|Comment by Nicholas Blair [ 10/Jun/09 ]|
If you provided an extension point along the lines of:
1. replace lines 508-510 with some non-final method that passes in the results and validationActionsVector. If you don't pass the validationActionsVector in, perhaps expose the validation actions with a getter?
2. default implementation of this new method simply does:
I could override the method in a subclass to trim the non-matching elements in the results vector and invoke the super.
|Comment by Tareq Abedrabbo [ 17/Aug/09 ]|
I changed the summary and type to reflect the issue better. I'll add a protected void checkResults(Vector results, Vector validationActionsVector) method to enable custom validation behavior.
|Comment by Mona [ 22/Jan/10 ]|
We are using spring webservice (1.5.7) as a client. It gives "Security processing failed (actions mismatch)" error on following message from provider (with timestamp)... we tried upgrading to 1.5.8 which did not work. Any comment?
|Comment by Arjen Poutsma [ 04/May/12 ]|
Closing old issues