Grouper Users - Open Discussion List

[Julio Polo <>]

Are your groups really ad hoc or are they usually well-defined groups such as "employees of the office of information technology" with some exceptions?   This all hinges on your having something that automatically keeps these well-defined groups in sync.  For example, we have a group store where we offer app developers groups based on roles (faculty, staff, student), department, campus, system of record.  The groups in the group store are automatically updated as our IDM system gets data from the systems of record.

In this scenario, you would create a composite group:  ("employees of IT department" from the group store UNION "a group for manual inclusions") COMPLEMENT "a group for manual exclusions"  If a person leaves that IT department, he or she is no longer a member of the composite group, and therefore no longer has access to whatever is controlled by that composite group.  The tricky part is setting rules for dealing with the manual inclusions/exclusions.

-julio

Julio Polo
Enterprise Middleware, Identity and Access Management
Information Technology Services
University of Hawaii

On Fri, May 8, 2015 at 9:38 AM, Steven Carmody <> wrote:

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