ShibRequestSetting forceAuthn true vs 1 vs on

[Dan McLaughlin]

Hey Scott,

Thanks for the feedback.

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."

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.

I will go ahead and open a bug report for this.

--

Thanks,

Dan

On Fri, Jun 5, 2026 at 8:23 AM Scott Cantor via users <users at shibboleth.net>
wrote:

> 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...
>
> > On Jun 4, 2026, at 4:06 PM, Dan McLaughlin via users <
> users at shibboleth.net> wrote:
> >
> > 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.
> >
> > 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.
>
> 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.
>
> 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.
>
> I would not, certainly, suggest that On/Off is a good ides in that
> command, but I understand the reason to accidentally do it.
>
> -- Scott
>
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> 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/20260605/87fe6f96/attachment.htm>