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

[David Walker]

So, in
https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration
it says:


          Flow Cancellation

    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.

    Flows use event IDs to signal their outcome back to the master
    subflow that orchestrates AuthenticationFlowSelection
    <https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection>.
    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.


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.

David


On 04/21/2015 09:33 AM, Cantor, Scott wrote:
> On 4/21/15, 12:22 PM, "David Walker" <dhwprof at gmail.com> wrote:
>> The MCB's limit was intended to be on the number of times the user is allowed to select an authentication method.
> 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.
>
>> 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.
> I think that's handled by providing a "cancel" button, not by tracking number of attempts.
>
>> 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.)
> 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.
>
>> 1. Scott, if the authentication method web flow returns failure, will Shib v3 return failure to the SP or give the user another chance?
> That's up to the deployer and is indirectly covered in the error handling documentation where event handling is described.
>
> -- Scott
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150423/a1e1ab33/attachment.html>