Grouper Developers Forum

[Chris Hyzer <>]

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