Context Check Intercept for AuthZ

[Andrew Morgan]

On Thu, 30 Mar 2017, Cantor, Scott wrote:

> On 3/30/17, 12:25 PM, "users on behalf of Schwoerer, Brad" 
> <users-bounces at shibboleth.net on behalf of schwoerb at uww.edu> wrote:
>
>> I am looking to create a directory based (LDAP) way to deny certain 
>> individuals to certain entityIDs.  It seems there are two approaches. 
>> 1) Use LDAP groups with an attribute that has the SP entityID and 
>> membership of people that are NOT allowed access to the SP.  2) A 
>> multivalued user attribute with the entityIDs that the user is not 
>> allowed to access.  The first approach has the benefit that it is 
>> easier to delegate group membership than managing a shared attribute 
>> for an individual.  The second approach has the benefit of easier to 
>> see what a user can't access.
>
> I think those are artifacts of how you happen to reflect the information 
> in LDAP, but the solution really depends on the pieces you have. OSU for 
> example today has nothing, so there's nothing I could do to manage this 
> information scalably and so I don't do it.
>
> In terms of the IdP, I think the answer is that you probably want to 
> have *an attribute* of some sort to make the determination with, whether 
> it's a whitelist or blacklist approach. Point being, have something you 
> can resolve for the principal in the normal course of looking up 
> attributes that you can implement a check against, so you don't need 
> anything custom. The context check interceptor can look at anything in 
> the request state, but really for a user-specific rule that's only going 
> to be attributes unless you implement a fancy script or Java class to do 
> something unusual.

Brad,

Here is the code we used (in 
flows/intercept/box-access/box-access-beans.xml):

     <bean id="ContextCheckPredicate" parent="shibboleth.Conditions.AND">
         <constructor-arg>
             <list>
                 <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="https://services.box.com/sp" />
                 <bean class="net.shibboleth.idp.profile.logic.RegexAttributePredicate"
                         p:useUnfilteredAttributes="true"
                         p:attributeId="ismemberof"
                         p:pattern="(?i)cn=eligible,ou=box,ou=app,ou=is,ou=org,ou=osu,ou=grouper,ou=groups,o=orst.edu" />
             </list>
         </constructor-arg>
     </bean>


You could invert the logic using a NOT if you wanted to blacklist people 
from a service.  Also, you could build an attribute "box_access" in 
attribute-resolver.xml and refer to it directly here.  That might be 
useful if you wanted more complicated logic or a Scripted attribute.

Thanks,
 	Andy