Grouper Users - Open Discussion List

[Chris Hyzer <>]

> Ok, I undestand. In fact I hoped that somme logic would be shared and so could be reused but if it is not the case I

> will follow your sugestion.

The logic which can be reused is the addMember web service.  If you don’t know which members are to be added or deleted, then just send the whole list to the web service, and it will only add or remove the ones which are different.  If using grouperClient (which is a front end for web services), you can put the list in a file, and tell grouperClient to replace with that file, and it will do everything for you.  You shouldn’t need to do much on your side.  Let me know if you need help getting it working

 

Kind regards,

Chris

 

 

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

 

Chris Hyzer a écrit :

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

 

Thanks for your proposition Chris, but...unfortunately I am afraid that my english is too limited.

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. 

Yes, you are right: the ldapsync client would push the changes to grouper.

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

Ok, I undestand. In fact I hoped that somme logic would be shared and so could be reused but if it is not the case I will follow your sugestion.

Thanks,
Arnaud.

 
Thanks,
Chris

 

 

 

 

From: Arnaud Deman []
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