IdP Shibboleth timing Issue

Michael A Grady mgrady at unicon.net
Tue Sep 24 21:46:41 EDT 2013


The best solution is to get the SP to "do the right thing" and allow for clock skew in the first place, which is what they should be doing according to the SAML standard (and by long running best practice with other protocols with short-lived timestamp windows for key artifacts like Kerberos).

The other option, one we needed to use with one cloud vendor that refused to allow for clock skew, was to remove sending the NotBefore condition in the first place -- which the SAMLv2 standard explicitly allows. (Both NotBefore and NotAfter are optional according to the standard.) Note that is the condition that is causing you problems. (If both the IdP and SP are successfully syncing clocks to recognized time sources, the NotAfter condition should never cause you problems unless you start setting validity periods of only a few seconds.)

The latest release of the Shib IdP, 2.4.0, allows you to set an option, by protocol, to *not* send a NotBefore condition. The attribute you use is:

  includeConditionsNotBefore="false" (default is true)

See the Relying Party SAML2 SSO Profile page for the details:

 https://wiki.shibboleth.net/confluence/display/SHIB2/IdPSAML2SSOProfileConfig

You can set that for a specific relying party, for the default relying party config, and/or for the anonymous relying party config.

On Sep 24, 2013, at 7:47 PM, lalithj wrote:

> Hi
> 
> We got a SP connected to our IdP (IdP initiated SSO), the SP is hosted
> elsewhere, it has been working but since yesterday we have a issue
> connecting to that SP,
> 
> Our IdP is sync with NTP and got other SPs working fine, the issue raised by
> the SP is
> 
> client response is .....
> 
> "The SAML document specified an invalid time based on the NotBefore and 
> NotAfter values and the our server time.The NotBefore value provided 
> was 9/24/2013 2:23:37 AM.T he NotAfter value provided was 9/24/2013
> 2:28:37 AM.  Our Server time was 9/24/2013 2:23:36 AM."
> It seems that IdP server's time is advance by one second which is what's
> causing the issue"
> 
> 
> Please shed some light what is the best way to solve issues like this.
> 
> Thanks
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> View this message in context: http://shibboleth.1660669.n2.nabble.com/IdP-Shibboleth-timing-Issue-tp7590238.html
> Sent from the Shibboleth - Users mailing list archive at Nabble.com.
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.



More information about the users mailing list