Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Re: [grouper-users] Dynamics groups in grouper

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Re: [grouper-users] Dynamics groups in grouper

Chronological Thread 
  • From: Kathryn Huxtable <>
  • To: "Michael R. Gettes" <>
  • Cc: , Tom Barton <>, "GW Brown, Information Systems and Computing" <>,
  • Subject: Re: [grouper-dev] Re: [grouper-users] Dynamics groups in grouper
  • Date: Mon, 25 Feb 2008 09:56:41 -0600

At the moment it's LDAP-PC. What Brown has done is pretty good. I'm going to rip off the better parts.

I'm still doing performance tests on proof of concept code between vanilla LDAPPC, Brown's mechanism, a small improvement of Brown's mechanism, and the database idea.


On Feb 22, 2008, at 1:56 PM, Michael R. Gettes wrote:

I guess this begs the question of whether or not LDAP-PC is being
developed here or is it GENERIC-PC??? It sounds to me like you favor
GENERIC-PC. I think you can make a LDAP-PC without some additional
DB as an intermediary and still have it behave efficiently - which
I think is what folks at Brown have been up to if I understand correctly.


On Feb 22, 2008, at 14:47, Kathryn Huxtable wrote:

This is why I'm more database-centric and less LDAP-centric. I prefer to
master everything in a database and use LDAP only as a receptacle for
application queries.

At KU we provision a relational database with our IdMS data, including
the Grouper groups. We provision LDAP from that.

It's not so difficult to make triggers on tables create actions that
result in memberships changing, not that we've done that. KU uses the
loader approach, but who knows what the future will bring. Last I heard
they were looking at Sun Identity Manager.


On Fri, 2008-02-22 at 09:55 +0100, Arnaud Deman wrote:
Tom Barton a écrit :
Arnaud Deman wrote:
How many dynamic groups are you likely to need? Do they have to be
fully enumerated i.e. will you be expecting to list these
memberships or just test whether someone is a member?

A lot ! ;) We don't know currently exactly how many but it is
possible that we have to manage several thoushands (say between 3000
and 5000). And of course we would like to enumerate them ! We can't
do that with the PAGS groups and it was also one of our motivation to
extends Grouper for this purpose.

This is where dynamic and static groups mix about as well as oil and
water. You can't know that a subject is not a member of a dynamic
group until you evaluate the dynamic group membership filter on that
subject. So, to enumerate a subject's memberships will require that
all dynamic group filters are evaluated. If you have 5000 of those,
they'll all need to be evaluated every time you need to enumerate

This type of issue is what led us early on to maintain "flattened"
group membership information in grouper, ie, compute the indirect
membership effects of subgroups and composite groups as they are
created. That enables us to quickly enumerate memberships on demand. I
suspect that only a "pre-computed" approach to dynamic group
membership can scale to more than a handful of dynamic groups.

Something must update the attributes in the LDAP directory (or many
LDAP directories?) that appear in the filters defining your dynamic
groups. Can this LDAP updating process be used to trigger updating of
the flattened membership of dynamically-defined groups?


Effectively, this problem is more harder than I thought and I realize
that my approach may be naive...

Actually our problem is to determine which attributes have been modified
and ideally to trigger an update when it occures.
I may be wrong (I hope I am wrong), but I don't think this is possible
in a standard LDAP configuration.

Nevertheless, with another colleague, we still try to find a solution,
and there is perhaps a possibility. We have to consider it more but it
would be based on this points :

i) I can determine if the subject has changed or not,(most of the time
he won't ), even if I can't determine directly which attributes have
been modified.
ii) I know wich attributes are involved in the dynimics groups definitions.
iii) I Know the old (dynamics) memberships of the subject, in the
attribute isMemberOf.

We are looking if we are able to do what we want with this elements.
If we can't, we will have to use the loader approach. I answered to fast
to the advice of Gary, and eventually, a loader like the one descibed by
Kathryn may be our solution.


Archive powered by MHonArc 2.6.16.

Top of Page