Grouper Users - Open Discussion List

[Julio Polo <>]

Hi Bill,

My original feedback on the Grouper Deployment Guide was TL;DR.  Allow me to summarize the key proposals:

1. Rename basis groups to something else: raw groups? source groups?  Instead, use the word basis for the concept below.
2. Define the intermediate concept of a grouping as a composite that has a basis group + include group - exclude group.
   
   1. The basis of a grouping reflects the grouping's intent and is usually made up of other groups (e.g. reference group for faculty + reference group for staff).
   2. A grouping's include and exclude groups only have individual members who are exceptions to the grouping's intent.  No groups allowed here.
   3. A grouping is an intermediate-level concept between low-level Grouper primitives (group, composite, subject, memberships) and high-level TIER concepts (reference groups, bundle groups)
   4. The grouping model can be applied in all situations and helps to clearly define the intent and exceptions of any group.
      
3. Policy groups should be implemented as groupings to easily allow individual exceptions to the policy.

I added the above summary to the consultation wiki page. If this makes it to a TIER API WG agenda, I'll be sure to join.

-julio

On Thu, Mar 16, 2017 at 9:23 AM, Julio Polo <> wrote:

Hi Bill,

Yes, it's fine, and I'll be on the lookout for the next TIER API WG call.

Thanks,

-julio

On Thu, Mar 16, 2017 at 5:39 AM, William G. Thompson, Jr. <> wrote:

Hi Julio,

Thanks for taking the time to review the guide and for your feedback! Indeed one of the goals/challenges of the GDG is to identify similar concepts and approaches in practice with different/local names and come to some agreement on terminology. See the folder and group design comparison: https://docs.google.com/spreadsheets/d/13YTJhUzV7jrA9bXYKB9nSAEnC3ej0fTcsWjjhCTA9Bk/edit?usp=sharing which includes Hawaii's approach. At this stage in the process, my sense is to continue with the broader TIER consultation starting tomorrow and include a discussion/review of your feedback in that process knowing we'll have an opportunity to add/change before the final release. Sound fair?

Also, would you be able to make one of the TIER API WG calls in the next couple weeks?

Best,

Bill

On Thu, Mar 16, 2017 at 4:28 AM, Julio Polo <> wrote:

Hi Bill,

Apologies for the late feedback. I have some concerns about the allow/deny groups and how they are used in the access policy groups and account policy groups (I'll just refer to them as policy groups). The restriction that only reference groups be used in allow/deny groups would make it difficult to grant ad hoc inclusions/exclusions of individuals.  We would have to create a reference group with those individuals in order to add them to the allow/deny groups, and that just seems cumbersome.

I think I understand the impetus behind requiring a reference group in a policy group.  We have policy groups ourselves, but we've implemented them as composites like this:  

policy group = 

 criteria group which can only have reference groups 

 + allow group for individuals

 - deny group for individuals

This model makes it easy to make exceptions for individuals.  The allow/deny groups always exist for a policy group.  Only individuals can go into an allow/deny group.  If you need to allow or deny a reference group, that is done at the criteria group, never in the allow/deny groups.   The criteria group can be a composite or regular group of groups, but it can only be built using reference groups.  We actually don't use the term "criteria" but came up with the term "basis" a couple of years ago, as in "what is the basis of your policy group?" (more on basis below) This model also allows us to answer "what individual exceptions are allowed/denied?"

I know the GDG uses "basis" for something else. If the above model is adopted for policy groups, I would prefer to use the word basis for policy groups and come up with a different term for the other groups.  We ourselves use the term "prime" groups because they are just like prime numbers in that they cannot be reduced to anything smaller, and they are used to build bigger numbers (bigger bundle groups). The prime number can make a copy of itself when multiplied by 1, and that analogy still works for us because every prime groups has an equivalent reference group.  The reason we offer a reference group that is just a copy of a prime group is because we don't want to burden our users with having to understand the difference between prime and ref.   All they need to know is that they look in ref (groups built from prime, includes bundle groups).  All other groups go in the custom folder (policy groups go here, other app groups, etc.)

Our policy groups are actually a generic concept we call grouping.  The allow/deny groups are actually called include/exclude (works better because it doesn't hardcode the policy meaning, see mailing list example below).  A grouping can also have one ore more purposes attributed to it, and that's how we know whether a grouping is acting as an access policy group or as an account policy group (or something else).  We have also been using groupings to sync mailing lists, and the concept works just as nicely there too:

grouping of all students whose purpose is to sync a mailing list = 

 reference bundle group for all students

 + individual managers included

 - individual students who opted out of the mailing list.

Hope all of this made sense.  I was hoping to have more time to explain this more clearly, but I know you're submitting the GDG in a few hours.  I'd be happy to follow up if there are any questions.  Thanks for listening.

-julio

Julio Polo

University of Hawaii

Enterprise Middleware, Identity and Access Management

On Thu, Mar 9, 2017 at 8:17 AM, William G. Thompson, Jr. <> wrote:

Thanks, Emily. Adding the terms to the Grouper Glossary seems to make sense. Your question reminds me we need to think about where/how best to incorporate the GDG more generally with the wiki.

Best,
Bill

On Wed, Mar 8, 2017 at 9:52 AM, Emily Eisbruch <> wrote:

Bill and team,

Great work on the TIER Grouper Deployment Guide.

Thinking about the terminology introduced in section 2.4 and then discussed in section 5.1 ( basis groups, reference groups,

access policy groups, account policy groups). Would it make sense to add those terms to the Grouper Glossary?   We could add those terms to in a different table in the Grouper Glossary of "ABAC terms that may be useful and  are referenced in the TIER Grouper Deployment Guide." Or we could add a link from the Grouper Glossary to  NIST 800-162 doc

Guide to Attribute Based Access Control (ABAC) Definition and Considerations 

Thoughts?

Thanks,

- Emily

Emily Eisbruch, Work Group Lead, Trust and Identity
Internet2

office: +1-734-352-4996 | mobile +1-734-730-5749

---

From: <> on behalf of William G. Thompson, Jr. <>
Sent: Tuesday, February 28, 2017 11:37 AM
To:
Subject: [grouper-users] Grouper Deployment Guide 0.9 Beta - Community Feedback

 

The Grouper Team and the TIER API and Entity Registry WG is pleased to
present the Grouper Deployment Guide 0.9 Beta for community feedback.
The guide is not yet published or complete, and is being shared with
the Grouper community to solicit early feedback ahead of a broader
TIER community consultation scheduled for March 17 - April 14.

Grouper Deployment Guide 0.9 Beta
https://goo.gl/iTJOJk

Feedback can be sent via email to the grouper-user list or directly to
Bill Thompson <>.

Thanks,
Bill