How To: Timestamp Validation

When Sentry processes a WS-Security Header, the Timestamps are validated against the system time by default (for instance when verifying a signature). However, certain use cases may require a Timestamp be validated outside of processing a WS-Security Header.

A Timestamp in a request can be validated against either the current system time, or in a number of ways as desired by the specific use case. For example, the requirement may be to validate a Timestamp in the incoming request that it is within certain bounds. For example, the Created Timestamp in the following sample request might need to be 5 minutes or less from the current DateTime:

The above setup will map the Timestamp generated by the function DateTime into a template that can be modified/manipulated to suit the purposes for this setup.

4. Map the Created Timestamp from the Sample Document to a Template

a. Click New to create another Taskb. Select Map Attributes from XML and click Nextc. Type in a name under Task Name to signify the purpose, for example, “Map Created Timestamp to Templated. Select the element Created and click Applye. Paste the following in the TEMPLATE field:{CrY}-{CrMM}-{CrD}T{CrH}:{CrM}:{CrS}Z

5. Create the Document to Present to XSLT for Transformation

a. Click New to create another Taskb. Select Replace Document and click Nextc. In the Drop Down select the document created in step 1.b. above and Save

6. Map DateTime Attributes to Document to Present to XSLT for Transformation

a. Click New to create another Taskb. Select Map Attributes to XML and click Nextc. Select all elements as seen below and click Applyd. Fill in the TEMPLATE fields as appropriate. For example, CrD for Created/day, CuH for Current/Hour, etc…

7. Create a Transform Document Task that Returns the Difference Between Created and Current Timestamp in Seconds

This step requires an XSLT to do the transformation. The XSLT will take the document generate in Step 6 and return as a result the difference between Created and Current Timestamps in seconds.

Please, find the XSLT attached to this article. This XSLT takes the various components making the entire Timestamp as supplied by step 6, converts as appropriate then returns the difference in seconds. This is subtracting Created from Current Timestamps.

a. Click New to create another Taskb. Select Transform Document and click Nextc. Browse to select the XSLT and click Apply first to make sure there are no errors report then click Save

8. Testing before Adding a Validation Task

Note: Running tests will result in errors unless the Created date/time in the sample doc imported as part of the FSG is updated with a date/time in zulu time, as compared to the current date/time. One way to do this is to enable DEBUG mode logging for system logs then run the task once. Check the log to find the current date/time:

Edit the sample doc and change the Created date/time to match. Run the task again and it should now be a few seconds behind the system time which will result in a success.

a. Testing at the Task List Level

At this point the Task List should look as:

Test the setup by clicking Run (highlighted in the above image). Please allow popups to see:

Now edit, as highlighted above, and make changes to the Created Timestamp to run further testing.

b. Create a Task List Group and Add the Task List to it then Associate the Group to a new Content Policy for Testing Purposesc. Send Requests to the new policy as seen below using SOAPSonar, for example:

9. Add a Task to Validate the Result

At this point a Task takes the return and validates that it is within a certain bound. For example, below is a Task that validates that the Created time is within 5 minutes from the Current Time.

a. Click New to add a new Task

b. Select Identify Document and click Next

c. Select Result and click Apply (Result is returned by the XSLT)

d. Set the COMPARATOR to <= and a VALUE of 300

e. Click Save

10. Final Testing

This step is a repeat of step 8 above except that when the difference is greater than 5 minutes (300 seconds) the return to the client is a failure.