[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rampart-dev
Subject:    [jira] Updated: (RAMPART-4) RAMPART : Timestamp handling in
From:       "Hans G Knudsen (JIRA)" <jira () apache ! org>
Date:       2007-01-31 11:45:05
Message-ID: 22995001.1170243905586.JavaMail.jira () brutus
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/RAMPART-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Hans G Knudsen updated RAMPART-4:
---------------------------------

    Attachment: fix_timestamp.diff

Hi!

Here is a proposal for fixing the timestamp problem that Rampart allows sender to run \
ahead of receiver.

The fix for PolicyBasedResultsValidator does not allow any timeskew between sender \
and receiver.

Rule for Timestamp :

Timestamp->Created < now/currentTime < Timestamp->Expires.


A comment states :

         * Note: the method verifyTimestamp(Timestamp) allows custom
         * implementations with other validation algorithms for subclasses.

Is this possible ?? PolicyBasedResultsValidator seems to be hardcoded in \
RampartEngine ??



Also included is :
1)
A correction of the RampartConfig.DEFAULT_TIMESTAMP_TTL default value. 

New default value is now 300 (replacing 300.000) as WSS4J WSSecTimestamp/Timestamp \
multiplies with 1000

300 is also the default value of WSSecTimestamp


2)
Fix for RampartConfigBuilder.java so that timestampTTL can now be defined in \
configuration of Rampart. (Transfer of value was missing) 


/hans


> RAMPART : Timestamp handling in PolicyBasedResultsValidator when 'NOW' is before \
>                 Timestamp->Created
> ---------------------------------------------------------------------------------------------------
>  
> Key: RAMPART-4
> URL: https://issues.apache.org/jira/browse/RAMPART-4
> Project: Rampart
> Issue Type: Bug
> Environment: Java 5 (1.5.0_06) on Apple OS X 10.4.8
> Reporter: Hans G Knudsen
> Assigned To: Ruchith Udayanga Fernando
> Attachments: fix_timestamp.diff
> 
> 
> Hi
> Interop testing against a MS .Net/WCF receiver we get an SoapFault/SecurityError if \
> we have a timeskew and 'NOW' is before Timestamp->Created generated on the sender. \
> On MS .Net/WCF currentTime/NOW must be > Timestamp->Created and < \
> Timestamp-Expired.  On Axis NOW before a received Timestamp->Created is accecpted.
> In Axis Timestamp->Expires is validated in WSS4J TimestampProcessor and is very \
> strict (and must be) The Timestamp->Created is handled by RAMPART \
> PolicyBasedResultsValidator - and with the sender being 10 minuttes ahead of \
> receiver the values of the different vars eg. could be : ts created   : \
> 2007-01-18T10:20:20.626Z ts expires   : 2007-01-18T10:25:20.626Z
> currentTime  : 2007-01-18T10:10:20.904Z
> validcreation: 2007-01-18T10:05:20.904Z
> and the timestamp is accepted as validCreation is before ts->created.
> This behaviour could (depening on skew) result in a timestamp-error on a server \
> response as Timestamp->Expires could be before NOW. With the 10 min skew and the \
> time from above ts->expires would be around 10:15 on response and NOW on receiver \
> would be around 10:20. Is the Axis/RAMPART timestamp valiation correct ??
> A more strict validation of would be more usefull/practically for (at least) us.
> A timestamp handling alowing sender to be a 10th (30 seconds on default 300) of ttl \
> ahead could look like ( setting fraction value to 1 would give current behaviour) : \
>  long created = timestamp.getCreated().getTimeInMillis();
> int skewFraction = 10;
> Calendar creationTimeWithAllowedSkew = Calendar.getInstance();
> creationTimeWithAllowedSkew.setTime( new Date( created - (timeToLive/skewFraction) \
> * 1000 ) );  
> if( creationTimeWithAllowedSkew.after( currentTime ) ) {
> return false;
> } 
> Would accept a 30 second timeskew :
> ts created  : 2007-01-18T10:10:50.869Z
> ts expires  : 2007-01-18T10:15:50.869Z
> currentTime : 2007-01-18T10:10:41.161Z
> cre w. skew : 2007-01-18T10:10:20.869Z
> If a diff is needed - should it be againt Axis/RAMPART - \
> axis2/tags/java/rampart_1_1 rev 482298 ?? regards
> /hans

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[prev in list] [next in list] [prev in thread] [next in thread]