Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] Need composite groups with more than 2 factors

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] Need composite groups with more than 2 factors


Chronological Thread 
  • From: "Hyzer, Chris" <>
  • To: "Bellina, Brendan" <>, "" <>
  • Subject: RE: [grouper-users] Need composite groups with more than 2 factors
  • Date: Thu, 10 Mar 2016 18:52:41 +0000
  • Accept-language: en-US
  • Authentication-results: ucla.edu; dkim=none (message not signed) header.d=none;ucla.edu; dmarc=none action=none header.from=isc.upenn.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:23

Btw, you can “easily” use the include/exclude type as an example of how to use a type and a hook(s) to do your own naming convention.  It is a little complicated (i.e. attach the type, maybe a couple helper groups exist, a couple don’t, make sure it will generally work), but in general it could be cloned and edited (and submitted back to grouper? J )

 

Thanks

Chris

 

From: [mailto:] On Behalf Of Bellina, Brendan
Sent: Thursday, March 10, 2016 1:19 PM
To:
Subject: Re: [grouper-users] Need composite groups with more than 2 factors

 

Thanks for the suggestion.  I think that the include/exclude naming makes a lot of sense for person oriented groups. For authorization groups I am leaning toward the allow/deny naming convention suggested by Bill.  I also need to look into the include/exclude type as I had not seen that.

 

Regards,

 

Brendan Bellina

Identity Mgmt. Architect, IT Services, UCLA

     +1 310 206 3131

 

 

 

From: Julio Polo <>
Date: Wednesday, March 9, 2016 at 4:46 PM
To: Brendan Bellina <>
Cc: "" <>
Subject: Re: [grouper-users] Need composite groups with more than 2 factors

 

Several interesting topics came out of this discussion.  Going back to Brendan's original question, I guess the answer is that you can't avoid using intermediate groups, since a composite can only have two factors.  We wrote recursive code that parses any _expression_ involving any number of factors such as this:

outcome:group:path =

(
 (
  group:path:one
  union
  (
   group:path:two
   complement
   group:path:three
  )
 )
 intersection
 group:path:four
)

The code automatically creates the intermediate groups (basically the composite enclosed in parentheses) by assigning them a sequence number.  In the above example, there would be two intermediate groups because the outermost parentheses are for the outcome:group:path.  The intermediate groups are created in a folder alongside the outcome group (e.g. the intermediate groups would be outcome:group:path:100, outcome:group:path:101)

Bill's nomenclature of allow-minus-deny is similar to what we're deploying as UH Groupings.  A grouping = basis + include - exclude where the basis is as simple as a reference group (e.g. basis = all faculty at Honolulu Community College) or a complicated _expression_ like the one above.  We can grant exceptions to the basis of the grouping by including and excluding people from it (some student employees need to be included, some annoyed faculty complained and want out).

Chris' mention of the include/exclude type is news to me.  Sounds like something I could use to optimize the composite groups I'm creating above, especially if I can avoid implementing them as composites.  I suspect that the nesting of all these intermediate composites, along with large-population reference groups, is one reason why it takes a couple of minutes to create some of our groupings.

-julio

Julio Polo
Enterprise Middleware, Identity and Access Management
Information Technology Services
University of Hawaii

 

 

On Wed, Mar 9, 2016 at 11:23 AM, Bellina, Brendan <> wrote:

Bill,

 

That sounds like a workable naming convention.  Thanks for the description.

 

Regards,

 

Brendan Bellina

Identity Mgmt. Architect, IT Services, UCLA

   +1 310 206 3131

 

 

 

From: "William G. Thompson, Jr." <>
Date: Wednesday, March 9, 2016 at 12:53 PM
To: Brendan Bellina <>
Cc: "" <>
Subject: Re: [grouper-users] Need composite groups with more than 2 factors

 

The general approach we've taken at Lafayette is to have the final "authorization group" (i.e. the composite group) be composed of two groups; service_allow - service_deny, where each of those groups have sub groups that create effective membership and adhere to the desired access policy.

composite group: service_authorize = service_allow - service_deny

 

service_allow might have subgroups of reference groups for faculty, staff, student, etc or other ad-hoc groups and together make up the default access policy (generally we don't add direct membership assignments for people to the "allow" group, this way people come in and out of the service_authorize as reference groups change based on SoR feeds)

service_deny has our "big red button deny group" as a sub group. If you show up in that for whatever reason it turns down access across the board.

Make sense?

Best,

Bill

 

 

On Wed, Mar 9, 2016 at 3:36 PM, Bellina, Brendan <> wrote:

Sorry if this question has an obvious answer somewhere.  A link to the answer would be fine.

 

I have a need to use the Grouper UI to create groups with more than 2 composite factors.  Specifically group A + group B – group C.  I can see how this could easily grow to a much larger number of factors as well.  I don’t see a way in the UI to create anything more complicated than 2 factors.  I am hoping there is a better solution than creating otherwise unnecessary intermediate groups.  Is there a way to do this?

 

Regards,

 

Brendan Bellina

Identity Mgmt. Architect, IT Services, UCLA

   +1 310 206 3131

 

 

 

 




Archive powered by MHonArc 2.6.16.

Top of Page