Grouper Users - Open Discussion List

[Michael Gettes <>]

It’s also worth noting that, at least in my experience, not much is immutable with group structures in Grouper.  What do I mean???  With 5 min of thought you can think through how you might change up a group of an app if you got it wrong.  Just make sure you have an additional level of group indirection in your structures.  If you create a policy group and it has other groups within it, then if you need to change how you populate the sub-groups then create the new groups and modify the policy group to include them first before removing the old sub-groups.  If you are careful you can change the structure dramatically without breaking the policy or the app.  You just have think through the changes and how they will flow out to applications - you don’t want to remove someone who shouldn’t be removed which would cause them to be de-provisioned from the app using the groups.

For me, this aspect of Grouper is one of its core positive characteristics.  It means you can try things and, I can say with a high degree of confidence, with some planning you can change things up later to modernize how you do things as you learn better ways of managing your groups and policies.

I hope this helps!

/mrg

On Dec 16, 2020, at 10:08, Bill Thompson <> wrote:

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