RE: Created date validation issues in service client with future times - Axis2 1.6.2, Rampart 1.6.2

Hi Matt-

instead of setting final attributes of final class org.apache.ws.security.handler.WSHandlerConstants via WSS4J

what happens if you set org.apache.axis2.Constants TIMOUT attribute such as 
serviceStub._getServiceClient().getOptions().setProperty(
                Constants.Configuration.CONFIG_CONTEXT_TIMOUT_INTERVAL, "60");

in your Axis Client code?

Martin 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.


Date: Thu, 16 Aug 2012 18:53:24 +1000
Subject: Created date validation issues in service client with future times - Axis2 1.6.2, Rampart 1.6.2
From: [email protected]
To: [email protected]

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