Authentication fails with error SAML2ValidationError: The assertion is valid in the future, 2020-02-19T06: 43: 27.464-08: 00, notBefore: 2020-02-19T14: 44: 28.106ZDescriptionUser Authentication will fail since we are not able to validate the SAML assertion with error SAML2ValidationError: The assertion is valid in the future, 2020-02-19T06: 43: 27.464-08: 00, notBefore: 2020-02-19T14: 44: 28.106ZRelease or EnvironmentAllCauseIn SAML Response we receive the attribute with "<saml:SubjectConfirmationData" and it does contain "NotOnOrAfter" with date which means NotOnOrAfter is a time instant at which the subject can no longer be confirmed. At the same time in the same SAMLResponse we receive attribute "<saml:Conditions NotBefore="<date and Time stamp>" NotOnOrAfter="<Date and Time stamo"> Example how it looks like is "<saml:Conditions NotBefore="2014-07-17T01:01:18Z" NotOnOrAfter="2014-07-18T06:21:48Z">" so from above conditions NotBefore Specifies the earliest time instant at which the assertion is valid and NotOnOrAfter Specifies the time instant at which the assertion has expired. Consider below Scenario from the picture As shown in the above image, here the both system clocks are not synced and IDP clock is 60s faster than the SP clock, During this situation, if a SAML response is generated in the IDP, response will contain a NotBefore time stamp which is 60s greater than the SP time stamp, so when the assertion occurs in the SP with the SAML response, assertion will fail since the SP time is less than NotBefore time. But for the same scenario, if the network delay between IDP and the SP is more than 60s, the response will reach the SP after the NotBefore time stamp, so assertion will not fail. Scenario 2: In the second scenario, IDP clock is 60s slower than the SP clock, so the SAML response NotBefore time stamp is always less than the SP time stamp and assertion will not fail due to the not before condition. But lets say SP has a response validity period as 100's (clock Skew) and network delay between IDP and the SP is more than 40s response validity period < IDP clock difference + network delay So assertion will fail because of the NotOnOrAfter conditionResolutionIn this kind of scenarios adjust the clock skew time in IDP record to 120 seconds, default it will be 60 seconds so there is possibility of delay for 60 seconds in few casesIf we set it to 120 seconds then the 60 sec ahead of IDP and validity in SP is waiting for 120 sec so both will get satisfied and assertion validation will succeed and user login will be successfulThis can be set at IDP side as well by adjusting "notbeforeskew"