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