Grouper Developers Forum

[Tom Barton <>]

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
>>
>