[
https://issues.apache.org/jira/browse/RAMPART-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712016#action_12712016
]
Colm O hEigeartaigh commented on RAMPART-183:
---------------------------------------------
I believe this was a bug in WSS4J that I fixed in the 1.5.4 release:
https://issues.apache.org/jira/browse/WSS-70
What version of WSS4J are you using?
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
