Question on Login Handlers

[David Langenberg]

On Thu, Aug 22, 2013 at 5:43 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 8/22/13 6: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.
>
> That's what I meant by authn == authz.
>
> The way you're meant to do this is by passing an attribute about their
> permissions to the various systems, affiliation or entitlements or
> something else, but not by excluding information to simulate a lack of
> access.
>
> Essentially you have apps that apparently don't do any authz, and now are
> being told to fix that for them, when in reality it's likely they don't
> even agree with your central IT's concerns about access or that people in
> the LDAP2 case shouldn't have access. But in any case, it's their job to
> do authz, not the authentication system's job. And when you try and do it,
> you limit your ability to evolve your system, and you end up with policies
> that don't actually meet the needs of the apps because they're too broadly
> applied, so you end up carving out exceptions.
>

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.

Dave

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