<div dir="ltr">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?<div><br></div><div>Thanks,</div><div>Christopher</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 5, 2015 at 3:34 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8/5/15, 4:20 PM, "users on behalf of O'Dowd, Josh" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:Josh.O%27Dowd@mso.umt.edu">Josh.O'Dowd@mso.umt.edu</a>> wrote:<br>
<br>
>Thanks.  This is great; very flexible.  Can I assume, then, that only a 'proceed' event will result in an SSO session being granted?<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>