<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
So, in <a
href="https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration">https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration</a>
it says:<br>
<br>
<blockquote>
<h3 id="AuthenticationConfiguration-FlowCancellation">Flow
Cancellation</h3>
<p>It's possible to provide users with a way to "cancel" the use
of a login flow, perhaps to indicate that can't successfully
complete it, or to just cancel the request outright.</p>
<p>Flows use event IDs to signal their outcome back to the master
subflow that orchestrates <a
href="https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection">AuthenticationFlowSelection</a>.
The built-in login flows include configuration support for
mapping various conditions they encounter into specific event
IDs. If a login flow produces the "ReselectFlow" event, that
causes the master subflow to try and find a new login flow to
attempt, but any other unsuccessful event will essentially
cancel the login process.<br>
</p>
</blockquote>
<br>
Am I right in assuming that if a site configures authentication
flows to return "ReselectFlow", rather than failure, then David
Bantz would get the effect he wants? That is, the IdP would
continue to prompt the user for authentication and not return to the
SP? Adding a "Get me out of here!" button that returns failure
would address the original intent of the MCB's counter, but it
wouldn't be necessary.<br>
<p>David<br>
</p>
<br>
<div class="moz-cite-prefix">On 04/21/2015 09:33 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:1F8E581F-1E61-48E3-93B2-44FEEC155647@osu.edu"
type="cite">
<pre wrap="">On 4/21/15, 12:22 PM, "David Walker" <a class="moz-txt-link-rfc2396E" href="mailto:dhwprof@gmail.com"><dhwprof@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
The MCB's limit was intended to be on the number of times the user is allowed to select an authentication method.
</pre>
</blockquote>
<pre wrap="">
The IdP has no notion of a user selecting something, so that's why it's not tracked. The IdP selects the method from among the valid options. Somebody implementing a flow to do user selection is free to attach context tree state to track this if they wanted to. The tree design allows extensions to attach their own state without the IdP code having to change to accomodate it.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
I think that's handled by providing a "cancel" button, not by tracking number of attempts.
</pre>
<blockquote type="cite">
<pre wrap="">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.)
</pre>
</blockquote>
<pre wrap="">
There's no right or wrong answer, it depends on the situation. Again, most login forms today have no cancel button, but the broken back button behavior necessitated by the way SWF works and the amount of state we have to track means that having some kind of cancel option is probably a good idea and we should probably add it to the example form.
</pre>
<blockquote type="cite">
<pre wrap="">1. Scott, if the authentication method web flow returns failure, will Shib v3 return failure to the SP or give the user another chance?
</pre>
</blockquote>
<pre wrap="">
That's up to the deployer and is indirectly covered in the error handling documentation where event handling is described.
-- Scott
</pre>
</blockquote>
<br>
</body>
</html>