testing group membership

[Peter Schober]

* Jim Fox <fox at washington.edu> [2013-04-17 17:51]:
> > * Bennett, Steve <s.bennett at lancaster.ac.uk> [2013-04-17 13:49]:
> >> I think I need to store a flat copy of my group memberships in a
> >> database. Then it's a simple lookup for the first part, and I
> >> already have the second part working.
> >
> > I wouldn't take that lightly, that's another piece of infrastructure
> > that can break, can get out of sync, needs to be maintained for the
> > forseeable future, etc.
> > (But granted recursively resolving memberships on-access in the IdP
> > doesn't sound too tempting either.)
> 
> We do this all the time.  We have a REST API in front of an LDAP
> that is not flattened.  The API takes care of recursion.  We also
> have an attribute plugin that handles the API.
> 
> My point being that recursion at the IdP, or at least at the time
> of resolution, has not been a hinderance for us.
> 
> Grouper is our groups engine, but I've found effective membership
> queries directly to grouper take too long.  Around 400ms vs.
> about 40ms for the LDAP queries.

Thanks for the data points.

My comment wrt being cautious about running a database with flattened
menberships for the IdP to query (one more thing that can fail)
doesn't apply to institutions writing and implementing their own group
APIs ;)

Regarding Grouper: I would have expected Grouper to do the flattening
in/to LDAP so that the Shib IdP does not query the Grouper DB directly
but the Grouper-provisioned, flattened groups in LDAP?
Anyway, if you don't already have Grouper adding it to the mix solely
for flattening your nested groups is overkill.
I was just pointing out Libre Software that existed in this space.
-peter