Question on Login Handlers

[Brewer, Edward L]

Keith,


>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.

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

Thanks again,
Lee

-----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
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net