Question on Login Handlers

[David Langenberg]

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.

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.

Dave


On Thu, Aug 22, 2013 at 4:52 PM, Brewer, Edward L <lee.brewer at vanderbilt.edu
> wrote:

>  David,****
>
> ** **
>
> The case that is cited that is considered the “scariest” is the following.
> ****
>
> ** **
>
> User A is in both LDAP1 and LDAP2… the data is the same.****
>
> User A is terminated…. Login access to LDAP1 is disabled…  user’s
> information is still there.****
>
> ** **
>
> 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****
>
> ** **
>
> So I at least need a way of not sending the attribute information from
> LDAP1.****
>
> ** **
>
> ** **
>
> Thanks,
> Lee****
>
> ** **
>
>
>
>
> ****
>
> >Ok... Now I understand better what Scott was saying.. authentication ==
> authorization...   Maybe I am a little obtuse...
>
> >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
> ****
>
> ** **
>
> >>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.****
>
> ** **
>
> Dave****
>
> ** **
>
> --
> David Langenberg****
>
> Identity & Access Management****
>
> The University of Chicago****
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
David Langenberg
Identity & Access Management
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130822/32554c15/attachment.html