Hi Mary, Do you prefer mail from users relating only to rampart to be on this list or > an the axis2-user list? I don't want to impose on a developer's list :-) >
It if it is a Rampart related issue, we prefer to discuss it in the Rampart list. But Axis2 user list has a much more audience and if the question will be helpful to more users, it makes sense to ask them in the axis2 mailing list. 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
