Grouper Users - Open Discussion List

["Crawford, Jeffrey" <>]

Cheers Chris!!!

 

From: "Hyzer, Chris" <>
Date: Sunday, March 17, 2019 at 1:22 AM
To: "Black, Carey M." <>, "Crawford, Jeffrey" <>, "" <>
Subject: RE: [grouper-users] Veto or Prevent user from adding themselves to a group

 

This is done:

 

grouper_v2_4_0_ui_patch_18

 

https://spaces.at.internet2.edu/display/Grouper/Do+not+allow+someone+to+add+themself+to+a+group

 

https://bugs.internet2.edu/jira/browse/GRP-2064

    

Thanks

Chris

 

 

From: Black, Carey M. <>
Sent: Thursday, March 07, 2019 4:50 PM
To: Crawford, Jeffrey <>; Hyzer, Chris <>;
Subject: RE: [grouper-users] Veto or Prevent user from adding themselves to a group

 

Jeffrey,

 

What I described is a variation on what the “Include exclude and require groups” type functionality that exists in grouper. ( Just a different flavor/function. ) ( And maybe the Template feature could be a target to implement this as well… )

 

If the general pattern is acceptable, then maybe the user “implementing it” could start with a “normal group” (AKA: “Can Access Screen”) then set an attribute, push a button, etc.. to trigger the conversion. The hook could do the work of expanding that single group into the N groups in the pattern below.

                Yes, the users would need to know how to use the groups too. However the mechanical part of converting one to the others could be “magic” to the user.

 

                I think the more interesting question is this:

                                Do you think the user’s would not be able to understand the groups that would be produced and how to use them?

 

 

And frankly… if the user can “add a constraint” ( in grouper) then they can likely remove it too.

                However, the hook (and I would think a template too) could be designed in a way to prevent anyone but a grouper admin ( by default ) from being able to alter the memberships of the composites (and relevant structures created) after the conversion. So it can be a “one way trip” if it is designed that way.

 

 

Hope that helps.

 

--

Carey Matthew

 

From: Crawford, Jeffrey <>
Sent: Thursday, March 7, 2019 12:37 PM
To: Black, Carey M. <>; Hyzer, Chris <>;
Subject: Re: [grouper-users] Veto or Prevent user from adding themselves to a group

 

Hi Carey,

 

Yes I agree there are ways to do this, however the ultimate solutions is to hand off this construction to another department where this complexity probably wouldn’t be welcome (Although if Chris says he won’t do this then that’s where we are). Plus we would be talking about at least 400 groups like this (Might even expand since grouper can go down as many levels as we want).

 

To your last point, I’ve pointed out that a person adding themselves to a group would be audited, but there was concern that it shouldn’t happen in the first place. I really think that the current system was built to handle the situation in this way and there is a desire to not “remove” any current functionality for a perceived laps in security. Most people think that our Audit and Advisory were the original group to make that assertion that people shouldn’t ad themselves to a group on financial systems long ago.

 

In any case Chris seems open to creating a rule, and that would certainly work for us as long as it doesn’t make the code too complicated.

 

Thanks

Jeffrey C.

 

From: "Black, Carey M." <>
Date: Thursday, March 7, 2019 at 9:24 AM
To: "Hyzer, Chris" <>, "Crawford, Jeffrey" <>, "" <>
Subject: RE: [grouper-users] Veto or Prevent user from adding themselves to a group

 

Jeffrey,

 

I think I can see a way to do this without any “special code”. Picture this… ( Well try to…)

 

The final group that allows users to access the screen is called: “Can Access Screen”.

                Nether Bob nor Henry are given direct privileges to add members to “Can Access Screen”.

                Rather two “sub groups” are created for them to manage.

                                “Bob-Can Access Screen” ( managed only by Bob )

                                “Henry-Can Access Screen” ( managed only by Henry )

 

                Then… two more “deny groups” are created. Let’s call these two groups “NotBob” and “NotHenry”.

                                Yes, Bob is the only member in “NotBob” and Henry is the only member in “NotHenry”.

 

                Then… two composite groups are created.

                                “Bob-Allowed Users” =  ( “Bob-Can Access Screen” - “NotBob”)

                                And

                                “Henry-Allowed Users” = ( “Henry-Can Access Screen” – “NotHenry”)

 

                Last …

                 “Bob-Allowed Users” and “Henry-Allowed Users” are the members of “Can Access Screen”.

 

Now while that will work, it is a bit of “overhead” and does not scale well to an “N user” based system. (But it could be done.)

 

 

 

Another variation  on the theme with a two team slant:

 

Two groups that manage access to “Can Access Screen” that can not ultimately add themselves, but any member of the other set could add users from the other set.

 

                “Manages Access Screen” = “All users who can normally manage access to the screen” ( =  Bob and Henry, or others too…)

                “Special Managers Access Screen_list” = Users who can allow “Manages Access Screen” members to use the screen

                                                                ( Members can not be members of “Manages Access Screen”, done with a composite later. )

                                                                                       

 

2 groups that feed members up into the ultimate allowed set:

                “Normal - Allowed Users_list”:   Is managed by “Manages Access Screen”

                “Special - Allowed Users_list” (Is managed by “Special Managers Access Screen” )

 

3 Composites:

                “Special Managers Access Screen” = “Special Managers Access Screen_list” - “Manages Access Screen”

                                This prevents the “Special” approvers from overlapping with the “Manages Access Screen” approvers list.

 

                “Normal - Allowed Users” = “Normal - Allowed Users_list” - “Manages Access Screen”

                                This allows any user who is not in “Manages Access Screen”.

 

                “Special - Allowed Users” = “Manages Access Screen” *intersected* with “Special - Allowed Users_list”

                                This allows *only* members of “Manages Access Screen” who are allowed by “Special Managers Access Screen” to be added.

 

 

Finally the membership of “Can Access Screen” is set to:

                “Normal - Allowed Users” and “Special - Allowed Users”

 

I know that is a bit complicated… but I hope it makes sense.

 

Anyone see how that would not work?

 

 

I can also maybe see some code (AKA: a grouper Hook ) to try to prevent a user from adding themselves too. However, as Chris points out, it might be a bit complicated to mark a group and have the hook track down the “source group(s)” that is feeding up the membership. But maybe that could be done.

 

However, I generally think of “separation of duty” rules to try to prevent “collusion between coworkers” and other “lateral attacks” (unattended keyboard, shoulder surfing a password, etc…).  In other words, without controlling the distinction between who can add a “standard approver” from “any other approver” I think the value of that “separation” is even more dubious. ( JMHO )

 

--

Carey Matthew

 

From: <> On Behalf Of Hyzer, Chris
Sent: Thursday, March 7, 2019 10:55 AM
To: Crawford, Jeffrey <>;
Subject: RE: [grouper-users] Veto or Prevent user from adding themselves to a group

 

This is an interesting request for separation of duties.  It gets a little complicated though.  Someone could add a group to the group where the self is a member of the group being added.  Or an empty group could be added and then later the self could add self to the new empty group.  It would make things easier if the group did not allow groups to be added.  So do you want me to make a rule or hook that:

 

1. Vetoes if groups are added to group
2. Vetoes if self is added to group

 

Or do you want something else?  What version do you need this in and when do you need it?  I made a jira and cc’ed you.

 

Thanks

Chris

 

From: <> On Behalf Of Crawford, Jeffrey
Sent: Thursday, March 07, 2019 10:30 AM
To:
Subject: Re: [grouper-users] Veto or Prevent user from adding themselves to a group

 

It was pointed out to me that my question probably wasn’t specific enough 😊. So the following is the example of what we need:

 

So lets pretend Bob and Henry have been designated to manage access to a screen in a financial system. They are free to add people to view this screen about employees. Now one day Bob realizes that he needs access to this screen too. But management wants an error to show up if Bob adds himself to this screen access. Bob remembering that there is a policy that prevents him from adding himself now needs Henry to add Bob. That is fine because someone else added Bob.

 

Silly example I know but that is what is being asked.

 

Thanks

Jeffrey C

 

From: <> on behalf of "Crawford, Jeffrey" <>
Reply-To: "Crawford, Jeffrey" <>
Date: Wednesday, March 6, 2019 at 7:42 AM
To: "" <>
Subject: [grouper-users] Veto or Prevent user from adding themselves to a group

 

Hi,

 

Is there a way to allow a user to add members to a group except themselves? There is an application we are supposed to integrate with that has a policy that people must be added by someone else.

 

Thanks

Jeffrey