Grouper Users - Open Discussion List

[Bill Thompson <>]

Grouper affords a great deal of flexibility due to its mostly agnostic treatment of "groups". That flexibility can lead to unnecessary complexity and pain if not well managed. The Grouper deployment guide provides a model for a well managed deployment focused on attribute based access control as defined by NIST 800-162. The distinction between "labelled" groups is meant to mostly drive how they are used in practice within the GDG framework. 

If a basis group is showing up in access policy groups then it is a reference group by definition regardless of where it may be located in your grouper deployment.  Think of basis groups as the formerly deep dark opaque dependencies (arcane codes) or components that can be used to create institutional meaning cohorts/concepts. If you have a basis group that is showing up in natural language policy (NLP), then again, by definition it is a reference group.

Nothing in the model precludes composing reference groups from other reference groups or combination of reference groups and basis groups. The main thing is the expectation that reference groups are primarily used within the confines of Grouper to drive access policy groups (per service). A composed reference group is a "policy" in the sense that it has a definition which may be managed, but it is not an access policy group if following the GDG.

Grouper Security groups are a relatively new concept and not covered by the GDG. In practice these are meant to be an administrative access policy mechanism governing access to Grouper objects. "Best practice" is to not assign Grouper Privileges (aka administrative access to Grouper objects) directly to individuals, and instead use "security groups". These "security groups" could be constructed as access policy groups, ACLs, etc.

Best,

Bill

On Wed, Dec 16, 2020 at 8:57 AM Black, Carey M. <> wrote:

+1 for an abstraction between SOR and “Ref” groups. 

                However, I can also imagine “some code” to remove/add new Basis groups in mass too. I just would not relish the churn that would cause in the downstream systems too. (Shutter…)

 

 

 

At the end of the day, the “object type” in Grouper does not drive/restrict anything at the moment.

                If ( or when?) that changes then the answers here might change too.

                Are there any plans to support such a model/restrictions?

                                I would love it if “grouperSecurity” types were these things:

                                                Could only be set/removed by some “:etc:groupSecurityManagers” function/group.

                                                Conditionally required to be used in Privileges ( best implemented as some kind of rule/attribute marker on folders IMHO )

 

However, back to the general topic for all “object types”….

 

IMHO. It is “ok” for a “Ref” group to be other types as well.

    An “IAM Ref” group may even be a Policy group.  If you think about it from the IAM perspective.

    Example: An IAM business policy decides “who is a Student”.

                Which might be more than just people coming from the Student Information System (SOR/basis group(s)).

                It might include some kind of MOOC ( https://en.wikipedia.org/wiki/Massive_open_online_course ) subjects too.

 

    Example:

                If your application has “restricted data” then the users might be required to “bla, and bla, and bla”. And an IAM managed Ref group used to drive a https://spaces.at.internet2.edu/display/Grouper/Grouper+rules+use+case+-+Veto+if+not+eligible+by+folder rule that is forced to be applied to the application folder(s) would be a good way to run things….

 

 

 

And.. from a Grouper Privileges perspective….

    An IAM Ref group might be used to allow “OptIn”/”OptOut” which would make it also a grouperSecurity type too.

 

 

I am not sure there really are any “this can never be a ‘that’ type too” rules.

    However the general/normal patterns are the majority of the system.

 

-- 

Carey Matthew

 

From: <> on behalf of Andrew Jason Morgan <>
Reply-To: Andrew Jason Morgan <>
Date: Wednesday, December 16, 2020 at 12:47 AM
To: "Hoekenga, Liam" <>, Bill Thompson <>, "Hyzer, Chris" <>
Cc: Grouper Users <>
Subject: Re: [grouper-users] example basis and reference groups?

 

One reason to always create a reference group is that it allows IAM to modify basis groups without updating policy groups.  If you don't have a layer of abstraction between the loader job and the access policy, it is harder to make changes to loader jobs.

 

Andy

 

---

From: <> on behalf of Hyzer, Chris <>
Sent: Tuesday, December 15, 2020 12:04 PM
To: Liam Hoekenga <>; Bill Thompson <>
Cc: Grouper Users <>
Subject: Re: [grouper-users] example basis and reference groups?

 

[This email originated from outside of OSU. Use caution with links and attachments.]

One specific question though.  If a dept code 1234 is arcane but also institutionally meaningful, then is that a basis or a reference?  It is used in policies and has properties of both ref/basis.  My gut says reference since it is used in policies, but I could also see that as basis.  Maybe just pick one and doesnt matter that much since its a gray area?  I think classlists could be a similar situation...   course F2020_eng_cis_101 is both arcane and institutionally meaningful and is used in policies...  thoughts?  🙂

---

From: <> on behalf of Bill Thompson <>
Sent: Tuesday, December 15, 2020 12:37 PM
To: Liam Hoekenga <>
Cc: Grouper Users <>
Subject: Re: [grouper-users] example basis and reference groups?

 

Indeed. Policy groups should be service specific and backed up by reference/basis groups that can be used in any policy where they are needed.

 

 

On Tue, Dec 15, 2020 at 12:34 PM Liam Hoekenga <> wrote:

Hey Bill!

 

That would be fantastic.  I'll contact you off list.

 

> Generally we let access policy requirements drive what reference and basis groups we have.

We've been warned about making groups that were too specific / implemented for very specific uses.  I've been hoping we could generalize some stuff and make some broadly useful groups. 

 

Liam

 

On Tue, Dec 15, 2020 at 11:19 AM Bill Thompson <> wrote:

Hi Liam,

 

Happy to jump on a call to review Lafayette's setup.  Generally we let access policy requirements drive what reference and basis groups we have.

 

Best,

Bill

 

 

On Tue, Dec 15, 2020 at 11:27 AM Liam Hoekenga <> wrote:

We're trying to figure out how we want to slice and dice our HR data into basis and reference groups.  I'm aware of the "arcane codes" vs "institutionally meaningful" descriptions.. but it feels like some of our arcane codes might be institutionally meaningful (e.g. "department ID number").

 

I was hoping people might be willing to share samples of what they've implemented?

 

thanks!

-- 

Liam Hoekenga

ITS Identity and Access Management

The University of Michigan