[
https://issues.apache.org/jira/browse/RAMPART-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilina Buddhika resolved RAMPART-183.
--------------------------------------
Resolution: Fixed
Fix Version/s: 1.6.0
This has already been fixed, most probably with WSS4J 1.5.4 release as Colm
mentioned.
I verified it in the latest trunk using the basic sample04.
> 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: Thilina Buddhika
> Fix For: 1.6.0
>
>
> 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
