forced Authentication with authn/External

[Jeff Chapin]

>   it's the inverse since Duo's Remember Me feature tends to make honoring
ForceAuthn difficult, the first factor is normally the "guaranteed" one

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.

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

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.

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

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.

On Fri, May 17, 2024 at 9:00 AM Cantor, Scott <cantor.2 at osu.edu> wrote:

> > Is it as simple as adding
> idp.authn.external.forcedAuthenticationSupported = true to the
> > authn.properties to enable this?
>
> Mechanically, yes.
>
> > I believe that while the authn/External will just check to see if the
> current CAS cookie is valid
> > and not prompt the user, we *will* be using Duo with settings to "always
> prompt", so we
> > will be honoring the spirit of forcedAuthentication -- users will still
> have to verify their
> > identity with at least one factor before accessing the SP.
>
> 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.
>
> 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.
>
> 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.
>
> > Please let me know if I am on the right track, or missing something.
>
> 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.
>
> 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.
>
> -- Scott
>
>
>

-- 

Jeff Chapin,

Panther eSports Adviser
Systems/Applications Administrator
ITS-IS, University of Northern Iowa
Phone: 319-273-3162 Email: Jeff.Chapin at uni.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240517/2e5b6ead/attachment.htm>