Grouper Users - Open Discussion List

[Paul Gazda <>]

Chris,

Thanks for your reply, although it is not what I was hoping to hear. J From the jira, it appears that there were technical factors contributing to the decision, and I realize that the issue of changing permissions on subgroups presents dilemmas no matter how you handle it. However, I do want to present arguments for having Grouper dynamically honor access permissions when displaying query results, and allowing subgroups with view privileges to be added.

 

First, dynamic evaluation of permissions. If a person creates a group with “read” access to GrouperAll, and other people incorporate it into their groups, and then the person changes access to “view” for GrouperAll, they would intuitively expect from that point on, that people would not be able to see the members of that group. They would not be thinking that the previous read privilege would be grandfathered into all groups that currently have it as a subgroup. If the burden is placed on the business logic of the UI, it could generate a lot of overhead for the admin user behind the scenes to look for all groups that contain the subgroup and delete it from all of them. That could be a very time consuming operation using web service calls.

 

I also see an advantage of allowing subgroups to be added when the user has only view access. For example, some standard groups may be provided to users such as all students, all staff, all faculty, etc. that may have thousands of members. If everyone needs read access to use them as subgroups, they will be able to query the members, and curiosity being what it is, many people will be bogging down response time by needlessly listing the thousands of members. The UI will have to prevent those kinds of queries via business logic, which probably means both special group design and special coding to recognize and suppress the querying of those special groups. It would be much simpler from a development point of view if Grouper returned only the group name to a user who had only view privilege at the time of the query.

 

Paul Gazda

 

---

From: Chris Hyzer [mailto:]
Sent: Wednesday, April 08, 2009 12:05 PM
To: Paul Gazda; Grouper Users Mailing List
Subject: RE: Access privileges within sub-groups and composite groups

 

That was a design decision…

 

If you add a group’s members to your group while you have read access, then that group “has” those members, and can always query for them if you can list the outer group’s memberships.  However, if you remove that group from your group, then you wont be able to re-add it without READ of the underlying group.

 

So… if you are removing READ from a group, and you want to make sure no one is using that list, you should check to see where that group is a member of another group or a composite factor…

 

We did discuss this on a design call, but this exact issue didn’t make it into the Jira issue, I added a comment.

 

https://bugs.internet2.edu/jira/browse/GRP-199

 

OK?

 

Thanks,

Chris

 

From: Paul Gazda [mailto:]
Sent: Wednesday, April 08, 2009 2:55 PM
To: Grouper Users Mailing List
Subject: [grouper-users] Access privileges within sub-groups and composite groups

 

I am seeing what seems to be an inconsistency in the way Grouper handles access privileges in sub-groups and composite groups. I have looked in the listserv archives and wiki and could not find info on this. I see the same behavior in both cases and will explain it with a sub-group example.

 

I have a group A.

I have a group B.

I make group B a sub-group of group A.

 

I query for the members of group A using getMembersWs of GrouperClient 1.4.1 as a non-admin. I see all of Group A’s members plus Group B plus Group B’s members - as expected.

 

I remove read and view access privileges on Group B for GrouperAll.

 

I query for the members of Group B and get an error that the group is not found – as expected.

 

I query for the members of Group A and see all of Group A’s members plus Group B plus Group B’s members. That is not what I would expect. I would expect to see only Group A’s members because Group B should still be invisible to GrouperAll.

 

Paul Gazda