<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Thank you Mike! I will work that angle & let all know if it helps or resolves.<br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><br><div>David.Bantz<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.231373); -webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); ">@Alaska.edu</span><div><span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);"><br></span></div></div></div><div dir="ltr"><br><blockquote type="cite">On Nov 26, 2025, at 17:42, Michael Grady <mgrady@unicon.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">According to the AI summary in front of my search results, KeyCloak supports a clock skew setting, BUT it is set to zero (no allowed skew) by default. If that is true, and they did not think to adjust that setting, that could indeed be the problem. You could get them to look, or you could simply have a relying party override for that SP to not send NotBefore and see if that solves the problem.<div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Mike Grady, Unicon</div><div dir="ltr"><br><blockquote type="cite">On Nov 26, 2025, at 8:36 PM, Michael Grady <mgrady@unicon.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">One possibility I’d consider is their server clock management, and/or whether they have things configured to support some clock skew. It has been a few years, but there was a vendor we integrated with whose SP config did not support any clock skew. And even if both sides are synced to the same standard time source, clocks can be off by milliseconds, and that was enough — intermittently, but still often — to cause the SAML response to be rejected because of the NotBefore attribute in the response. Which is why I worked with Scott (we are talking back in 2012/13) to get the relying party override to have an option to NOT send the NotBefore attribute in the response. <div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Mike Grady, Unicon</div><div dir="ltr"><br><blockquote type="cite">On Nov 26, 2025, at 7:07 PM, IAM David Bantz via users <users@shibboleth.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Thank you for the response. <br>Our IdP side uses sticky sessions and I can verify that the successful and unsuccessful sign-ins for the same user were issues from the same IdP node.<br>But when we next meet, I will raise that issue for the vendor to examine on the SP side.<div><br>David Bantz</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Nov 26, 2025 at 3:13 PM o haya <<a href="mailto:ohaya1001@gmail.com">ohaya1001@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi, <br></div>Is there any clustering/round robin going on in the path somewhere? That might explain why you are seeing problems intermittently?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 26, 2025 at 4:22 PM IAM David Bantz via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We set up SSO with a vendor that relies on KeyCloak as the SAML2 SP interface. Are other users here aware of sporadic but plentiful failures with similar set-up? If so, we're desperate for potential remedies to offer to the vendor.<br><br>The iterative process to set up SAML2 SSO was frustrating as many aspects of SAML practices were apparently unknown to the vendor. But we have a seemingly complete integration in routine production. However many users - both naive users and experienced skilled users reproducing students' experiences - report failures at the service despite normal successful SSO and SAML response from the IdP to SP. We have repeatedly copied the exact SAML response (prior to encryption) to the vendor asking them to review their own logs to determine why students were occasionally being stopped. In some cases, a second or third sign-in attempt - seemingly identical to failed attempts - succeeds. We've provided examples of the exact same SAML response (save timestamps and transient nameID) that succeeds one time, fails another. Responses to have been, essentially, expressions of puzzlement; we have not seen any detailed logs from either KeyCloak or the service being protected. We've been stuck in this loop for 6 weeks; this is a mission critical service owned locally by our Registrars, who are understandably frustrated and despondent and have inboxes flooded with complaints from students unable to get needed service. <br><br>I did not mention the vendor or service to avoid flack, but will if it helps; many of you would recognize them.<div><br></div><div>David St PIerre Bantz<br>UA IAM<br><br></div></div>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>
</blockquote></div>
<span>-- </span><br><span>For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw</span><br><span>To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net</span><br></div></blockquote></div></div></blockquote></div></div></blockquote></body></html>