Nandana,
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.
I've have subscribed to the rampart-dev mailing list, so I should see
your commit message.
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 :-)
Thanks, Mary
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.
