<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 3:56 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">Keith,<br>
<div class="im"><br>
<br>
>Scott's attitude is correct here. The IDP's job is authentication and attribute release, authorization belongs to the SP.<br>
<br>
>We've recently run into this because we want to open up our IDP to do attribute release for users outside of our enterprise OU in Active Directory. This means that >guest and test users, created on the fly by anyone authorized to do so in their own OU of Active Directory (which is a well-controled set relatively speaking) could >authenticate to our IDP. Our Security staff wisely asked us to ask all SP administrators first what authorization measures they had in place, and we caught a couple >who would have been burned.<br>
<br>
>If an SP is letting anyone in who can Shib authenticate, that's their business. But if you want to make the best usage out of the IDP, your SP administrators need to take >responsibility for authorization.<br>
<br>
</div>Ok... Now I understand better what Scott was saying.. authentication == authorization... Maybe I am a little obtuse...<br>
<br>
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 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 inadvertent access to an application... So, maybe just having JAAS configured with both without creating a new login handler is adequate<br>
</blockquote><div><br></div><div>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 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 the death of the holder, the conversation quickly moves from generic unspecific concerns to a more productive conversation on how they can leverage the IAM infrastructure to automatically grant/revoke access to apps they're concerned about.</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>