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: Tom Barton <>
  • To:
  • Subject: Re: [grouper-dev] veto if not eligible
  • Date: Fri, 28 Jan 2011 10:23:38 -0600

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