Grouper Users - Open Discussion List

[Chris Hyzer <>]

This is a provisioning thing so the PSP is where it should go, as we add more modules it will be easier to do so.  Hopefully Dave can help make it easier J

 

Remind me how this works, does the PSP have one change log consumer for each module it is provisioning, or does it share one?  Seems like one per module is the requirement in this case…

 

Thanks,

Chris

 

 

 

From: Michael R. Gettes [mailto:]
Sent: Friday, March 15, 2013 9:40 AM
To: David Langenberg
Cc: Chris Hyzer;
Subject: Re: [grouper-users] grouper - box.com integration

 

We were just having a discussion yesterday around a related issue - when should something be a new change log consumer vs. some extension to PSP?  To me, PSP takes care of issues interacting within Grouper - like the changelog - and possibly other stuff.  Then the PSP extension (not sure of the right term here) can concentrate on doing the job it needs to do.  Proper thinking or not?

 

/mrg

 

On Mar 15, 2013, at 1:29, David Langenberg <>

 wrote:

...sounds like a new module for the psp

 

Dave

David Langenberg

Identity Management

The University of Chicago 

On Mar 14, 2013, at 10:06 PM, "" <> wrote:

I was thinking there would be a daemon in the loader, and a change log consumer that did the real timer part...

Chris

----- Reply message -----
From: "Michael R. Gettes" <>
To: "Chris Hyzer" <>
Cc: "" <>
Subject: [grouper-users] grouper - box.com integration
Date: Thu, Mar 14, 2013 3:51 pm

Chris,

 

Could you better describe what happens in step 4?  Is this a PSP thingie?  Is this something inside grouper, outside grouper?

 

thanks

 

/mrg

 

On Mar 13, 2013, at 4:07 PM, Chris Hyzer <>

 wrote:

I wrote a simple proof of concept box app that uses box’s API, so I am thinking of how Grouper – Box integration could work…

 

At Penn, our Box implementation has folders that are owned by users, and we don’t have any groups in Box (due to a security concern about Group admins, I don’t know the specifics).

 

Anyways, the way I see how it could work for us is:

 

1.       A Grouper Group admin (or Grouper Admin) adds an attribute to a group: boxEnable

2.       That attribute has value of the netId/userId, box role, and folder location, e.g. mchyzer_collaborator_testFolder

a.       Note: this could be validated with helpful error messages

b.      Note: this could be broken up into separate sub-attributes to make it easier(?) to use

3.       Grouper would make sure that the Grouper user assigning/changing that attribute/value are either a Grouper admin, or their user ID in the attribute value matches the netId.

4.       A real time process and periodic daemon would sync the users in the group with the users that the folder is shared with for that box role

 

Issues: would external users work?  Email addresses would need to match.  Some Penn users arent using their  account in Box, so they would have to use that account in box or we would need a user attribute for one-offs…  how does it work to transition this when people leave the group?  In box I think you delegate admin access to someone else, and the Grouper attribute could be edited to point to that user instead.  The person it is moving to would need to be a group admin, or the Grouper admin could do this.  This would only work for institutions who have agreements with box so that an admin app could manage their user account…  Grouper would be authenticating to box with an admin account that has control over the institution’s users.

 

Note: this would help for people who want a folder shared with a group.  Its not really intended for migrating a massive number of groups to box or something like that.

 

Would something like this be useful to people?  J  How else could it look?

 

Thanks,

Chris