"The SAML Assertion is too old" error randomly reported when users trying to authenticate
search cancel

"The SAML Assertion is too old" error randomly reported when users trying to authenticate


Article ID: 209766


Updated On:


Cloud Secure Web Gateway - Cloud SWG


Explicit access method used with WSS

SAML Authentication enabled for all users

SAML IDP server is the Auth Connector/BCCA IDP server

Users seem to be able to authenticate file.

User are unable to access the internet randomly. Instead of getting the web site they were going to, they get the following error shown below:

"The SAML assertion is too old. The assertion's IssueInstant attribute specifies a time too far in the past" 




Clock skew on some proxy servers within WSS

SAML IDP server not defining any conditions for time validity

WSS consumes assertion and defaults to a short window for valid assertions


Update checks to NTP server for WSS proxies to sync up every minute.

Defect open to increase the time window which a WSS assertion is considered valid IF the assertion generated by IDP server does not contain any conditions statement with time info.

Additional Information

When the IDP generates an assertion, it typically includes a condition statement with NotBefore or NotOnOrAfter timestamps. This provides a window where the assertion, being consumed by the SAML SP/WSS, is considered valid. An example of such a case is shown below where the assertion was issued at 8:08:04 UTC, but the conditions statement states that the time window is +/- 5 mins from this time (8:03:04 UTC to 8:13:04 UTC). This info should be used by the SAML SP/WSS to allow for clock skews.


        <saml2:Assertion ID="id4262995610995183474548298" IssueInstant="2021-03-02T08:08:04.326Z" Version="2.0"
            <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
                    <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">[email protected]</saml2:NameID>
                    <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                        <saml2:SubjectConfirmationData InResponseTo="_60aae74eb8407227e7d52a9c4c411ada13fb04373d59609a392db182148921ec" NotOnOrAfter="2021-03-02T08:13:04.326Z" Recipient="https://saml.threatpulse.net:8443/saml/saml_realm/bcsamlpost"/>
                <saml2:Conditions NotBefore="2021-03-02T08:03:04.326Z" NotOnOrAfter="2021-03-02T08:13:04.326Z"


With the BCCA IDP server, the assertion does not include any condition as shown below. The end result is that the SAML SP/WSS defaults to it's own validation window which is set to 1 minute. If there is a time discrepancy of more than one minute between the SAML IDP server and SP, we will fail and throw the above message to users.

                xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Version="2.0" ID="_exUNoio0Zjbxli4I7NJgyMa9UrK5efWqBk24eieAJWzGq2coW0KkkYSOptSju7dmwuEtXs1MIEfozkz569uOlOc6VCYC" IssueInstant="2021-03-03T13:37:50Z" InResponseTo="_6773aeaa63b23ae6fa9420f366a86cde3c5331a159e95b6ece0176d675efdb87">
                                <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
                                xmlns="urn:oasis:names:tc:SAML:2.0:assertion" IssueInstant="2021-03-03T13:37:50Z" Version="2.0">