Context Check Intercept for AuthZ

[Cantor, Scott]

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.

> It does appear that 3.4 will make this better, but we aren't there yet, and my deadline is before it would be released.

The thing I checked in yesterday (and implemented on OSU's dime, BTW) is just helpful if you have to juggle a number of diferent rules doing different kinds of checks and leading to different kinds of error rendering. If it's all one sort of rule leading to a "you're not allowed" page, that's pretty much the same work now.

I have some basic authz stuff today for one SP, and I need to add a custom error page for students with the FERPA flag set, so that's a totally separate sort of check and the change will make it easier for me to do that within the existing flow we ship and not have to throw another together.

-- Scott