Grouper Users - Open Discussion List

["Black, Carey M." <>]

Chris,

 

Sadly the placement is relevant to how the groups are being used.

 

The basics for my needs are that the exceptions to the rule ( inherited permissions ) are smaller, and definable. While the rule is “open ended”.

 

Essentially ( in short form)

                in a folder there will be a set of N groups that need to be “restricted”. But the folder should allow others to add new groups at will.

 

 

To be fair I also long for the ability to:

                Allow some users to ( in a folder):

                                Create groups but not new folders.

                And other users to:

                                Create groups and folders.

 

 

So I really think that I need the hook based “additional access controls”. ( I think I can generally “skin this cat” via some attributes and hooks. )

 

--

Carey Matthew

 

From: Hyzer, Chris <>
Sent: Wednesday, January 23, 2019 11:24 AM
To: Black, Carey M. <>;
Subject: Re: Is it possible to block inherited privs on some objects?

 

Nope.  Can you organize your folders so that the inheritance is pure?  e.g. put a folder to the side that has the one-offs.  Otherwise if you inherit priv, I wouldnt change those afterwards with a hook.  You could do the whole thing outside of inherited privs if that what you mean.  Thanks, Chris

---

From: <> on behalf of Black, Carey M. <>
Sent: Monday, January 14, 2019 10:13:10 AM
To:
Subject: [grouper-users] Is it possible to block inherited privs on some objects?

 

Before I go invent something for myself....
        Is there an existing way to tag/restricted inherited privileges in Grouper?


I have a condition where generally I want to use inherited privileges on (groups/folders/attributes) but I also have some exceptions to that as well.
        A folder that should be "fully controlled" (read ADMIN) by GroupA. However, GroupB wants some groups/folders to exist in that folder and they don't want GroupA to be able to  make changes to them.
        NOTE: I am not concerned about GroupA having visibility to the objects. I am only concerned about preventing GroupA from being able to change the objects. ( all things like: object rename, object delete, member changes, attribute changes (values, Add/remove,etc....))

I am leaning toward making a set of hooks that add an additional "authorization check" before allowing any Stem, Group, Attribute, Membership event from completing.
        Attribute would have a "GroupName" value, or a list with a "requireOne, RequireAll" specification . If user making the change is not a member of "GroupName" then throw HookVeto with message.


Is there an easier way to achieve this?

Other thoughts?

--
Carey Matthew