Introduction

SAML assertions issued by the Identity Provider (IdP) have a limited validity window defined by the NotBefore and NotOnOrAfter conditions. If the Service Provider (SP) receives the assertion after the NotOnOrAfter time, it rejects the assertion as expired. This can happen due to clock skew between the IdP and SP, network delays, or overly short assertion validity periods.

Symptoms

  • SAML login fails with Assertion expired or Invalid assertion error
  • SP logs show SAML response rejected: assertion is no longer valid
  • User is authenticated at the IdP but rejected by the application
  • Error correlates with high network latency or SP processing delays
  • Error message: SAMLResponse rejected: Condition 'NotOnOrAfter' has passed

Common Causes

  • Clock skew between the IdP server and the SP server (time not synchronized)
  • Assertion validity period set too short (e.g., 30 seconds)
  • Network latency delaying the SAML response delivery
  • SP processing delay -- application takes too long to validate the assertion
  • IdP server time drifting ahead of the SP server time

Step-by-Step Fix

  1. 1.Check clock synchronization between IdP and SP: Verify NTP is working.
  2. 2.```bash
  3. 3.# On both IdP and SP servers
  4. 4.ntpq -p
  5. 5.# Or check chrony
  6. 6.chronyc tracking
  7. 7.# Both servers should be within 30 seconds of each other
  8. 8.`
  9. 9.Increase the assertion validity period on the IdP: Allow more processing time.
  10. 10.`
  11. 11.# In the IdP configuration (e.g., ADFS, Okta, Keycloak):
  12. 12.# Set SAML assertion lifetime to at least 300 seconds (5 minutes)
  13. 13.# ADFS: AD FS Management > Service > set TokenLifetime to 5
  14. 14.# Keycloak: Client Settings > Assertion Lifespan = 300
  15. 15.`
  16. 16.Configure clock skew tolerance on the SP: Allow for time differences.
  17. 17.```xml
  18. 18.<!-- In the SP SAML configuration -->
  19. 19.<saml:Conditions NotBefore="..." NotOnOrAfter="...">
  20. 20.<!-- SP should allow a clock skew tolerance -->
  21. 21.</saml:Conditions>
  22. 22.<!-- Most SAML libraries support a clockSkew setting -->
  23. 23.`
  24. 24.Enable clock skew tolerance in the SAML library: Configure the application.
  25. 25.```java
  26. 26.// Spring Security SAML example
  27. 27.OpenSAMLWrapper samlWrapper = new OpenSAMLWrapper();
  28. 28.samlWrapper.setResponseSkew(300); // 5 minutes tolerance
  29. 29.`
  30. 30.Verify SAML authentication succeeds after the fix: Test the end-to-end flow.
  31. 31.`
  32. 32.# Trigger SAML login
  33. 33.# Check SP logs for successful assertion validation
  34. 34.# Verify the user is authenticated and can access the application
  35. 35.`

Prevention

  • Synchronize all IdP and SP servers with the same NTP source
  • Set SAML assertion validity period to at least 300 seconds
  • Configure clock skew tolerance of 2-5 minutes on the SP side
  • Monitor SAML authentication failure rates and correlate with assertion expiry
  • Test SAML integration after any time synchronization or NTP configuration changes
  • Use SAML monitoring tools to track assertion validity and processing times