Hey all
Hopefully someone has encountered this. Since upgrading to Axis2
1.6.2/Rampart 1.6.2 we have been having a problem with timestamp validation
(on the client side). We are using WSDL2Java to generate a stub and using
that to call the web service. We upgraded from 1.5.3, where we had no
problem.
The issue is that the clock on the web service side seems to be a couple of
minutes ahead. The timestamp then fails validation due to a default 60
second futureTimeToLive. I traced through the source, and this is
happening in org.apache.ws.security.message.token.Timestamp.verifyCreated -
the check code is below.
if (futureTimeToLive > 0) {
validCreation.setTime(currentTime + ((long)futureTimeToLive * 1000L));
}
// Check to see if the created time is in the future
if (createdDate != null && createdDate.after(validCreation)) {
...
return false;
}
So this is fair enough I thought - I just need to increase futureTimeToLive
from the default 60. However I have been unable to do this.
I have tried using setProperty(WSHandlerConstants.TTL_FUTURE_TIMESTAMP,
"value here") on the service client options. I wasn't surprised that this
didn't work.
I next tried setting timestampMaxSkew on the RampartConfig. I thought this
might work. I can see it in the RampartMessageData when I trace the code,
but as soon it swaps over to using the Wss4j stuff
(org.apache.ws.security.handler.RequestData), the WSSConfig values are all
default.
So I may be missing the obvious, but does anyone know how to set the
timeStampFutureTTL value in the WSSConfig to enable future Created dates to
get through?
I should mention this is all being done dynamically through code.
Thanks in advance. I have spent a lot of time on what is essentially a
simple client :)
Matt
