Handling Time Differences when using Validity Periods in a SAML Assertion
A SAML assertion can contain conditions limiting the validity period of a request. (This provides an additional precaution against identity theft.)
When a validity period is defined, if the clocks on the client system and the BPM runtime are not synchronized, you must ensure that time differences between the two systems do not cause authentication failures due to the unexpected expiry of an assertion’s validity period.
For example, suppose a client application is attempting to invoke a service on a BPM runtime. The client application generates a SAML assertion containing the following condition:
<saml:Conditions NotBefore="2011-09-01T14:25:54.622Z" NotOnOrAfter="2011-09-01T14:35:54.622Z" />
where the NotBefore condition is set to the clock time on the client system. However, the BPM runtime’s clock has not yet reached this time, and it therefore rejects the call because the assertion is invalid.
The methods used to handle this depend on which API the client application is using to invoke BPM runtime services:
- Web Service API - The client application generates (or obtains) the SAML assertion, so can control what timestamp it puts in the NotBefore and NotOnOrAfter fields in the assertion (or indeed if it uses them at all).
- Java Service Connector API - The SAMLSenderVouchesSecurityHandler generates the SAML assertion. Optional parameters can be defined to define and insert a validity period. (By default, no validity period is set.) See Using the Service Connector SamlSenderVouchesSecurityHandler Method for more information.
Whichever API it uses, the client application must ensure that any validity period used in the SAML assertion will be valid when the request is authenticated by the BPM runtime.