Multi-Context Broker functionality in Shibboleth v3 - Comments please.

[IAM David Bantz]

My IdP infrastructure is fairly simple.  The only end user 'choice'
currently supported is a (directory) attribute requiring use of Duo's 2FA -
so a choice outside the SAML flow.

Apparently some users (the application was one for placement testing, so
users mostly new to any central authN) entered or guessed invalid
credentials multiple times; the first two times receiving our standard
"Authentication Failed" response on the login page, but the third time
being re-directed to the SP for an unhelpful error message.  Of course
attempting to return to the IdP login page or even to the original page
that sent them to the IdP does not allow for yet more attempts and the
users perceived a "dead end."  Raising the "max number of fails" in the MCB
config to a large number resolved this problem for those users.  So the
behavior I don't want in v3 is an analogous redirect to the IdP after a
small number of authN failures at the IdP.

Enabling end users to select an authN method (other than the opt in to 2FA
via directory attribute) is not in my planning horizon.

David

On Tue, Apr 21, 2015 at 8:22 AM, David Walker <dhwprof at gmail.com> wrote:

>  A little background...
>
> The MCB's limit was intended to be on the number of times the user is
> allowed to select an authentication method.  Each authentication method
> could also allow multiple tries (and, in fact, I figured that
> username/password methods would try multiple times without before returning
> to the MCB).  We wanted to handle, for example, the case where a user
> selected a method requiring a hardware token and then found she didn't have
> the token in her pocket by giving her a chance to choose another method.
> The limit was to keep the user from being trapped and never returning
> control to the SP.  (FYI, at some point along the line, I had a discussion
> with Scott and decided that the best thing would have been always to return
> the user to the SP, figuring that it would then decide to prompt the user
> to login again, but we had already released the MCB by then.)
>
> Now that we've got some experience with the MCB, however, it appears that
> 1) many IdP administrators avoid providing choices of authentication
> methods, due to the confusion it causes, and 2) IdP administrators avoid
> dumping users back to an SP, as the probability is high that the SP will
> not treat the user well.
>
> So, I have a couple of questions, one for Scott and one for everyone:
>
>
>    1. Scott, if the authentication method web flow returns failure, will
>    Shib v3 return failure to the SP or give the user another chance?
>    2. David Bantz and others, are you looking for 1) multiple attempts to
>    select an authentication method (as the MCB does), 2) multiple attempts for
>    select authentication methods (*e.g.*, username/password, but not
>    second factor), 3) multiple attempts for all authentication methods, or
>    something else?
>
>
> David
>
> On 04/20/2015 12:12 PM, Cantor, Scott wrote:
>
> On 4/20/15, 6:41 PM, "db at alaska.edu" <db at alaska.edu> <dabantz at alaska.edu> <dabantz at alaska.edu> wrote:
>
>
>
>  Agreed; that's the scenario I want to avoid.  In MCB / IdP 2 I avoid by
> setting high threshold for max failures.  I want a config or other means
> to avoid in IdP 3 as well.
>
>  There is no notion of limiting the number of failures at all.
>
> -- Scott
>
>
>
>
> --
> 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/20150421/e8f3f868/attachment.html>