"The SAML Assertion is too old" error randomly reported when users trying to authenticate
Article ID: 209766
Updated On:
Products
Issue/Introduction
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"
Cause
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
Resolution
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"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://www.okta.com/xxxxxxxxxx
</saml2:Issuer>
<ds:Signature
:
</ds:Signature>
<saml2:Subject
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<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:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2021-03-02T08:03:04.326Z" NotOnOrAfter="2021-03-02T08:13:04.326Z"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:AudienceRestriction>
<saml2:Audience>https://saml.threatpulse.net:8443/saml/saml_realm</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
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.
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Version="2.0" ID="_exUNoio0Zjbxli4I7NJgyMa9UrK5efWqBk24eieAJWzGq2coW0KkkYSOptSju7dmwuEtXs1MIEfozkz569uOlOc6VCYC" IssueInstant="2021-03-03T13:37:50Z" InResponseTo="_6773aeaa63b23ae6fa9420f366a86cde3c5331a159e95b6ece0176d675efdb87">
<Issuer
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">bcca
</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion
xmlns="urn:oasis:names:tc:SAML:2.0:assertion" IssueInstant="2021-03-03T13:37:50Z" Version="2.0">
<Issuer>bcca</Issuer>
<Subject>
<NameID>DOMAIN\user</NameID>
</Subject>
Feedback
