Grouper Users - Open Discussion List

[Steven Carmody <>]

Thanks ! This has been an interesting conversation.

We've been following the model that people have described for many many 
years. We have reference groups fed from Business Systems; we have 
aggregate groups composed from those reference groups ("your bundles"). 
And we give every Dept and Center on the campus their own STEM, and 
start them out with People and Projects STEMs, and a standard set of 
people groups (initially populated from the reference groups). We 
delegate to the Dept the authority to manage their own groups. We have 
an applications/services STEM, STEMs under that for each distinct 
service, STEMS and groups as needed within each Service STEM. We 
delegate to the Service Manager the responsibility to manage the 
membership of their service eligibility groups. We have other reference 
groups (undergraduate concentrations, graduate student programs, a 
replica of the Workday Supervisory ORG structure, etc).

This has worked marvelously for us !

A couple of questions, tho:

-- increasingly, for fine grained access control, service managers are 
using dept-managed groups (eg for ACLs on firewall ports). The people 
managing the dept groups want to know "what can Jane do after I add her 
to this group?". (ie suddenly she can access a bunch of new machines) 
How do you present the set of service eligibility groups to a Dept Admin 
person in a way that they'll understand ?

-- grouper's set arithmetic capabilities are stupendous ! We couldn't 
live without them ! But, how do you explain all these include and 
exclude groups to an administrative helper (who is managing groups for a 
research project) ? Someone who has trouble with set arithmetic ... how 
do you hide all that magic from them ?

thanks !

On 3/2/17 9:29 AM, Waldbieser, Carl wrote:
>

> We are also doing this at Lafayette. Bill Thompson is actually
documenting an organizational strategy for Grouper in his "Grouper
Deployment Guide", and we are attempting to align our own Grouper
organization with that.
> To that end, every service has its own stem in our "app" folder. Each
> service may have one or more policy groups, each of which is a
> composite
of corresponding "allow" and "deny" policy groups.
> Reference groups from our "ref" stem can be used to create policies.
>
> We've also noticed that there are some cohorts that tend to get the
same access to multiple services. For these, we create what we are
calling "bundles" in our "bundle" stem. Each bundle gets its own stem
with "include" and "exclude" groups for the cohort.
> What differentiates a bundle from a reference group is that reference
> groups represent a fact. You *are* an employee of the College, or
> you're
not. Bundles are a cohort that have access to similar services. An
"Employee Services" bundle would naturally include the employees
reference group, but it may also include long term contractors, interns,
etc. This bundle can then be used to form access policies for services.
To answer the question, "What services does this bundle provide access
to?", you can simply choose the "This group's membership in other
groups" option and see all the "allow" policies of which the bundle is a
member.
> Thanks, Carl Waldbieser ITS Identity Management Lafayette College
>
> ----- Original Message ----- From: "Dave Churchley"
> <>
>  To: "Julio Polo" 
> <>,
> "Steven Carmody" 
> <>
>  Cc: "Grouper-Users"
> <>
>  Sent: Thursday, March 2, 2017 3:54:41
> AM Subject: RE: [grouper-users] what is a group authorized to do ?
>
> Yes, this is the method we use. We only have one of our base stems
> provisioned to AD. Groups under that stem are (supposed to be) names
> uniquely according to their purpose. Department groups and the like
> can be included as members of these application groups. I think this
> works quite well. It is, in fact, one of my seven principles of
> Grouper group administration
> (https://blogs.ncl.ac.uk/integration/2016/02/19/make-applications-groups-specific/)!
>
>  Dave
>
> From: 
>
> [mailto:]
>  On Behalf Of Julio Polo
> Sent: 01 March 2017 21:09 To: Steven Carmody
> <>
>  Cc: Grouper-Users
> <>
>  Subject: Re: [grouper-users] what is a
> group authorized to do ?
>
> I would advocate creating a group for each application/service (for
> each authz need).  Each of those application groups can include the
> same officially-sanctioned group for the desired department, but each
> group can have its own exceptions (inclusions and exclusions). To
> help track all such groups, you can create a special attribute to
> identify them or you could just put them all under one folder.
> -julio
>
> On Wed, Mar 1, 2017 at 9:41 AM, Steven Carmody
> <<mailto:>>
>  wrote:
> Hi,
>
> We've got a growing community of dept-based people taking advantage
> of delegated management of group membership. And we've got a growing
> community of service owners managing the membership of their service
> eligibility groups. They sometimes include dept-based-groups in their
> eligibility groups.
>
> We now have some dept-based group managers asking "before I add a
> person to group X, how can I find out the set of permissions and
> services are granted to that group?". A perfectly reasonable
> question.
>
> I can see that using service management groups might help to develop
> an answer -- I'm wondering if other sites have yet encountered this
> question, and what tools they are providing to users who want an
> answer ?
>
> thanks !