Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

This discussion will surely inform some small changes to the GDG.  When we hone in on some new "types" we will adjust the GDG.

Also, we will have some training modules on the GDG in the February Grouper training (and going forward), so if you are interested in this type of thing and can take the training, we would love you have you.

Finally, if it matters to people, wanted to suggest some tweaks to the cardinality:

> Access policy groups would be expected to have a one-to-one relationship with a service. 

I think its a many-to-one relationship.  Many access policy groups can be associated with one service.  One service can have many access policy groups.  But an access policy group cannot be in more than one service.  (but you can reuse service or team specific non global ref group inside of service policy groups 🙂 ).

> Reference groups would generally be expected to have one-to-many relationship to various access policy groups.

I think this is a many to many relationship.  Many reference groups can be associated with a policy group.  A reference group can be associated with many policy groups.  

Happy holidays!

---

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

 

The thread got a little jumbled below so I'll just reply here:

My frame of reference is the GDG. If we don't start there we can claim any particular labelled group can statisfy any stated purpose. Reference groups are intended to represent stable notions of a particular type of subject (person).  GDG access policy groups are intended to represent natural language access policy (NPL) for specific services. Access policy groups would be expected to have a one-to-one relationship with a service. Reference groups would generally be expected to have one-to-many relationship to various access policy groups.

If you find that your NPL frequently refers to "students and employee" such that it would be convenient to make a reference group composed of student and employee you can do that. However, that doesn't make it an access policy group in the GDG model.

Wiki Access Policy Group

* Student Ref Group

* Employee Ref Group

or 

Wiki Access Policy Group

* Student and Employee Ref Group

That choice is yours! :) 

Best,

Bill

On Wed, Dec 16, 2020 at 12:07 PM Black, Carey M. <> wrote:

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

Uh… I hate the English language… https://www.merriam-webster.com/dictionary/policy ( noun(1), Def 2.b)
“a high-level overall plan embracing the general goals and acceptable procedures especially of a governmental body“

IAM Refs:

            A single IAM ref group could be all of these:

                        directly “the full set that is allowed” to ‘do X’ by business policy. ( As in the “final answer”/ “Access control policy” )

                        an institutionally defined “cohort” that are combined with other cohorts to do other things too. ( ref group )

Examples are things like:

   “Only Students can”…. ( Then the “Student” ref group is equivalent to the sum total “access control policy”. )
            yes the “policy” group should not be directly the Ref group. ( It should be nested into the policy groups that need to only have Students. )

              But it is equivalent to the ACL policy in membership.

   “Students and Employees can” … ( Then the “Student” ref group needs to be joined with “Employee” to become a “access control policy”)

 

-- 

Carey Matthew

 

From: "Hyzer, Chris" <>
Date: Wednesday, December 16, 2020 at 11:17 AM
To: Carey Black <>, Andrew Jason Morgan <>, "Hoekenga, Liam" <>, Bill Thompson <>
Cc: Grouper Users <>
Subject: Re: [grouper-users] example basis and reference groups?

 

> 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