<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div>Re: <span style="font-family: "Courier New", monospace;">curl -i</span></div>
<div><br>
</div>
<div><span style="font-family: "Palatino Linotype", "Book Antiqua", Palatino, serif;">Well, it should have occurred to me to check the web server headers. Thanks.</span></div>
<div><br>
</div>
<div><span style="font-family: "Palatino Linotype", "Book Antiqua", Palatino, serif;">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.</span></div>
<div><br>
</div>
<div><span style="font-family: "Palatino Linotype", "Book Antiqua", Palatino, serif;">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.</span></div>
<div><br>
</div>
<div><span style="font-family: "Palatino Linotype", "Book Antiqua", Palatino, serif;">From the IdP perspective, the ADFS option seems like a hack, except setting
</span><span style="font-family: Arial, Helvetica, sans-serif;">notBefore=(now - 4 seconds)</span><span style="font-family: "Palatino Linotype", "Book Antiqua", Palatino, serif;"> seems useful and not unreasonable.</span></div>
<div><br>
</div>
<div><span style="font-family: "Palatino Linotype", "Book Antiqua", Palatino, serif;">Still, they should have tested and fixed their clock before telling us to accommodate them.</span></div>
<div><br>
</div>
<div><span style="font-family: "Palatino Linotype", "Book Antiqua", Palatino, serif;">Paul</span><br>
<div id="AppleMailSignature">
<div class="ApplePlainTextBody" style="font-family:Charter; font-size:13px">--</div>
<div class="ApplePlainTextBody"><font color="#011993" face="Arial">Paul Fardy, Service Delivery, Info Security, ITS</font></div>
<div class="ApplePlainTextBody"><font color="#011993" face="Arial">University of Toronto</font></div>
</div>
<div class="AppleOriginalContents" style="direction:ltr"><br>
<div>On Oct 6, 2020, at 3:35 PM, Cantor, Scott <cantor.2@osu.edu> wrote:</div>
<blockquote type="cite"><br class="Apple-interchange-newline">
<div>
<div>EXTERNAL EMAIL: Treat content with extra caution.<br class="">
<br class="">
On 10/6/20, 3:09 PM, "users on behalf of Paul Fardy" <users-bounces@shibboleth.net on behalf of paul.fardy@utoronto.ca> wrote:<br class="">
<br class="">
<blockquote type="cite" class=""> 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.<br class="">
</blockquote>
<br class="">
Modulo web site architecture, curl -i to examine the header from the server. It's usually a decent hint.<br class="">
<br class="">
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.<br class="">
<br class="">
-- Scott<br class="">
<br class="">
<br class="">
--<br class="">
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg<br class="">
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br class="">
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>