SSO/SAML login fails with "Received invalid SAML response: Timing issues (please check your clock settings)" (Server and Data Center)
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Users are unable to login via SSO.
This might be happening consistently to any user, or some users can experience it intermittently.
Diagnosis
Reviewing the Atlassian product log, you will find error messages such as:
2021-05-31 09:42:54,03 ERROR [https-jsse-nio2-8443-exec-104] [onelogin.saml2.authn.SamlResponse] isValid Timing issues (please check your clock settings)
-- url: /confluence/plugins/servlet/samlconsumer | traceId: c7455b0abd6e00bb | userName: anonymous
2021-05-31 09:42:54,404 ERROR [https-jsse-nio2-8443-exec-104] [com.onelogin.saml2.Auth] processResponse processResponse error. invalid_response
-- url: /confluence/plugins/servlet/samlconsumer | traceId: c7455b0abd6e00bb | userName: anonymous
2021-05-31 09:42:54,405+0200 ERROR [https-jsse-nio2-8443-exec-104] [impl.web.filter.ErrorHandlingFilter] doFilter Received invalid SAML response: Timing issues (please check your clock settings)
com.atlassian.plugins.authentication.impl.web.saml.provider.InvalidSamlResponse: Received invalid SAML response: Timing issues (please check your clock settings)
at com.atlassian.plugins.authentication.impl.web.saml.provider.impl.OneloginJavaSamlProvider.lambda$extractSamlResponse$1(OneloginJavaSamlProvider.java:89)
at com.atlassian.plugin.util.ContextClassLoaderSwitchingUtil.runInContext(ContextClassLoaderSwitchingUtil.java:48)
at com.atlassian.plugins.authentication.impl.web.saml.provider.impl.OneloginJavaSamlProvider.extractSamlResponse(OneloginJavaSamlProvider.java:80)
at com.atlassian.plugins.authentication.impl.web.saml.SamlConsumerServlet.doPost(SamlConsumerServlet.java:87)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
...
2021-05-31 09:42:54,405+0200 http-nio-8080-exec-52 ERROR /plugins/servlet/samlconsumer [c.a.p.a.i.web.filter.ErrorHandlingFilter] Received invalid SAML response: Could not validate timestamp: expired. Check system clock.
com.atlassian.plugins.authentication.impl.web.saml.provider.InvalidSamlResponse: Received invalid SAML response: Could not validate timestamp: expired. Check system clock.Cause
The error is self-explanatory and points to clock synchronisation issues between the IdP and the SP (the Atlassian product).
When a SAML response is received from your IdP if the user succeeds in the authentication process, it specifies additional data that allows the subject to be confirmed or constrains the circumstances under which the act of subject confirmation can take place.
Among those conditions, it may include a NotBefore and NotOnOrAfter attributes. As an example:
<Conditions NotBefore="2021-05-31T10:45:28.672Z" NotOnOrAfter="2021-05-31T11:45:28.672Z">
<AudienceRestriction>
<Audience>https://YOUR_APPLICATION_URL</Audience>
</AudienceRestriction>
</Conditions>NotBefore is a time instant before which the subject cannot be confirmed and NotOnOrAfter indicates a time instant at which the subject can no longer be confirmed. If the SP verifies the request outside of this interval, it will fail.
Solution
System clocks are usually kept in sync via Network Time Servers (NTP - Network Time Protocol). Infrastructure admins need to make NTP is syncing and the time delta is negligible.
- If logins to multiple SPs are impacted, the issue most likely lies with the clock of the IdP server.
- If only logins to the Atlassian product are failing, the clock needs to be fixed on the product server side.
Occasionally, if using Microsoft ADFS as IdP, it is possible to configure an additional parameter called NotBeforeSkew that allows a little clock skew to account for small clock drifts. Please, review the official Microsoft documentation for further details: ADFS > Set-AdfsRelyingPartyTrust.
Similar options might exist for other IdPs, our recommendation is to check with your IdP provider.