[SWS-524] Wss4j security header validation: make header elements check overriddable Created: 08/Jun/09  Updated: 04/May/12  Resolved: 17/Aug/09

Status: Closed
Project: Spring Web Services
Component/s: Security
Affects Version/s: 1.5.7
Fix Version/s: 1.5.8

Type: Improvement Priority: Minor
Reporter: Nicholas Blair Assignee: Tareq Abedrabbo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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:
if(!handler.checkReceiverResults(results, validationActionsVector)) {

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?
2. If that's not the case, should wss4j be returning false for checkReceiverResults if the input Vectors have different sizes?
3. If wss4j is doing what it's supposed to, should the spring-ws Wss4JHandler or Wss4jSecurityInterceptor remove results from the result of securityEngine.processHeader that aren't specified in the validationActions property?

It seems to me that the Timestamp (in my example case) is superfluous and likely can be ignored (unless the security specification says otherwise).



 Comments   
Comment by Nicholas Blair [ 08/Jun/09 ]

correction:

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.
The actions vector doesn't have a second element (index 1), although no ArrayIndexOutOfBoundException is thrown (as described in Vector#get(int)'s javadoc).

Comment by Tareq Abedrabbo [ 08/Jun/09 ]

Hi Nicholas,

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.

Tareq

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:
if (!handler.checkReceiverResults(results, validationActionsVector)) {
throw new Wss4jSecurityValidationException("Security processing failed (actions mismatch)");
}

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?

//MSG....
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsu:Timestamp
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2010-01-22T16:22:20.71Z
</wsu:Created>
</wsu:Timestamp>
<wsse:BinarySecurityToken wsu:Id="x509bst_15"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
//MSG....

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Sat Dec 16 15:03:08 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.