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: Ruchith Udayanga Fernando
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.
