<div dir="ltr">On Thu, Aug 22, 2013 at 5:43 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 8/22/13 6:52 PM, "Brewer, Edward L" <lee.brewer@Vanderbilt.Edu> wrote:<br>
<br>
>David,<br>
><br>
>The case that is cited that is considered the ³scariest² is the following.<br>
><br>
</div>>User A is in both LDAP1 and LDAP2Š the data is the same.<br>
>User A is terminatedŠ. Login access to LDAP1 is disabledŠ user¹s<br>
<div class="im">>information is still there.<br>
><br>
>User A logins into an application and is able to auth to LDAP2 and gain<br>
</div>>accessŠ plus since they are in LDAP1 their attributes will be there to<br>
<div class="im">>pass on to the<br>
> app<br>
><br>
>So I at least need a way of not sending the attribute information from<br>
>LDAP1.<br>
<br>
</div>That's what I meant by authn == authz.<br>
<br>
The way you're meant to do this is by passing an attribute about their<br>
permissions to the various systems, affiliation or entitlements or<br>
something else, but not by excluding information to simulate a lack of<br>
access.<br>
<br>
Essentially you have apps that apparently don't do any authz, and now are<br>
being told to fix that for them, when in reality it's likely they don't<br>
even agree with your central IT's concerns about access or that people in<br>
the LDAP2 case shouldn't have access. But in any case, it's their job to<br>
do authz, not the authentication system's job. And when you try and do it,<br>
you limit your ability to evolve your system, and you end up with policies<br>
that don't actually meet the needs of the apps because they're too broadly<br>
applied, so you end up carving out exceptions.<br></blockquote><div><br></div><div>Exactly what Scott says! As I point out to my SPs. The IdP does NOT do Authorization. In fact, it totally sucks at that and attempts to shoehorn an AuthZ decision into the IdP always winds up with messy results. What it is good at though is sending attributes to the SP which is far better at making the decision to AuthZ the user. </div>
<div><br></div><div>Dave</div><div><br></div></div>-- <br>David Langenberg<div>Identity & Access Management</div><div>The University of Chicago</div>
</div></div>