CA API Gateway 9.1

9.4 9.1

Require Timestamp Assertion

The Require Timestamp assertion is used to enforce the presence of a timestamp in the target message. When this assertion is added to a policy, the  will check that the timestamps adhere to all of the following conditions (all time comparisons are against the time):
gateway83
The 
Require Timestamp 
assertion is used to enforce the presence of a timestamp in the target message. When this assertion is added to a policy, the
API Gateway
 will check that the timestamps adhere to all of the following conditions (all time comparisons are against the
API Gateway
 time):
  • The SOAP header in the target message contains a valid 
    <wsu:Timestamp>
     element.
  • If a created date is present in the timestamp, the date is no more than one minute in the future.
  • An expiry date is present in the timestamp and that date is no more than one minute in the past.
  • An expiry time is present in the timestamp and the current time of the
    API Gateway
     is no later than the 
    <wsu:Created>
     time + the Maximum Expiry Time configured in this assertion or the request SOAP 
    <wsu:Expires>
     time, whichever occurs earlier.
You can optionally specify that a security signature be required for all timestamps.
To learn about selecting the target message for this assertion, see Select a Target Message.
To learn more about selecting the target identity for this assertion, see Select a Target Identity.
To learn more about changing the WSS Recipient for this assertion, see Change the WSS Assertion Recipient.
(1) Timestamps in a request message, even if invalid or expired, are not checked unless the Require Timestamp assertion is present in a policy. 2) This assertion does not override the duration of the timestamp in the message—it simply allows a timestamp to be longer than the default 5 minutes allowed by the Require WS-Security Signature Credentials assertion. If the
API Gateway
 -XML VPN Client is used to add WSS headers to the message, the timestamp duration will always be 5 minutes, regardless of what other timestamp assertions are used.
Using the Assertion
  1. Do one of the following:
    • To add the assertion to the Policy Development window, see Add an Assertion.
    • To change the configuration of an existing assertion, proceed to step 2 below.
    This assertion can be used immediately. Further configuration is not necessary unless you want to change the default settings. (Note the positioning of this assertion in the policy if you use the default setting of "Require Signature".)
  2. To change the settings, right-click 
    <target>:
     Require [Signed] Timestamp 
    in the policy window and select 
    Timestamp Properties
     or double-click the assertion in the policy window. The assertion properties are displayed. 
  3. Configure the properties as follows:
    Setting
    Description
    Target Message
    Select the message to check for a timestamp:
    • Request:
       The request message will be checked.
    • Response:
       The response message will be checked.
    • Other Context Variable:
       A context variable will be checked. This context variable must be of type "message" and must be predefined or has been set in the policy prior to the Require Timestamp assertion. For more information on Message variables, see Context Variables.
    Maximum Expiry Time
    Select the unit of measure from the drop-down list (milliseconds, seconds, minutes, hours), then enter the maximum permitted expiry time. Fractional measurements are permitted. An expiry time of '0' (zero) means the request expires immediately. The default is 60 minutes, with a one minute grace period.
    Require Signature
    Select this check box to require that the timestamp be digitally signed. This setting is the default.
    If a signature is required, one of the following assertions must appear
    before
     the Require Timestamp assertion in the policy:
    • Require WS-Security Signature Credentials
    • Require WS-Security Kerberos Token Profile Credentials
    • Require WS-Secure Conversation
    • Require Encrypted UsernameToken Profile Credentials
    • Require SAML Token Profile (using the "Holder-of-Key" subject confirmation method, with Require Message Signature enabled, in step 6 of the SAML Token Profile Wizard).
  4. Click [
    OK
    ]when done.

Content feedback and comments