<div dir="ltr">Hey Scott,<br><br>Thanks for the feedback.<br><br>To clarify the timeout issue: it occurs when a user is proxied to the MFA provider and takes more than two minutes to enter their code and return to the SP. By that point, the SP session has expired, resulting in the error: "The gap between now and the time you logged into your identity provider exceeds the allowed limit."<br><br>I likely changed the setting to "On" because other configurations were using that syntax and the SP documentation listed "1" or "On" as examples. My expectation was that if the documentation lists "1", "on", or "true" as valid boolean values, the SP would handle the translation to ensure the setting takes effect as intended. I probably changed to On because that's what everything else was using. <br><br>I will go ahead and open a bug report for this.<br><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>--<br><br>Thanks,<br><br>Dan </div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jun 5, 2026 at 8:23 AM Scott Cantor via users <<a href="mailto:users@shibboleth.net">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">I'm not sure what ForceAuthn in particular has to do with a timeout error, that sounds at most as though there's some login flow that needs to be adjusted in terms of whether it supports ForceAuthn perhaps, but...<br>
<br>
> On Jun 4, 2026, at 4:06 PM, Dan McLaughlin via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> wrote:<br>
> <br>
> I believe I have identified the cause of this behavior. From a SAML XML perspective, forceAuthn is a boolean that expects a value of 0, 1, true, or false.<br>
> <br>
> It appears the SP is not converting "on" to "1" or "true" before passing it along. Instead, it passes the value literally as "on," which causes the process to break.<br>
<br>
I don't have time to check into it right now, but file a bug and I'll verify how the ShibRequestSetting command parsing is handling that. The On/Off syntax is more Apache and that just translates internally into a boolean, but that's only for single argument commands.<br>
<br>
ShibRequestSetting is parsed by additional code to handle boolean settings and it might be mishandling or explicitly not handling On/Off and it's just treating "not 1/true" as false.<br>
<br>
I would not, certainly, suggest that On/Off is a good ides in that command, but I understand the reason to accidentally do it.<br>
<br>
-- Scott<br>
<br>
-- <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>