Grouper Users - Open Discussion List

[Tom Barton <>]

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.

Tom