IdP is returning invalid_message_timestamp if user takes too long to login

It appears that we are hitting some kind of default timeout with our saml request/response. Here’s the scenario:
The user goes to the SP and initiates a saml request to the IdP to login. The user takes 5 minutes to create an account or login. The saml response is returned to the SP ACS method, but it contains the following message: invalid_message_timestamp.
Here’s a sample of my saml request and response:
Request
<samlp:AuthnRequest AssertionConsumerServiceURL=“”
Destination=“” ForceAuthn=“false”
ID=“” IsPassive=“false” IssueInstant=“2018-10-23T23:52:18.774Z”
ProtocolBinding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Version=“2.0”
xmlns:samlp=“urn:oasis:names:tc:SAML:2.0:protocol”>
<saml:Issuer xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”></saml:Issuer>




<InclusiveNamespaces PrefixList=“#default samlp saml ds xs xsi”
xmlns=“”/>



Response (after 5 minutes)
<samlp:Response Destination=“”
ID=“”
InResponseTo=“” IssueInstant=“2018-10-23T20:35:38Z”
Version=“2.0” xmlns:fim=“urn:ibm:names:ITFIM:saml”
xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”
xmlns:samlp=“urn:oasis:names:tc:SAML:2.0:protocol”>
<saml:Issuer Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:entity”></saml:Issuer>
samlp:Status
<samlp:StatusCode Value=“urn:oasis:names:tc:SAML:2.0:status:Requester”></samlp:StatusCode>
samlp:StatusDetail
<fim:FIMStatusDetail MessageID=“invalid_message_timestamp”>
fim:SubstitutionStringTue Oct 23 13:30:03 PDT 2018</fim:SubstitutionString>
fim:SubstitutionString300</fim:SubstitutionString>
fim:SubstitutionStringTue Oct 23 13:35:38 PDT 2018</fim:SubstitutionString>
</fim:FIMStatusDetail>
</samlp:StatusDetail>
</samlp:Status>
</samlp:Response>

If the user is taking too long to login they will get this message. Is there something I can set in my saml configuration or SP code when making the saml request that will extend this timeout period? I found something called “NotOnOrAfter” which seems to be set by the AssertionLifeTime attribute, but this seems to only apply to “Partner Service Provider Configuration” not “Service Provider Configuration” which is what I’m using.

I’m not sure what the “invalid_message_timestamp” refers to.
The authn request includes an IssueInstant as does the SAML response.
The one thing that strikes me as odd is the IssueInstant for these.
The authn request appears to have been issued three hours after the SAML response.
Please ensure that your server’s clock and that of the IdP are correct just in case that’s causing the problem.
Other than that, I think you need assistance from the IdP.
They should be able to explain what is causing this error.
It’s odd that a delayed login would cause a problem. I’m assuming a regular login goes through without an issue.
The NotOnOrAfter/AssertionLifeTime only apply if you’re the IdP. There are no relevant configuration settings for the SP.