[
https://issues.apache.org/jira/browse/AXIS2-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466300
]
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 times.
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.
Thanks,
Ruchith
> RAMPART : Timestamp handling in PolicyBasedResultsValidator when 'NOW' is
> before Timestamp->Created
> ---------------------------------------------------------------------------------------------------
>
> Key: AXIS2-1997
> URL: https://issues.apache.org/jira/browse/AXIS2-1997
> 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:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
