Grouper Users - Open Discussion List

[Julio Polo <>]

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