<div dir="ltr"><div>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 - 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.  I'm not sure that's the best path but I'm not sure of what the alternative path's are.<br><br></div><div>Thanks,<br></div>Christopher<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 12:37 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, 1:12 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>
>Interesting I assumed it would be a popular.   Having a central way to control even loose authorization is powerful.<br>
<br>
</span>I think it's misguided. One of the differences here is that Shibboleth was designed around a world in which the resources being protected were not owned by the IdP's organization, and enterprises using federation really care much more about the case where they are. If you own the resources, you certainly can't expect me to enforce the access control for you (vs. me providing the data to help determine the decision).<br>
<br>
My experience is that creating rules at the IdP is inflexible and leads to unanticipated consequences when people figure out how to exploit the weird policies people try and make the IdP apply. A common example of that is when managers try and force us to deploy "simple" rules based on user affiliation or role, and are totally incapable of understanding that roles overlap routinely.<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>