grouper-study

["Coleman, Erik C" <>]

Aimee,

 

I like your work breakdown, it seems not far off from ours.  A similar goal we’ve had is to deploy “simple” and build out from there. We still have to build the processes around how we go about implementing functionality expansions in a regular, approved sort of way. That’s a bit abstracted from Grouper itself, but does anyone have any defined processes they could share? Just using an agile/scrum method?

 

One thing we still need to define is a standard delegation model/process for unit ownership of a folder for ad-hoc groups, as the use-case will come up quickly.  I’m picturing something like this:

 

1)      Department “basketry” wants a folder to manage their own groups.

2)      We create a folder under our “org” folder, call it “basketry”

3)      We create a default admin group called “folder-admins” within that folder.

4)      We assign the “Admin” privilege to the “folder-admins” group on the “basketry” folder.

5)      We populate a supplied list of people that are designated as admins on that folder in the folder-admins group.

 

Ideally, I would like a GSH script that automates this, as we have several hundred potential orgs that could request this. All I would need to supply is the org’s name, and the folks that are admins.

 

Thanks for your advice!

 

-Erik

 

 

 

 

 

From: [mailto:] On Behalf Of Aimee Lahann
Sent: Thursday, December 7, 2017 14:53
To: thompsow <>
Cc:
Subject: Re: U-M's TIER CSP Grouper Project Plan

 

Thanks, Bill. Your feedback is helpful.  

 

Do you have any documentation about your approach to Grouper security?  We are interested in learning about security in the context of limiting who can see which group members - especially in the case of course groups due to FERPA regulations. Security concerns are one of the reasons we are first exploring only departmental groups with staff members. We would be interested in helping to refine the security piece of the Deployment Guide.

 

How are you receiving your use cases/ policy requirements?  Are administrators in departments and/or application owners contacting you/your staff directly with requests?  Do you create the reference groups, build groups from them according to end-user requirements and then provide end-users an interface to include or exclude members to the group?  What are some of your use cases?  How did you begin? Could we talk to you more about this?

 

We would like to provide data-driven groups that are useful to users to create access control groups. Somehow we are a little stuck analyzing what reference groups are useful and how to offer groups to whom.  

 

Now you have opened the floodgates...

 

Thanks for your help!

Aimee

 

 

 

On Wed, Dec 6, 2017 at 4:32 PM, thompsow <> wrote:

HI Aimee,

 

The workstreams look reasonable. Our original implementation took about 3 months calendar time to implement a very specific use case (VPN access).  Since then, we have let our use cases/policy requirements drive any additional basis/ref groups that we have added.

 

I wouldn’t worry too much about getting all the basis/ref groups right at the start. These are fairly easily to refactor in Grouper. Recommend focusing on a specific access policy and start with that.

 

One thing you'll want to give some thought to is the security model for Grouper itself. This isn’t discussed much in the Grouper Deployment Guide. Might be an opportunity for us to refine that and include something in the next revision.

 

Best,

Bill

 

On Dec 6, 2017, at 3:19 PM, Aimee Lahann <> wrote:

 

Hi.

 

We would like to share U-M's plan for our CSP Grouper project with the Grouper cohort for feedback.  The Google document, TIER CSP Grouper Project Plan -DRAFT is currently a list of workstreams with milestones/tasks. Our original intent was to focus on identifying the work involved. Dependencies and order of operation are not yet noted. However, we have made time estimates for each workstream.

 

We would love to see others' Grouper project plans so we can learn how to improve our own.

 

(I apologize if you already received this email already.  I realized I originally sent it to the umich grouper study email group instead of the more recent Internet2 group email.)

 

Thanks!

 

Aimee Lahann

ERP Business Systems Analyst Senior

Identity and Access Management Team

University of Michigan

(734) 764-5641

 

 

 

--

Aimee Lahann

ERP Business Systems Analyst Senior

Identity and Access Management Team

University of Michigan

(734) 764-5641