Grouper Users - Open Discussion List

[Brendan Bellina <>]

An interesting approach.

I particularly like the ability to retrieve all groups a person is in  
quickly. We find that it can take 20 seconds or more to determine  
which groups a person is in. I suspect this is due to the LDAP server  
checking for groups within groups, which is wasted effort since we do  
not allow that practice. We do populate a forward-reference attribute,  
but it isn't populated for all types of groups.  I haven't yet found a  
good solution for this, but it isn't a problem with your approach.

One possible downside of your approach is that some vendor  
applications expect a group to be a single object. Do you have any  
such applications, and if so how do you accommodate them? Do you also  
create a group object?

Another downside is that you have to store your group metadata (like  
the privacy attribute) in each entry, which means far more updates if  
you change your mind about a value. If you had a single group object  
that data would be in only one place.

And then one more downside is that you will have a lot of updates to  
do if you need to rename a group.  Especially if it is one of your  
groups with 190K members.

Regards,

Brendan Bellina
Identity Services Architect
University of Southern California

On Jan 31, 2008, at 1:22 PM, Steve Edgar wrote:

> Here at Cornell, we would like to deploy Grouper as a replacement  
> for our current central AuthZ system.  Group/member info would be  
> provisioned out to a LDAP directory server.
>
> Some requirements we have for the directory server are ...
>
> 1) Must support private groups
> 2) Must support very large groups (190K members)
> 3) All queries must be fast, regardless of group size
> 4) All clients must be able to use a simple and consistent query
>
> As posted previously, we've found using static groups allows us  
> achieve all but number 3 above.  To get around that problem, we've  
> looked into using "singleton pairs", which works like this ...
>
> Say we have a group named ...
>
> man.fred
>
> ... and it contains these members ...
>
>
>
>
> ... and it is a private group which can only be read by a client  
> authenticated as the Kerberos principal ...
>
>
>
> For the group man.fred, 2 entries (singleton pairs) would get  
> created in directory server ...
>
>
>
> groupname=man.fred
>
>
>
>
> groupname=man.fred
>
>
> Each cn entry is created by combining the group name and a member.
>
> Quick disclaimer... I made up the groupname attribute.  Whatever  
> attribute name is appropriate would go there.
>
> To support private groups, we have an ACI which checks the Kerberos  
> principal of the authenticated client against  
> cornelledugroupreadpriv.  An anonymous bind can not read a private  
> group.
>
> A client can make the 3 simple queries we need ...
>
> 1) Check for membership.  To find out of  is a  
> member of man.fred, search for ...
>
>
>
> Or, search for ...
>
>
>  and groupname=man.fred.
>
> (I am not a directory person, but I am assuming the second search is  
> slower.)
>
> 2) List groups for a member.  To list all groups for  
> , search for all entries which contain ...
>
>
>
> ... and return each groupname that matches.
>
> 3) List members in a group.  To list all members in a group, search  
> for ...
>
> groupname=man.fred
>
> ... and return each hasmember that matches.
>
> One drawback is this approach uses a lot of entries.  However, our  
> testing shows all 3 queries are fast, regardless of group size.
>
> We realize another drawback is we would have to do our own  
> provisioning from Grouper to directory server.
>
> We are interested in what other folks think of using this "singleton  
> pairs" approach.
>
> -- Steve.