[jira] Moved: (RAMPART-4) RAMPART : Timestamp handling in PolicyBasedResultsValidator when 'NOW' is before Timestamp->Created

["Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org>]

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

Ruchith Udayanga Fernando moved RAMPART-3 to RAMPART-4:
-------------------------------------------------------

        Key: RAMPART-4  (was: RAMPART-3)
    Project: Rampart  (was: Axis 2.0 (Axis2))

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