Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

> 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 > )

Thats a good idea and can simplify the app template (take out the "service" folder"), and will help inform "service manager" "role" of the evolving "grouper service" concept

> 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.

This if I understand I guess I disagree, if a ref group is used for intersection or rules on an ad hoc group, that doesnt make it a policy group...

> 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.

Uh... maybe optin/optout are exempt from the grouperSecurity idea above?  🙂    I think of grouperSecurity of admin types, not of user types

---

From: Black, Carey M. <>
Sent: Wednesday, December 16, 2020 8:57 AM
To: Andrew Jason Morgan <>; Hoekenga, Liam <>; Bill Thompson <>; Hyzer, Chris <>
Cc: Grouper Users <>
Subject: Re: [grouper-users] example basis and reference groups?

 

+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