Grouper Developers Forum

["Cramton, James" <>]

As for what we've been up to at Brown, I wouldn't say we've avoided the 
intermediary DB entirely. We used JVM memory to store the intermediary data 
structures that represent memberships of isMemberOf and hasMember, although I 
could easily be persuaded to use a DB for that as well, I suppose. We chose 
the JVM approach primarily because we'd already written half the code we'd 
need to provision LDAP in our QA application. But it would not surprise me to 
find a greater degree of flexibility possible with a DB driven approach, 
especially when it comes to triggering real-time LDAP provisioning from the 
DB.

It's worth noting that we did use a local SQL copy of our LDAP person 
registry to get around JNDI performance/scalability issues we experienced in 
Grouper 1.2.0. We were seeing LDAPpc's JNDI connection to our LDAP server go 
out to lunch after a couple hours of processing tens of thousands of records. 
Having a local SQL person registry also turned out to be a critical means of 
avoiding the issue that's in the bug list for the next version of Grouper, 
whereby you can't delete members that can't be instantiated because they no 
longer exist in the LDAP registry. As a result, we only ever add or modify 
records in our Grouper SQL person registry...when folks disappear from our 
LDAP registry, they are left in the SQL registry with a status of "deleted." 
That was ultimately a decision driven by 2 bugs or deficiencies, but looking 
back on it, we gain a number of benefits--performance and flexibility, 
primary--from having a local copy of our person registry, so I'm inclined to 
keep the design, even if the original issues in Grouper are resolved.

James

-----Original Message-----
From: Michael R. Gettes 
[mailto:]
 
Sent: Friday, February 22, 2008 2:57 PM
To: Kathryn Huxtable
Cc: 
;
 Tom Barton; GW Brown, Information Systems and Computing; 

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

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.
>>
>>
>>
>>
>