Page Comparison

...

The following are the rampart configuration parameters that allows you to configure and control Timestamp handling in Rampart and WSS4J (applies to Rampart 1.6.2 or above).

<rampart:rampartconfig xmlns:rampart="http://ws.apache.org/rampart/policy">  
      ...  
      <rampart:timestampprecisioninmilliseconds>true  
      </rampart:timestampprecisioninmilliseconds>  
      <rampart:timestampttl>300</rampart:timestampttl>  
      <rampart:timestampmaxskew>300</rampart:timestampmaxskew>  
      <rampart:timestampstrict>false</rampart:timestampstrict>  
      ...  
</rampart:rampartconfig>

• timestampprecisioninmilliseconds: This decides whether the precision of the timestamp reference is in milliseconds. This is a configuration parameter passed to WSS4J, when creating WSSConfig.
• timestampttl: This is the validity period of the message as decided by the sender of the message. This is used in Rampart level to calculate the "expires" time reference. Default value is 300 seconds.
• timestampmaxskew: Specifies the maximum tolerance limit for the clock skewed between the sender and recipient. As specified by the WS-Security specification, it should be taken into consideration that the sender and recipient may not have synchronized clocks and proper measures should be taken to avoid it. This is a rampart level configuration parameter and the default value is 300 seconds.
• timestampstrict: This instructs rampart whether to enable timestamp validation at WSS4J level or not. This is set to false by default. Timestamp validation happens in PolicyBasedResultsValidator of Rampart.

How Timestamp is created

RampartSender is the handler introduced by Rampart for security processing of the outflow of Axis2. In the process of securing the outgoing message according to the defined security policy, BindingBuilder adds the Timestamp element to the security header.

The following is how 'created' and 'expires' time references of Timestamp are derived:

• created = current time
• expires = created(in millis) + timestampttl*1000

How Timestamp is validated

RampartReceiver is the handler introduced by Rampart for security processing of the inflow of Axis2. In the process of validating the security of the incoming message, both WSSecurityEngine (in WSS4J) and PolicyBasedResultsValidator (in Rampart) validates Timestamp in the security header. WSS4J only checks whether the 'expires' time reference is before the current time of the receiver, to validate timestamp.

Rampart verifies the timestamp taking timestampmaxskew also into consideration and validates against both 'created' and 'expires' time references.

Timestamp is invalid if:

• current time < [created - (timestampmaxskew*1000)] (in millis)
• current time > [created + (timestampmaxskew*1000)] (in millis)

Because of the consistent way timestamp is verified in Rampart level considering both created and expires, the validation at the WSS4J is disabled by default with timestampstrict set to false.

Other ways to avoid replay attacks:

According to the above logic of validating Timestamp, it is considered valid during the time period:

from (created - timestampskew) to (expires + timestampskew)

This means replay attacks made during that period are not detected if any other mechanism is not adopted to detect and avoid replay attacks.

Some other mechanisms to avoid replay attacks are:

• Using session keys
• Using one time passwords
• Using nonce value