axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruchith Udayanga Fernando (JIRA)" <>
Subject [jira] Commented: (AXIS2-1997) RAMPART : Timestamp handling in PolicyBasedResultsValidator when 'NOW' is before Timestamp->Created
Date Sun, 21 Jan 2007 05:48:30 GMT


Ruchith Udayanga Fernando commented on AXIS2-1997:

Hi Hans,

Do we really need to allow for a time skew? IMHO the two nodes have to have their time set
properly. Most of the time during interop testing we had to adjust our clocks to the standard

But I guess we can provide a switch where IFF a timeskew is specified in the RampartConfig
assertion the timestamp validation will take it into consideration.

It'll be great if you can provide a patch. Right now we are in the process of moving rampart
out into  new location will ping the list as soon as it is complete. Then you can create the
patch against the new codebase.


> RAMPART : Timestamp handling in PolicyBasedResultsValidator when 'NOW' is before Timestamp->Created
> ---------------------------------------------------------------------------------------------------
>                 Key: AXIS2-1997
>                 URL:
>             Project: Apache Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: modules
>         Environment: Java 5 (1.5.0_06) on Apple OS X 10.4.8
>            Reporter: Hans G Knuden
> 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.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message