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 13:26:22 -0600

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

Tom

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