Subject: Grouper Developers Forum
Re: [grouper-dev] More Fun With Large Groups - Singleton Pairs
- From: Brendan Bellina <>
- To: Grouper Dev <>
- Cc: Grouper Users <>
- Subject: Re: [grouper-dev] More Fun With Large Groups - Singleton Pairs
- Date: Thu, 31 Jan 2008 13:39:30 -0800
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.
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 ...
... 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 ...
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 ...
(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 ...
... 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.
- More Fun With Large Groups - Singleton Pairs, Steve Edgar, 01/31/2008
- Re: [grouper-dev] More Fun With Large Groups - Singleton Pairs, Brendan Bellina, 01/31/2008
Archive powered by MHonArc 2.6.16.