IdP and SP clock tolerance

[Paul Fardy]

Re: curl -i

Well, it should have occurred to me to check the web server headers. Thanks.

I asserted that our clocks were NTP sync'd and match several visible web services. I asked for them to check their servers. They responded by restarting the servers and I guess that fixed the clocks. So too late now for me to check the HTTP headers.

Isn’t some tolerance acceptable, if not valuable? If I’m running an SP with Discovery Service and one IdP happens to be N seconds fast, how might I address that? The right thing is for the IdP to fix its clock. But an SP “fix” might be expedient and, therefore, valuable.

>From the IdP perspective, the ADFS option seems like a hack, except setting notBefore=(now - 4 seconds) seems useful and not unreasonable.

Still, they should have tested and fixed their clock before telling us to accommodate them.

Paul
--
Paul Fardy, Service Delivery, Info Security, ITS
University of Toronto

On Oct 6, 2020, at 3:35 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

EXTERNAL EMAIL:  Treat content with extra caution.

On 10/6/20, 3:09 PM, "users on behalf of Paul Fardy" <users-bounces at shibboleth.net on behalf of paul.fardy at utoronto.ca> wrote:

  We have an SP that's rejecting our SAML responses, apparently due to clock differences. The SP uses Unsolicited SAML >requests, so I cannot see a SAML AuthnRequest and, thus far, I have no means of checking the SP's clock.

Modulo web site architecture, curl -i to examine the header from the server. It's usually a decent hint.

Clock skew is, by definition, the message recipient's responsibility, not the sender's. If it had occurred to anybody writing the standard that this was ever in question, we would have said so.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20201006/c2cdf1a6/attachment.htm>