On Demand Consulting
Author: Volodymyr Sitarchuk

Example of the exception
"AxisEngine E org.apache.axis2.engine.AxisEngine receive the timestamp is invalid, creation of timestamp - 2016-08-31T17:05:30.416Z too far in future"
thrown
when calling a Web Service from "Web Service Integration" component.

The reason for the exception is the un-sync of system time between servers - between Web Service producer and consumer

It can happen if the SOAP response contains a security header like :
<soapenv:Header>
      <o:Security  soapenv:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <u:Timestamp u:Id="_0">
                  <u:Created>2016-08-31T17:05:30.416Z </u:Created>
            </u:Timestamp>
      </o:Security>
</soapenv:Header>
and the security timestamp is bigger than the current time on BPM server

See
http://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.messages.doc/com.ibm.ws.wssecurity.resources.wssmessages.html
The time stamp value occurs too far into the future.
Explanation  The clocks on the client and server might not be synchronized.
Action   Ensure that the date time and time zone are synchronized for both the client and the server.



There are three possible solutions:

1
If the fix JR57235 (ADDING SWITCH FOR WEB SERVICE SECURITY HEADER TIMESTAMP CHECKING) is installed to your BPM env

then you can disable the security header timestamp checking
http://www-01.ibm.com/support/docview.wss?uid=swg1JR57235
you can configure a switch by
adding system property with the name
"com.ibm.bpm.ws.inbound.timestamp.checking.disable" and value set to "true"




2
http://www-01.ibm.com/support/docview.wss?uid=swg1JR57235
-Synchronize the server and client clocks so that their timestamps are in sync.

So the solution is to synchronize the system datetimes
but note that the issue can be even caused by a millisecond difference.


3
http://www-01.ibm.com/support/docview.wss?uid=swg1JR57235
-Switch the security and policy from Use Basic Security to Use Policy Set in the IBM BPM web service or web service integration.

An alternative solution could be to use WebSphere Security Policy feature.
The case is that if "Use Basic Security" option is used in "Web Service Integration" component
then the legacy/default Security Policy is used for checking the timestamp and this check is strict: now_timestamp >= soap_reponse_timestamp
You may set the "Use Policy Set" instead of the "Use Basic Security" option and use your customized Security Policy
that can be created in the "WAS console/Services/Policy sets/Application policy sets" and "WAS console/Services/Policy sets/client policy set bindings"
where you can specify a custom property  com.ibm.wsspi.wssecurity.core.TimestampClockSkew to make the timestamp checking be lax(less strict).

1. Create a Security Policy Set



2. Add the WS-Security to the Policy Set



and make sure that
the "Include timestamp in security header" checkbox is switched on
otherwise you can get such an exception :
"org.apache.axis2.engine.AxisEngine receive Must Understand check failed for header http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd : Security"






3. Create a Policy Set bindings



4. Add the WS-Security to the Policy Set bindings and specify the custom property  com.ibm.wsspi.wssecurity.core.TimestampClockSkew
Note if you need more than 300 seconds then you will have to also add the com.ibm.wsspi.wssecurity.core.TimestampMaxAge and the com.ibm.wsspi.wssecurity.core.TimestampTimeout
The full list of properties:
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/rwbs_customproperties.html#rwbs_customproperties__com.ibm.wsspi.wssecurity.core.TimestampClockSkew





5. Set the created policies in Web Service