Authn cancel from a subflow.

[cneberg]

I'm working on a plugin which could handle problematically allowing or
forbidding access to a specific entityID based on properties of the
authentication - such as the authentication type, and/or properties of the
user such as what groups they are in.   I was building this based on
modeling it after the attribute release flow, but now that sounds wrong.
Where would I put code which does this and can cancel the flow securely?

Thanks,
Christopher

On Wed, Aug 5, 2015 at 3:34 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
> --
> 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/20150805/6330ae8b/attachment.html>