Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] veto if not eligible

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] veto if not eligible

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Tom Barton <>, "" <>
  • Subject: RE: [grouper-dev] veto if not eligible
  • Date: Fri, 28 Jan 2011 14:37:58 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

Ok, so lets revise the design...

On a folder you have the opportunity to say that subjects in the folder must
be in a group (or subject source? Or folder structure?). When a membership
is assigned, or subjects are searched for assignments, then the folder
hierarchy will be traversed upwards until there is such an assignment. If
there is none found, then no restrictions. If there is one found, traversal
will stop, and the subject must be in that group. We can have a change log
process that sees when subjects are removed from groups that are used in such
rules, they will be removed from any group/privilege/permission in that
folder structure. A daemon could also run to sync things up.

So I would think you would allow all g:gsa (group source), and then have a
group of people that can be used in folders. I wonder what the default
subject search in the UI would do... maybe it should run in the context of a
folder... hmmm


-----Original Message-----

On Behalf Of Tom Barton
Sent: Friday, January 28, 2011 2:26 PM

Subject: Re: [grouper-dev] veto if not eligible

that's right - so when they are searching for a Subject to put in a
group, they only see their project's Subjects.


On 1/28/2011 1:20 PM, Chris Hyzer wrote:
> That is similar to what I want. When you say a UI show members in
> the all group, you mean when you are searching for subjects to assign
> to groups, right? I think we would want that too, but it does sound
> more complicated... Maybe if I make the design less flexible (i.e.
> less hierarchy, and maybe less allow/deny, just an allow list), then
> maybe it would be easier to calculate and thus better performance...
> hmmm
> Chris
> -----Original Message-----
> From:
> [mailto:]
> On Behalf Of Tom Barton
> Sent: Friday, January 28, 2011 11:24 AM
> To:
> Subject: Re: [grouper-dev] veto if not eligible
> This is similar to a need in the CO/VO space. In that context each
> project, working group, activity, or what have you is assigned a folder
> in which they'll do all of their groups, attributes, & permissions.
> They'd also like to limit memberships to subjects in a folder-specific
> identified "all" group, ie, all the people involved in this project.
> So this might go a little beyond what Chris describes, in that a UI used
> by a project lead to assign group memberships should only show members
> of the project folder's "all" group.
> Tom
> On 1/27/2011 1:18 PM, Chris Hyzer wrote:
>> There is a rule available in 2.0 where if someone is not an employee,
>> they aren't allowed to be added to a specific group. I would like
>> something similar, but a little different.
>> The use case, is we don't want subjects from the external subjects
>> source to be added anywhere except in a specific folder. We don't want
>> Grouper users accidentally putting external users in groups. Granted
>> the app might not be shibibolized, but that's ok. This rule could be
>> done by source, or I guess it could be done by group (we could have a
>> group of all external subjects) as well, or both. We will soon have
>> applicants in our person registry, and we have lots of alumni, etc which
>> could also have similar restrictions.
>> i.e. I think we would like to have a bunch of ACLs on folders, and
>> membership adds would have to follow the rules. Do we do allow before
>> deny on matching rules? I guess this is configurable.
>> Example:
>> Root folder: forbid externalSubject source (or group)
>> Folder school:apps:federatedApps: allow externalSubject source, order:
>> allow/deny (though order doesn't matter since this folder has one rule on
>> it
>> So when a member is added to a group, it would need to traverse up the
>> folder structure, looking for rules, and seeing if the there is a
>> matching rule. If there is a matching rule, then follow the order (e.g.
>> allow/deny or deny/allow), and get the answer (stop traversing). Note,
>> if you do this by subject source, it would be very fast. If you do this
>> by group then it will require queries to check group memberships (as
>> groupersystem of course). However, I could imagine that it could
>> traverse, see which memberships it needs to check, and do this in one
>> query (assuming less than 100 groups to check J ), then process the logic.
>> So if we do this by group membership, then you could say, all users in
>> groups in the app folder must be employees.
>> I wasn't planning on having a daemon that cleans things up or a rule on
>> membership remove since it would be kind of time consuming to process
>> all the info, but maybe we need that as well, e.g. if someone falls out
>> of employee, they could fall out of required application groups by
>> folder J Actually, I could picture a change log process that would do
>> this efficiently.
>> Thoughts?
>> Thanks,
>> Chris

Archive powered by MHonArc 2.6.16.

Top of Page