In the very first version of WSS4J this was built in as a verification measure. The receiver processes the request in the opposite direction than the sender.
For example: <Timestamp UsernameToken> The sender sets up the request by adding a Timestamp first, then the username token. The receiver first reads the username token, then the timestamp. The processors (in the first version) added (actually appended) the results to a list (vector), the verification funtion reversed this list and checked it against the actions. Doing this enabled the user to have the same action order at the sender and receiver side. During the introduction of the new processors somehow the actions were prepended to the list but it seems the verification was not modified and reversed the list Regards, Werner > -----Original Message----- > From: ext Colm O hEigeartaigh (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Monday, December 08, 2008 12:21 PM > To: [email protected] > Subject: [jira] Commented: (WSS-147) WCF interop issue: > Security header ordering constraint > > > [ > https://issues.apache.org/jira/browse/WSS-147?page=com.atlassi an.jira.plugin.system.issuetabpanels:comment-> tabpanel&focusedCommentId=12654373#action_12654373 ] > > Colm O hEigeartaigh commented on WSS-147: > ----------------------------------------- > > > A definite bug methinks. Does anyone have an idea why the > processors append all of the results to the list? > > > WCF interop issue: Security header ordering constraint > > ------------------------------------------------------ > > > > Key: WSS-147 > > URL: https://issues.apache.org/jira/browse/WSS-147 > > Project: WSS4J > > Issue Type: Bug > > Components: WSS4J Handlers > > Environment: Windows XP, Java 1.5, CXF 2.1.2, .Net 3.5 > > Reporter: Aditya Sawhney > > Assignee: Colm O hEigeartaigh > > > > I have WCF Client which uses WS-Security UsernameToken > profile. WCF also automatically adds a TimeStamp header which > comes before the UsernameToken header in the Security header. > > If I try to call a CXF web service using CXF exposed from > a Java container then "Security header cannot be authorized" > exception is thrown. > > The reason is that WSHandler::checkReceiverResults returns > false. WSS4J excepts the security header contents to be in a > particular oder in which Timestamp should come after > UsernameToken but in this case it is the opposite and the > validation fails. The WS-Security spec doesnt specify this > ordering constraint and seems to have been self-imposed by > WSS4J which is incorrect and needs to be fixed for the > interop to work as desired. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
