We have been experiencing difficulties setting up SAML in Jive using Google as the Identity Provider.
We successfully logged in with SAML enabled for Goggle however we experience an sso authentication error after a day being logged in
We raised a private case with Jive support, below is some feedback on the error message received
- Authentication statement is too old to be used with value 2017-03-06T22:35:29.000Z
- Validation of received assertion failed, assertion will be skipped
org.springframework.security.authentication.CredentialsExpiredException: Authentication statement is too old to be used
- Response doesn't have any valid assertion which would pass subject validation
- AuthNResponse;FAILURE;10.160.25.44org.opensaml.common.SAMLException: Error validating SAML response
- There was an error during SAML authentication
org.springframework.security.authentication.AuthenticationServiceException: Error validating SAML message
Caused by: org.opensaml.common.SAMLException: Error validating SAML response
... 119 more
The complaint is that your authentication statement is outside the required conditions. Parsing through the assertion included in the stacktrace, it's easy to see why.
<saml2:Conditions NotBefore="2017-03-07T22:31:54.483Z" NotOnOrAfter="2017-03-07T22:41:54.483Z">
<saml2:AuthnStatement AuthnInstant="2017-03-06T22:35:29.000Z" SessionIndex="_f1990db4724c1f3a93ceeec3043ec1af">
AuthnInstant (2017-03-06T22:35:29.000Z) is older than NotOnOrAfter (2017-03-07T22:41:54.483Z"). Usually, this means that your server time is out of sync. In order to verify this, I ran ntpstat on both of your web app servers.
[nathan.howard@envato-isthebest-enc-t-wa01 ~]$ ntpstat
synchronised to NTP server (10.160.8.15) at stratum 3
time correct to within 165 ms
polling server every 1024 s
[nathan.howard@envato-isthebest-enc-t-wa02 ~]$ ntpstat
synchronised to NTP server (10.160.8.11) at stratum 3
time correct to within 158 ms
polling server every 1024 s
However, Jive appears to be in sync with NTP (Network Time Protocol). So I would recommend checking ntpstat on your IDP's server. Another way this can also be solved is by increasing the "Response Skew" time under Admin Console: People > Settings > Single Sign-On > SAML > General. See General SAML Integration Settings:
Specifies the maximum permitted time between the timestamps in the SAML Response and the clock on the Jive instance. The default value is 120 seconds. If there is a significant amount of clock drift between the IdP and Jive, you can increase this value. The same value is also used for the skew in the NotBefore check in the response. If you see an error indicating a problem with the NotBefore check and you aren't able to fix the clock difference problem, you can try increasing this value. However, increasing the response skew value can increase your security risk.
My colleague did some further investigations into this issue and here is his findings:
Let me clarify first a few misconceptions we have about the SAML response. The `saml2:Conditions` is sent by the IdP (i.e. Google) in the response to indicate simply the conditions under which the whole response should be accepted by the consumer (i.e. Jive). In other words, the `NotBefore` and `NotOnOrAfter` values are only telling Jive to accept the assertion in that given timeframe, but it has nothing to do with the authentication itself.
Now, going into the authentication bit. The `saml2:AuthnStatement` contains the last time the user was authenticated by the IdP in the `AuthnInstant`. For Google, that only happens when the user is forced to re-authenticate due to session expiration, MFA token expiration (remember this is 30 days), or user forcing a logout-login cycle. Google does not consider reusing an existing authentication token as a re-authentication, hence why we see what we see in the responses.
The following article mentions that, once the response is deemed valid through `saml2:Conditions`, Jive checks if the `AuthnInstant` is within a given maximum authentication age, and if not, it will simply throw the error we see:
*Solution:* Modify the Maximum Authentication Age parameter to be a reasonable amount of time (maybe 30 days because that's when the MFA token expires?). This can be done through the administration console in Jive, or most probably asking them to do it if we don't have access to such console in Jive Cloud:
I hope this blog post helps you.