Grouper Developers Forum

["caleb racey" <>]

Newcastle's main use case for notification is provisioning into access
control systems for wikis etc. At present we take a polling approach
where cron'd scripts check for updates in group memberships and
propagate the changes. This works but does result in a usability issues
due to the delay in updating systems. With notification we could move to
a model where change get propagated immediately. 

For tools like sympa (mailing list manager) they already have SOAP
servers that would allow us to propagate a group membership change into
the sympa mailing lists by firing off a SOAP message on notification of
change. Many apps are not what the comanage project calls "well behaved"
and would take a large amount of effort to adapt to pulling user groups
from LDAP. We therefore do have to provision these apps with group data
and notification of change would enable this.

We would like the audit trial element but for us the enhancements to
application provisioning is what would give us the most direct benefit.


>-----Original Message-----
>From: Cramton, James 
>[mailto:]
>Sent: 28 May 2008 14:45
>To: Tom Barton; Grouper Dev; 
>
>Subject: RE: [grouper-dev] hooks and notifications
>
>Brown has 2 main use cases where we'd like to use hooks or
notifications
>to provide additional functionality:
>
>1. The most important is real-time LDAP provisioning. We want to be
able
>to start an LDAP provisioning process (not necessarily LDAPpc) upon
>particular changes to group membership, name, or attribute changes. For
>performance reasons, the provisioning process will need to know what
>limited set of groups to change--which probably amounts to custom code
>identifying the lowest level group and all parents/grandparents whose
>membership (mainly) may be impacted by the change.
>
>2. A secondary need is for enhanced audit logging, particularly for
>certain high value events, TBD.
>
>Them's our 2 cents.
>
>
>James Cramton
>Lead Programmer/Analyst
>Brown University
>
>401 345 9795
>
>