Authn cancel from a subflow.

[Cantor, Scott]

On 8/5/15, 4:20 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

>Thanks.  This is great; very flexible.  Can I assume, then, that only a 'proceed' event will result in an SSO session being granted?

In general. If something else was added to the flow(s) somewhere that handled a non-proceed event but then turned around and transferred control back into the main processing logic, that would no longer be true.

I would not be willing to guarantee that nothing somebody did could convince the flow to pick back up and continue because it's still sort of primed for that, but I believe once it reaches a final end-state at the top level (like ErrorView or AuditedErrorView), that ends the flow execution and there's no way to pick it back up. So most of the time I think it will terminate before anybody could step in and override that. It only hits the client when view boundaries are crossed, the rest of the time it's just server side.

I'm hedging because the error handling and these various mechanisms weren't meant as security tools. The goal wasn't to prevent an adventurous user from convinving the IdP to issue an assertion that it was already configured and primed to issue about that user. Mostly it was to prevent issuing responses that would lead to errors anyway if they did get issued (like the Google case), or to let a user prevent it (attribute release), in which case there's no reason to think they'd want to subvert their own decision.

Interrupting authentication itself (which is not what an intercept here does, this is afterwards) is a different matter, because that would bubble out before the state of the context tree was such that subsequent steps would run properly. You can't fool it into thinking you logged in, I'm just saying once you have, it's less bulletproof as to whether it will respond. It may well be very hardened or impossible, but I'm not prepared to say that.

-- Scott