Grouper Users - Open Discussion List

[Arnaud Deman <>]

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:

 

1.       Custom simple loader (one group):

public List<SubjectLookup> externalGroup();

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

2.       Custom list loader (multiple groups):

public List<GroupSpec> externalGroupList();

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

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