<div dir="ltr">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.  <div><br></div><div>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.</div><div><br></div><div>Enabling end users to select an authN method (other than the opt in to 2FA via directory attribute) is not in my planning horizon.</div><div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 8:22 AM, David Walker <span dir="ltr"><<a href="mailto:dhwprof@gmail.com" target="_blank">dhwprof@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    A little background...<br>
    <br>
    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.)<br>
    <br>
    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.<br>
    <br>
    So, I have a couple of questions, one for Scott and one for
    everyone:<br>
    <br>
    <ol>
      <li>Scott, if the authentication method web flow returns failure,
        will Shib v3 return failure to the SP or give the user another
        chance?</li>
      <li>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 (<i>e.g.</i>,
        username/password, but not second factor), 3) multiple attempts
        for all authentication methods, or something else?</li><span class="HOEnZb"><font color="#888888">
    </font></span></ol><span class="HOEnZb"><font color="#888888">
    <p><br>
      David<br>
    </p></font></span><span class="">
    <br>
    On 04/20/2015 12:12 PM, Cantor, Scott wrote:<br>
    <blockquote type="cite">
      <pre>On 4/20/15, 6:41 PM, <a href="mailto:db@alaska.edu" target="_blank">"db@alaska.edu"</a> <a href="mailto:dabantz@alaska.edu" target="_blank"><dabantz@alaska.edu></a> wrote:


</pre>
      <blockquote type="cite">
        <pre>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.
</pre>
      </blockquote>
      <pre>There is no notion of limiting the number of failures at all.

-- Scott

</pre>
    </blockquote>
    <br>
  </span></div>

<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br></div>