Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Thoughts on a very large group?

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Thoughts on a very large group?

Chronological Thread 
  • From: Tom Barton <>
  • To: Joy Veronneau <>
  • Cc: Grouper Users <>
  • Subject: Re: [grouper-users] Thoughts on a very large group?
  • Date: Fri, 11 Jan 2008 09:13:05 -0500

Joy Veronneau wrote:
Some reading via google indicates that the directory will indeed have problems with entries that have very large multivalued attributes. Suggestion is to use dynamic groups.

Not everything that can be represented as a group should be - it can be better to use an attribute value rather than a membership to convey a fact. I think that's often the case with course-grained affiliations, in particular. So, edupersonaffiliation=alumni (as an element of an ldap search filter, ie, a dynamic group) is a fine way of determining if a particular entry belongs to a member of the "alumni group".

So long as you don't have a need to do group math with alumni as a factor, I don't see why you'd need to go beyond traditional ldap usage for this particular semantic.

R1.0 - All group membership queries need to be the same format as far as the search filter and results received back are concerned. Receiving a URL from the directory (because cu.alumni is a dynamic group) or receiving "nsrole" for some queries would not be acceptable.

OK, so we could create a directory plugin that would look at each search coming into the directory and reformat the query if necessary, and reformat the results if necessary, and then we could use either a dynamic group or a filtered role.

We don't have any experience with dynamic groups, filtered roles, or directory plugins, other than some cursory tests with the groups and roles.

I guess I am looking for some advice here - does this approach sound reasonable? Would you pick dynamic group over filtered role for one reason or another? Are plugins a bad idea? Got a better idea?

Do you already support affiliation-based access management with ldap? Does R1.0 imply that must cease? Again, not everything that can be expressed using group semantics should be expressed in that way.


Archive powered by MHonArc 2.6.16.

Top of Page