<div dir="ltr"><div><div><span class="im">
</span>>>Not new at all, but it tends to lead to a sloppy separation of concerns that doesn't work well at scale.<br><br></div>Sorry for the confusion, I didn't mean authorization at the IDP was new.   I meant my corporate use case of authorization - ie its not at scale and didn't have data ownership issues. So perhaps it didn't fit in the philosophical objections given previously.<br><br>>>Also, the main goal of the new platform was radical extensibility, i.e. 
making things we didn't agree with much easier to build with small 
amounts of code so that we weren't the gating factor.<br><br></div>Ok, I've read documents referring to that too but I was referring to discussions of oauth and OpenID Connect and other future technologies, and I assumed the discussion of shib 3 going forward was beyond extensibility and included new use cases and directions for the project.<br><div><br>>> In this case, your
 goal of authorization is really secondary to the question of what hooks
 exist or might be missing.<br><br></div><div>Fair enough.  Thank you.<br><br>>>I don't know that, upon studying it, I'll conclude that the right place 
for this isn't there already with the outbound intercept hook. The only 
reason I was initially not thinking that way is efficiency, since that 
runs rather late and we can probably do something a little less late in 
the sequence.<br><br></div><div>That might be ok.   Thank you for looking into it.<br><br></div><div>-Christopher<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 1: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 1/27/16, 2:18 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>
>In a university use case, or any use case where ownership of the data is different then the identity provider I see your point - but I think I'm representing a new corporate use case where the identity provider does also own the data<br>
<br>
</span>Not new at all, but it tends to lead to a sloppy separation of concerns that doesn't work well at scale.<br>
<span class=""><br>
>- many cots in house products now come with SAML support. I've seen shibboleth 3 or maybe it was incommon email last year about what should the future of the shibboleth 3 identity platform be - and I guess one enhancement request at a time I'm bringing ideas into the mix.<br>
<br>
</span>Having the IdP do authorization is not a new idea, but it was always something approached with a large grain of salt.<br>
<br>
Also, the main goal of the new platform was radical extensibility, i.e. making things we didn't agree with much easier to build with small amounts of code so that we weren't the gating factor. In this case, your goal of authorization is really secondary to the question of what hooks exist or might be missing.<br>
<br>
I don't know that, upon studying it, I'll conclude that the right place for this isn't there already with the outbound intercept hook. The only reason I was initially not thinking that way is efficiency, since that runs rather late and we can probably do something a little less late in the sequence.<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>