grouper-users - Re: [grouper-users] RE: Priv Hook?
Subject: Grouper Users - Open Discussion List
List archive
- From: John Gasper <>
- To: grouper-users <>
- Subject: Re: [grouper-users] RE: Priv Hook?
- Date: Thu, 24 Sep 2015 15:35:57 -0700
Hey Chris, Would it be possible to get the Grouper artifacts for 2.2.2. pushed to maven central? If possible its be nice to get the UI libraries there as well. Thanks, John -- John Gasper IAM Consultant Unicon, Inc. PGP/GPG Key: 0xbafee3ef From: <> on behalf of John Gasper <> Date: Thursday, September 24, 2015 at 9:40 AM To: Chris Hyzer <>, grouper-users <> Subject: Re: [grouper-users] RE: Priv Hook? Thanks Chris. -- John Gasper IAM Consultant Unicon, Inc. PGP/GPG Key: 0xbafee3ef From: <> on behalf of Chris Hyzer <> Date: Wednesday, September 16, 2015 at 8:25 AM To: John Gasper <>, grouper-users <> Subject: RE: [grouper-users] RE: Priv Hook? I tweaked and added your two hooks into 2.2.2+, and there is a method to easily see if a group is being deleted, and a method to walk up the folders to check
to see if an attribute is assigned and cache the results. Included is some GSH to easily test this out. Assign self opt out priv https://bugs.internet2.edu/jira/browse/GRP-1197 Assign self read priv https://bugs.internet2.edu/jira/browse/GRP-1198 I would like to hold off on the subject customizer though I put in a note to revisit that… https://bugs.internet2.edu/jira/browse/GRP-1199 Thanks, Chris From: []
On Behalf Of Chris Hyzer I think we would need a patch for this… assuming that delete group is the only case you need
J want to add a jira? From: John Gasper []
So ran into an issue. The Veto Hook that prevents the OptOut priv’s removal is blocking the group from being deleted. Is there anyway for the membershipPreRemoveMember()
hook code to determine whether the delete is independent or if it is being removed by another action? Thanks, John -- John Gasper From:
<> on behalf of John Gasper <> Hi Chris, The basic/essential code is here: package net.unicon.middleware.grouper.groupHooks; And package net.unicon.middleware.grouper.membershipHooks; Still need to add the code to limit to a stem or use attributes to identify stems, but that is trivial… I think. — John Gasper From:
Chris Hyzer <> I think a generic hook (or rule)/attribute for this would be a good idea. Did you end up implementing this? Is there code you can share? Thanks Chris From: John Gasper []
One more similar scenario that I’d like to get your thoughts on. By using an attribute at the stem (and essentially be inherited by all child stems) level or on a group, grant the groups opt out to “self”, so users within this
part of the tree can always remove themselves from a group. We were going to using a hook to add the “optout” for self priv to the group if the stem or any part of the its tree has the attribute, and a second hook that prevents an group admin from removing
the priv. Thoughts on that? I think what we are seeing from schools is a desire to apply inherited permissions that can’t be changed by a stem or group admin. Similar to how the Windows
permissions can work. Thanks, John -- John Gasper From:
<> on behalf of John Gasper <> Yes, I think we can commit to doing testing with this. Thanks, John -- John Gasper From:
<> on behalf of Chris Hyzer <> If you have READ then you automatically have VIEW, so you don’t have to assign both. Also, I think you might have performance problems with this on large registries… I looked in the code and to add the ability to have a READONLY and VIEWONLY
wheel group would not be a lot of changes. I can do some testing, but if you can also test that would be great. Is that something you are interested in? Thanks, Chris From: John Gasper []
At the end of the day, we want a read-only “wheel” group… In other words a group whose members can view, but not change all groups and their memberships. The
proposed method of implementation is to use a post hook at give “view" and “read" to a newly created group… and prevent “view" and “read" from being removed from a group (except perhaps by someone in the Wheel group). -- John Gasper From:
<> on behalf of Chris Hyzer <> You should be able to use a membership hook, since privileges are implemented at memberships. The list type is “access”, and you can see which priv it is,
and who is removing it, and veto it. If you write up exactly what you are doing I can look into making the grouper “rules” more full featured since these types of things should be easily accomplished with rules. Thanks, Chris From: John Gasper []
There specific case I’m working on is this… We are assigning privs (allow specific group to read and view) to new created groups via a hook. That part is great.
We don’t want Group Admins to be able to remove that priv. -- John Gasper From:
<> on behalf of Chris Hyzer <> Yes, can you tell me more info about what you want to do?
J Thanks, Chris From:
[]
On Behalf Of John Gasper Is there a hook to veto the assignment/deletion of a privilege? -- John Gasper |
- Re: [grouper-users] RE: Priv Hook?, John Gasper, 09/01/2015
- Re: [grouper-users] RE: Priv Hook?, John Gasper, 09/02/2015
- RE: [grouper-users] RE: Priv Hook?, Chris Hyzer, 09/03/2015
- RE: [grouper-users] RE: Priv Hook?, Chris Hyzer, 09/16/2015
- Re: [grouper-users] RE: Priv Hook?, John Gasper, 09/24/2015
- Re: [grouper-users] RE: Priv Hook?, John Gasper, 09/24/2015
- Re: [grouper-users] RE: Priv Hook?, John Gasper, 09/24/2015
- RE: [grouper-users] RE: Priv Hook?, Chris Hyzer, 09/16/2015
- RE: [grouper-users] RE: Priv Hook?, Chris Hyzer, 09/03/2015
- <Possible follow-up(s)>
- Re: [grouper-users] RE: Priv Hook?, John Gasper, 09/02/2015
- Re: [grouper-users] RE: Priv Hook?, John Gasper, 09/02/2015
Archive powered by MHonArc 2.6.16.