Question on Login Handlers

Wessel, Keith kwessel at illinois.edu
Thu Aug 22 17:33:57 EDT 2013


Scott's attitude is correct here. The IDP's job is authentication and attribute release, authorization belongs to the SP.

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.

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.

Keith


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, August 22, 2013 4:26 PM
To: Shib Users
Subject: Re: Question on Login Handlers

On 8/22/13 4:33 PM, "Kevin P. Foote" <kpfoote at iup.edu> wrote:
>
>I think Chris is right on the front side.. your LDAP2 specific app could
>request a special handler. But, the PreviousSession handler is where
>things run into issues and your LDAP2 group will have access to stuff
>they should not.

The handler won't run if you're using specific AuthnContext classes in the
request from the special apps.

You can't do any of this properly unless you configure the SPs, and in
that case, you should simply be using attributes.

The OP is in for a world of pain here and should simply tell them he'll
supply attributes as needed to drive policy and require appropriate
policy. This is authn == authz. It seems to be like smallpox; seemingly
eradicated but now coming back due to a rise in new security staff coming
from apparently questionably competent backgrounds.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list