You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by "LEE (JIRA)" <ji...@apache.org> on 2009/05/22 11:21:45 UTC

[jira] Commented: (RAMPART-183) Rampart not correctly enforcing Signature validity if other security elements exist (ie - Timestamp)

    [ https://issues.apache.org/jira/browse/RAMPART-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712001#action_12712001 ] 

LEE commented on RAMPART-183:
-----------------------------

Hi,

We are experiencing the same problem i.e. we specify Timestamp Signature in the <InflowSecurity> of services.xml  and yet only specifying Timestamp in the client still results in a successful response.

Any ideas of when this is likely to be resolved?

> 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.