Timestamp validation fails! Why?

This explains the common issues in wsse:Timestamp validation and the possible fixes.

Date: Mon, 30th Jul, 2007
Level: Intermidiate
Reads: 3566 Comments: 0 | Login or register to post comments
Ruchith Fernando
Software Engineer
WSO2 Inc.

We usually develop and test secure Web services applications in one machine. Then, when we actually test this application with a remote client, some of the initial issues we run into are timestamp validation issues. This is mainly due to the clocks of the two machines not being in sync. In real life scenarios, we certainly cannot expect clocks to be in sync. You can synchronize clocks across machines automatically with tools that use Network Time Protocol.

Apache Rampart/Java introduces a new configuration assertion to allow time differences between communicating hosts.

<timestampMaxSkew>value<timestampMaxSkew>

The "value" must be the allowed time skew in seconds and must be specified as an integer. By default Apache Rampart/Java tolarates a maximum time skew of five (5) minutes (300 seconds).

The <timestampMaxSkew> assertion must be placed within the <RampartConfig> assertion as an immediate child element.

 

Applies To

1. Apache Rampart/Java

 

 

Hot Topic
Hot
Topic

Google Gadgets are a nice way to develop user interfaces for distributed services. The fact that they can be hosted anywhere over a network, not necessarily in the very portal server they eventually run in makes them re-usable and allows users to quickly...

Mini Banners
WSO2Con 2010
Latest Webinar
In this webinar we'll share the range of concerns we've heard from the industry, and survey some of the new and sometimes subtle types of lock-in associated with cloud technologies.
Wednesday, 8 September, 10.00 AM (PDT)