<div dir="ltr"><div>>I'm sure there are any number of small tree changes that would reliably break the code.<br></div><br>I assume you mean any small changes to the context tree of the flow, as done by my code would break the the code of the flow (which is my goal) - so this is the path I should take if I need authorization in the IDP?<br><div><br>>It's just not a use case we have to do this. Authorization is the SPs 
job, and having the IdP do it is viewed as a UI feature, not a security 
feature.<br></div><div><br>I agree with fine grained authorization there is no other way but to do authorization in the SP, but for general corporate requirements doing it at the IDP is simpler to enforce at scale, and just as important to audit at scale.  I have already created a IDP hub so there is no other IDP's in play - all SP's must trust a single IDP - so in my case there is a single point where this could be implemented.    Maybe the level of autonomy given to make security decisions is different in university environments where shib is often used, than what is available to SP's in corporate environments.    In a company I think the autonomy is often much lower, and those additional policies need to be implemented while still minimizing their enforcement/audit point(s) and I think this is simple way to do it.<br><br></div><div>So I guess I'm asking is - could there be a blessed way for developers who want to implement Authorization in the IDP to do it securely?    Either the way you describe above - becomes the blessed way, OR some new API we could code to?   I could open a case if this is something you are willing to discuss more.<br><br></div><div>Thanks,<br></div><div>Topher<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 10:23 AM, 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, 8:48 PM, "users on behalf of cneberg" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:cneberg@gmail.com">cneberg@gmail.com</a>> wrote:<br>
<br>
<br>
<br>
>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.<br>
>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?<br>
<br>
</span>I'm not prepared to claim there is any way to do it with an absolute degree of certainty once the login is done. I would have to look at the code and determine exactly which context tree manipulations would do the trick. Even destroying user information might still just result in an empty assertion.<br>
<br>
Probably the one absolute that would do it in the SAML case is destroying the outbound message context because that's where the information on encoding the response lives. I'm sure there are any number of small tree changes that would reliably break the code.<br>
<br>
It's just not a use case we have to do this. Authorization is the SPs job, and having the IdP do it is viewed as a UI feature, not a security feature.<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>