<div dir="ltr">> 

 it's the inverse since Duo's Remember Me feature tends to make honoring ForceAuthn difficult, the first factor is normally the "guaranteed" one<br><br>We have a selector in place that picks what Duo pool we send an SP to, and I have already stated that *IF* we do this, we will absolutely be using the "Always Prompt" pool in Duo. It is my understanding that forceAuth requires that we guarantee that the user interactively authenticate, so we will guarantee that with Duo.<br><br>> 

This SP is broken anyway, so none of that much matters, but you need to recognize that unless you actually block ForceAuthn, enabling the property is telling all SPs they can use and rely on ForceAuthn, not just this one.<span class="gmail-im" style="color:rgb(52,57,59)"><br></span><div>This is absolutely a concern I have, but it sounds like management is going to tell me 'make it work'. Since we are moving to authn/Password in the very near future, we will be able to fix this at that point. Since we have gone since IDP 2 without having a vendor try and use Force/Auth, we might just have to risk it for a couple of weeks. It's also worth noting that I am the one that implements new integrations, and will absolutely be watching for *new* integrations that try to use forceAuth until this is resolved.<br><br>We cannot move the authn/Password up (this timeline is set in stone due to needing to retire an application before we make this change), and we need to have this new SP online ASAP, so we can use it for the summer semester. I would love to either override this in relying-party.xml for one SP, but that did not seem to work -- and I am also willing to set up a second authenticateionFlow that allows forceAuth, and only letting this SP use it -- but given the timelines, this may be more effort and time than it's worth.</div><div><br></div><div>>That's a different question. Normalizing saying no to bugs is IMHO one of the more important tasks in operating an IdP. Once you set the expectation that broken SPs will be coddled, you will be doing it for everything.</div><br>I understand, and I am on the same page with you, and I am making much the same arguments, but I have to play with the hand dealt me.  I would be far more against this if we were not already working towards moving to authn/Password -- which makes this particular discussion a moor point. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 17, 2024 at 9:00 AM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</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">> Is it as simple as adding idp.authn.external.forcedAuthenticationSupported = true to the<br>
> authn.properties to enable this?<br>
<br>
Mechanically, yes.<br>
<br>
> I believe that while the authn/External will just check to see if the current CAS cookie is valid<br>
> and not prompt the user, we *will* be using Duo with settings to "always prompt", so we<br>
> will be honoring the spirit of forcedAuthentication -- users will still have to verify their<br>
> identity with at least one factor before accessing the SP.<br>
<br>
The lack of an answer to that question is why the feature is not interoperable in general, but usually it's the inverse since Duo's Remember Me feature tends to make honoring ForceAuthn difficult, the first factor is normally the "guaranteed" one.<br>
<br>
The current IdP swaps the logic to set AuthnInstant to the oldest time at which it thinks somethng happened and not the newest, though that is configurable. Older versions use the newest, essentially lying to the SP about it so that they can't make an informed decision.<br>
<br>
This SP is broken anyway, so none of that much matters, but you need to recognize that unless you actually block ForceAuthn, enabling the property is telling all SPs they can use and rely on ForceAuthn, not just this one.<br>
<br>
> Please let me know if I am on the right track, or missing something.<br>
<br>
That's a different question. Normalizing saying no to bugs is IMHO one of the more important tasks in operating an IdP. Once you set the expectation that broken SPs will be coddled, you will be doing it for everything.<br>
<br>
Most of the people who complain to me about how bad their IdP config is and what a mess it all is have been shown to take the "let them get away with everything" mindset. That's why I am so vocal about it.<br>
<br>
-- Scott<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><pre cols="72">Jeff Chapin,</pre>Panther eSports Adviser            <br>Systems/Applications Administrator<br>ITS-IS, University of Northern Iowa<br>Phone: 319-273-3162 Email: <a href="mailto:Jeff.Chapin@uni.edu" target="_blank">Jeff.Chapin@uni.edu</a> </div></div></div></div>