<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 12, 2014 at 11:15 AM, Tom Scavo <span dir="ltr"><<a href="mailto:trscavo@gmail.com" target="_blank">trscavo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, Jun 12, 2014 at 12:32 PM, Ian Rifkin <<a href="mailto:irifkin@brandeis.edu">irifkin@brandeis.edu</a>> wrote:<br>
><br>
> My question is if it's possible for the IdP to do some kind of authorization<br>
> for specific SPs…<br>
<br>
</div>Yes, for some use cases, this is the way to go. In the Library use<br>
case, for example, the campus is in the best position to determine if<br>
and when a user should have access to a library resource (according to<br>
whatever contract is in place), so it's not unreasonable for the IdP<br>
to send an eduPersonEntitlement that indicates whether the user should<br>
have access.<br></blockquote><div><br></div><div>Yes, I run into this occasionally from time to time. My response is it's impossible for me to block the user at the IdP, however, I can send you an attribute indicating if the user is allowed. We usually go 2-3 rounds, but eventually the vendors always find a solution that uses an authorizing attribute value.</div>
<div><br></div><div>Dave</div></div><div><br></div>-- <br>David Langenberg<div>Identity & Access Management</div><div>The University of Chicago</div>
</div></div>