Hi Mary, Thanks for the reply. I was rather surprised that such a bug in what I > think is a common security protocol wouldn't have been caught sooner. I was > wondering if it was not always reproducible. >
Yeah, it is too bad that we didn't catch this any sooner. I think we might even have to think a minor release with this fix included. And we need to strengthen the test suites in Rampart. Any help from the community will be highly appreciated. thanks, nandana > Nandana Mihindukulasooriya (JIRA) wrote: > >> [ >> https://issues.apache.org/jira/browse/RAMPART-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636004#action_12636004] >> Nandana Mihindukulasooriya commented on RAMPART-183: >> ---------------------------------------------------- >> >> Hi Mary, >> Yeah, there is a bug in validation. Thanks for pointing out. Will fix >> this asap and commit to the trunk. >> thanks, >> nandana >> >>> Rampart not correctly enforcing Signature validity if other security >>> elements exist (ie - Timestamp) >>> >>> ---------------------------------------------------------------------------------------------------- >>> >>> Key: RAMPART-183 >>> URL: https://issues.apache.org/jira/browse/RAMPART-183 >>> Project: Rampart >>> Issue Type: Bug >>> Components: rampart-core >>> Affects Versions: 1.3 >>> Environment: IBM Rational Application Developer, Websphere 6.0 >>> runtime on Windows XP, Unix >>> Reporter: Wally Dennis >>> Assignee: Nandana Mihindukulasooriya >>> >>> It appears as though Rampart/WSS4J is not enforcing the <InflowSecurity> >>> settings that I have in my services.xml file. Here are the settings as I >>> have them configured: >>> <parameter name="InflowSecurity"> >>> <action> >>> <items>Timestamp Signature</items> >>> >>> <signaturePropFile>config/base/configuration.properties</signaturePropFile> >>> </action> >>> </parameter> >>> I discovered this issue during my testing - my test client is sending in >>> a SOAP request that contains a Timestamp but not a Signature. This results >>> in the creation of the <wsse:Security> element in the SOAP header that >>> contains only the <wsu:Timestamp> child as shown here: >>> <wsse:Security xmlns:wsse=" >>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; >>> soapenv:mustUnderstand="1"> >>> <wsu:Timestamp xmlns:wsu=" >>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; >>> wsu:Id="Timestamp-724480920"> >>> <wsu:Created>2008-07-08T13:49:08.433Z</wsu:Created> >>> <wsu:Expires>2008-07-08T13:54:08.433Z</wsu:Expires> >>> </wsu:Timestamp> >>> </wsse:Security> >>> In Rampart's WSDoAllReciever class, I can see were it is decoding the >>> actions configured, but these actions are not then passed into the >>> WSSecurityEngine to indicate which items should be validated. Therefore, >>> the WSSecurityEngine and subsequent classes simply use the elements in the >>> <wsse:Security> header to determine what to validate. This results in the >>> timestamp being validated correctly, but it does not throw an error due to >>> the lack of the <ds:Signature> element. >>> One additional thing - in debugging through this, I do see where the >>> enableSignatureConfirmation variable in WSSConfig is set to true, so this >>> may be an issue with WSS4J. If I need to submit this report under WSS4J I >>> will. >>> Thanks. >>> >> >> > -- Nandana Mihindukulasooriya WSO2 inc. http://nandana83.blogspot.com/ http://www.wso2.org
