...
(The full correspondence is available at https://list.unm.edu/cgi-bin/wa?A2=ind0701&L=jasig-portal&T=0&F=&S=&P=2733.)Although this here.)
This question exposes gaps in the groups manager channel, which should have permissions covering operations on groups and their descendants. However, you could also get the desired behavior with a custom permissions policy, and this might buy you some time to work out a long term solutionmore viable solution that involves changes to the groups and permissions manager channels. The policy would evaluate permissions perform a special evaluation on permissions that are owned by the groups manager channel:
Code Block |
---|
owner = "org.jasig.portal.channels.groupsmanager.CGroupsManager" |
such that permission targets that have a wildcard syntax, i.e.,and have targets with a known wildcard syntax like
Code Block |
---|
target = "group.local.123*" |
are A target in one of these permissions would be known to refer to a group and its descendants. Permissions like these would have to be maintained outside of the permissions manager. This is a very brittle approach, but it does work, and perhaps someone can think through and generalize the approachit, maybe introducing a configurable wildcard syntax and list of permission owners. A follow-up step would be to make the permissions manager channel able to write and evaluate such permissions.
For starters, I'm attaching a sample policy that addresses just the groups manager issue.