Grouper Users - Open Discussion List

[Kathryn Huxtable <>]

I'm working on something that uses triggers. I added a trigger to the
grouper_membership table to add a record to an action table when a record is
changed.

A background process polls the action table and ignores changes that don't
provision the external entity in question, e.g. LDAP groups, and makes the
change otherwise.

Because I'm writing this in Perl, there's a separate background process for
each type of provisioning. I don't want to hassle with conflicting Perl
modules, which has happened to me before. If I were writing in Java there
would be one process and each provisioning class would implement an
interface.

-K


On 10/12/06 4:07 AM, "GW Brown, Information Systems and Computing"
<>
 wrote:

> Hi aifei,
> 
> There is a project underway to produce a provisioning connector which will
> update LDAP with membership information from Grouper. A description of the
> aims of the project can be found at
> <https://filer.uchicago.edu/users/tbarton/public/jndi-conn-rfq-02.html>.
> 
> It is expected that an initial version will be ready in early November.
> 
> As for the Grouper API, given a Subject you can obtain a Member using
> MemberFinder:
> public static Member findByUuid(GrouperSession s, String uuid)
> 
> and given a member you can call:
> 
> Member.getGroups(), or Member.getMemberships().
> 
> You could try to iterate across all Subjects, find the memberships and
> write something to update LDAP, but in practice you probably want to only
> at Subjects which are members of groups which have changed. I would wait
> for the LDAP provisioning connector, but if you have specific requirements,
> as to how memberships are reflected in your LDAP repository, it would be
> worth discussing them on this list.
> 
> Regards,
> 
> Gary
> 
> 
> 
> --On 12 October 2006 10:50 +0800 "??" 
> <>
>  wrote:
> 
>> aifei
> 
> 
> 
> ----------------------
> GW Brown, Information Systems and Computing
>