Skip to Content.
Sympa Menu

grouper-users - RE: Grouper Loader dynamic groups and LDAP (cf Grouper v1.4.0 now available)

Subject: Grouper Users - Open Discussion List

List archive

RE: Grouper Loader dynamic groups and LDAP (cf Grouper v1.4.0 now available)


Chronological Thread 
  • From: Chris Hyzer <>
  • To: "" <>, "" <>
  • Cc: Tom Barton <>
  • Subject: RE: Grouper Loader dynamic groups and LDAP (cf Grouper v1.4.0 now available)
  • Date: Tue, 6 Jan 2009 10:14:54 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

Maybe we need to have a phone conversation about this if we aren’t making progress… Let me know and we can schedule something.

 

The grouper loader is a “pull” mechanism where it decides when to operate, and will retrieve all groups/memberships from db/ldap/wherever, and make the adjustments in the grouper registry.

 

What your picture looks like (if the arrows mean that communication is initiated) is a “push” architecture, where the ldapsync and ldapreplicat will know there is a change in ldap and push the change to grouper.  If this is not the case, maybe a sequence diagram would help.  Anyways, if this is how it will work, then the ldapsync or ldapreplicate should just use the grouper client or your own web services client, and send the new group list to grouper web services, and grouper web services will see which members are new and update the group if and where necessary.  In this case you don’t need anything in the grouper loader.

 

The grouper loader is only needed when it schedules things (any daemon job really [e.g. daily report], but especially jobs which update group membership).  If something else is firing (e.g. a trigger off of something else), then web services should be used

 

Thanks,

Chris

 

 

 

 

From: Arnaud Deman [mailto:]
Sent: Tuesday, January 06, 2009 6:07 AM
To: Chris Hyzer;
Cc: Tom Barton
Subject: Grouper Loader dynamic groups and LDAP (cf Grouper v1.4.0 now available)

 

Hi,

As I am not sure to be very clear, I have made a scheme of the general arcitecture (which is very simplified ;-) ).

I have not looked at the Grouper Loader API yet, so I may be completely wrong but what I imagined was to use the GrouperLoader:
- To create dynamic groups, with a custom loader to retrieve the members (#1or may be #3 in your list). 
- To update the groups. For this case only the "sync up" functionalities of the Grouper Loader would be used.

The main objectives of the architecture are :
- To support a big number of groups: that's why I suppose that a notification system would be more adapted for us.
- To be usable with different SI architectures (for our partners). Only the notifier part would have to be rewrite. For instance, we could imagine a notifier based on a persistent search instead of LDAPSync.

The main responsability of what I called "Dynamic Groups Manager" would be to determine the affected groups (which is not staightforward). It would be beside the GrouperLoader API and the LDAPSync client would be an external process.

Then the groups are used in two ways :
- via a custom web service when the groups hierarchy is needed. This is the case for the uPortal group store we developped.
- via ldap for the most part of the applications.

Regards,
Arnaud.

Chris Hyzer a écrit :

The loader runs on a specified interval or cron, then will poll the external system and grouper itself both for full group lists, and sync up grouper with the differences.

 

The interface is not yet written, but perhaps we need a few different types.  Here are some examples of what they could be:

 

Custom simple loader (one group):

public List<SubjectLookup> externalGroup();

SubjectLookup would have id, identifier (mutuallyexclusive), and sourceId (optional)


Custom list loader (multiple groups):

public List<GroupSpec> externalGroupList();

Then GroupSpec would have: groupName, groupDisplayName (optional), groupDescription(optional), List<SubjectLookup>


Custom loader job (just do whatever you want):

public void run();

 

 

I don’t really understand how yours would work.  Is it a job which polls LDAP for diffs, and just moves those diffs into Grouper?  (#3 above).  Or is it a process which does not run inside the loader, which needs to send diffs to Grouper (Shilen, doesn’t Duke do something like that?)  You could use web services and the grouperClient for that or a web service with your own client…

 

Also, where does the group data go once inside grouper?  Back to a different LDAP?  Out to web service clients?

 

If you can give a more explicit and detailed use case that would be great.

 

Thanks,

Chris

 

From: Arnaud Deman []
Sent: Monday, January 05, 2009 1:26 PM
To:
Cc: Chris Hyzer; Tom Barton
Subject: Re: [grouper-users] Grouper v1.4.0 now available

 

Thanks for your answer Chris,

First some precisions about our context:
we are using grouper with an adaptation of uPortal which will be deployed for a hundred of establishments.
In this context we have the need for dynamic groups (There was a thread: "Dynamics groups in grouper" in the grouper-dev list ten months ago).

Because of the very important number of groups, my first idea was to trigger the update in grouper when change occur in our LDAP.
This could be done with an implementation of  LDAPSync client.

As it is quite an important development, I wanted to see first if the Grouper Loader in association with  the LDAP dynamic groups overlay could be a solution. My two main questions are about the dynamic aspect and the effectiveness with a huge number of groups and users.

I think the possibility of using a custom implementation could be very interesting, even if we chose the first solution. Is there already a specification of the interface ?

Regards,
Arnaud.





Chris Hyzer a écrit :

Right now it is only databases, but the way it is setup is flexible, so we could easily define a new loader type for ldap.  I should also put in a custom type where users can provide their own implementation.
 
Anyways, for ldap, would this work?  If not, let me know exactly how you want it to work.
 
Specify the ldap url (which could be ssl), and the user/pass, and the location of the group object (or objects if list of lists), and the name of the multi-valued member attribute.  Perhaps also the subject source id.  The list of members should be subject identifiers or ids.
 
When do you need this by?  1.5 ok in spring?  Or sooner (1.4.1?)
 
Thanks,
Chris
 
  
-----Original Message-----
From: Arnaud Deman []
Sent: Monday, January 05, 2009 10:16 AM
To: 
Cc: Tom Barton
Subject: Re: [grouper-users] Grouper v1.4.0 now available
 
Hi everyone,
 
With the Grouper Loader, is it possible to use an LDAP as an external
source or is it only designed for data bases ?
Thanks,
Arnaud.
 
Tom Barton a écrit :
    
Grouper v1.4.0 is now available.
 
This release has substantial new integration, automation, and
diagnostic capabilities, designed to enable deployers to do more with
less effort. Among much more, it includes:
 
* Grouper Loader, to automatically maintain groups and memberships
from external sources
 
      
 
 
 
  





-- 
 
Arnaud Deman
GIP RECIA
Parc d'activités les Aulnaies
151 rue de la Juine - 45160 OLIVET
Tel : 02 38 42 14 63 




-- 
 
Arnaud Deman
GIP RECIA
Parc d'activités les Aulnaies
151 rue de la Juine - 45160 OLIVET
Tel : 02 38 42 14 63 



Archive powered by MHonArc 2.6.16.

Top of Page