Grouper Developers Forum

[Kathryn Huxtable <>]

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.

-K

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.
>
> /mrg
>
> 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.
> >
> > -K
> >
> > 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
> > > > memberships.
> > > >
> > > > 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?
> > > >
> > > > Tom
> > > Hello,
> > >
> > > 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.
> > >
> > > Regards,
> > > Arnaud.