<div dir="ltr">Which is exactly the method I described earlier. Presumably, you have some kind of Agent account for your IdP on LDAP1 so the Attribute Resolver can resolve attributes. Also, somehow in your LDAP1 there is presumably something that indicates enabled/disabled so the LDAP server can decide whether to allow the BIND or not. From this you create and apply an Access Control Instruction to your attribute resolver's agent account in LDAP1 that says, "only allow users who are not disabled to be found if this agent searches for them". You're then done, if a user AuthNs successfully to the IdP on LDAP2, the disabled LDAP1 account won't be found & no attributes will be marshalled. The IdP will send your new app a successful AuthResponse and no attributes. <div>
<br></div><div>With that said, THIS IS COMPLETELY THE WRONG WAY TO DO IT. Your next conversation needs to be with every SP downstream of you to ensure that they're doing *something* in the way of Authorization. Even if you perform the above steps, an SP that just lets every single user in who happens to authenticate to your IdP will still be vulnerable to letting everybody from LDAP2 in. Let's not forget what happens if these SPs happen to also be in InCommon Metadata. Those apps with AuthN == AuthZ are now essentially public thanks to the likes of Protect Network & the upcoming Social Gateway.</div>
<div><br></div><div>Dave</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 4:52 PM, Brewer, Edward L <span dir="ltr"><<a href="mailto:lee.brewer@vanderbilt.edu" target="_blank">lee.brewer@vanderbilt.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">David,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The case that is cited that is considered the “scariest” is the following.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">User A is in both LDAP1 and LDAP2… the data is the same.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">User A is terminated…. Login access to LDAP1 is disabled… user’s information is still there.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">User A logins into an application and is able to auth to LDAP2 and gain access… plus since they are in LDAP1 their attributes will be there to pass on to the
app<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">So I at least need a way of not sending the attribute information from LDAP1.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks,<br>
Lee<u></u><u></u></span></p><div class="im">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<u></u><u></u></p>
</div>
<p class="MsoNormal"><span style="color:#1f497d">></span>Ok... Now I understand better what Scott was saying.. authentication == authorization... Maybe I am a little obtuse...<br>
<br>
<span style="color:#1f497d">></span>Well, actually we have not had a policy of authentication is equivalent to authorization. Many of our SPs have some level of access control that is
<span style="color:#1f497d">></span>driven by attribute information or other data. It looks I just need to review each SP to ensure that is true. There is a lot of people worried about an
<span style="color:#1f497d">></span>inadvertent access to an application... So, maybe just having JAAS configured with both without creating a new login handler is adequate<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d">>></span>Yeah, I get that too -- concern about inadvertent access. I use that to take the opportunity to ask them about the specific apps they're concerned
<span style="color:#1f497d">>></span>about & also educate them about our account lifecycle. Generally, once I mention that we never lock or close a credential until we're notified of
<span style="color:#1f497d">>></span>the death of the holder, the conversation quickly moves from generic unspecific concerns to a more productive conversation on how they can
<span style="color:#1f497d">>></span>leverage the IAM infrastructure to automatically grant/revoke access to apps they're concerned about.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Dave<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal">-- <br>
David Langenberg<u></u><u></u></p>
<div>
<p class="MsoNormal">Identity & Access Management<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The University of Chicago<u></u><u></u></p>
</div>
</div>
</div>
</div></div>
</div>
<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>David Langenberg<div>Identity & Access Management</div>
<div>The University of Chicago</div>
</div>