Grouper Users - Open Discussion List

[Steven Carmody <>]

thanks for all the suggestions !

It sounds, tho, like all the suggested approaches rely on the Admin of 
each Group "doing the right thing". That has me more than a little 
concerned ... we're now keeping accounts alive (ie they can 
authenticate) after separation for for anywhere from 180 months to 
lifetime for much of our population; I'd like to find an approach that 
didn't rely on all the Admins doing the right thing.

This problem strikes me as being very similar to the Rulesets inside our 
IDM system that already drive all of the Provisioning to down stream 
systems. Those Rules are triggered by a wide variety of "changes" on the 
user record in the Person Registry. I'd like many (or most) of the 
changes that trigger a reevaluation of provisioning and 
rights/privileges to potentially trigger a reexamination of adhoc groups.

On 5/8/15 12:43 PM, David Langenberg wrote:
> We created a Group Type of Closure which admins can use to ensure that
> ad-hoc memberships are removed upon finalization of our account closure
> process.  Note, this doesn't help at all with the changing-department
> problem, just the final termination problem.  We encourage folks to
> intersect with our departmental groups to help catch those cases.
>
> Dave
>
> On Fri, May 8, 2015 at 9:39 AM, Chris Hyzer 
> <
> <mailto:>>
>  wrote:
>
>     We have a few options at Penn:
>
>     1. Intersect the employee group for auto-removal
>     2. Rule on employee group for auto-removal or auto-end date in the
>     near future
>     3. Rule on org list so if removed from org due to leaving Penn or
>     switching orgs:
>              - remove from group
>              - -or- send email so someone can review
>     4. There is a deprovisioning process where one step is for a Group
>     administrator to review memberships/privs and remove all but ones
>     that are needed
>
>     I could imagine a Grouper rule like #3 above where if someone
>     changes orgs or is removed from all orgs that it determines groups
>     which aren't exempt from the process which have the person as an ad
>     hoc member, puts an end-date on membership (few days?) and emails
>     the UPDATERS/ADMINS of the group letting them know they can remove
>     the end date if they like...
>
>     Chris
>
>     -----Original Message-----
>     From: 
>
>     
> <mailto:>
>     
> [mailto:
>     
> <mailto:>]
>  On Behalf Of Steven
>     Carmody
>     Sent: Friday, May 08, 2015 9:41 AM
>     To: Grouper-Users
>     Subject: [grouper-users] adhoc group memberships, what to do when
>     IDM Roles change
>
>     Hi,
>
>     We've delegated to Depts the authority to create and manage adhoc groups
>     to meet their local needs. We're now trying to figure what to do when a
>     "significant" change occurs in a person's relationships with Brown, and
>     their Roles. Examples could include a staff person moving to a new job
>     in a different dept, or a student becoming an alum (we now support
>     lifetime accounts for students/alumns).
>
>     We also allow people to authenticate for 18 months after separating from
>     Brown, but remove all of the privileges that we know about (except being
>     able to login to the HR/payroll system in order to obtain a W-2). "Doing
>     something" about adhoc group memberships would be part of removing
>     privileges.
>
>     Our current best thought (which isn't really very good) is to have the
>     IDM/Person Registry/Provisioning Rules "tell" a process what change has
>     occurred. That process would obtain all the adhoc groups that this
>     person is a member of, and send an email to the owners of each group and
>     the person saying that unless a certain action is taken by a certain
>     date the person will be removed from the group (default is to remove).
>     (Note -- people have a number of group memberships based on their
>     affiliation and role; as their status in the relevant Business system is
>     updated these memberships will be changed automatically; I'm only
>     worried about adhoc memberships.)
>
>     We expect that other schools are already starting to encounter this
>     problem, tho, and we're interested in hearing how other campuses are
>     approaching this situation.
>
>     thanks in advance !
>
>
>
>
> --
> David Langenberg
> Identity & Access Management Architect
> The University of Chicago