Skip to Content.
Sympa Menu

comanage-users - Re: [comanage-users] CO/COU Permissions questions

Subject: COmanage Users List

List archive

Re: [comanage-users] CO/COU Permissions questions

Chronological Thread 
  • From: Benn Oshrin <>
  • To: "Kevin M. Hildebrand" <>
  • Cc:
  • Subject: Re: [comanage-users] CO/COU Permissions questions
  • Date: Wed, 10 Apr 2019 16:31:39 -0400

On 4/8/19 3:36 PM, Kevin M. Hildebrand wrote:
I have an HPC cluster to which I want to provide federated access.  My idea is to create a CO for the cluster, and that CO will contain all users that have access to that cluster.
Within that CO, I want to create a COU for each of the partner organizations that will be using the cluster.  I want COU admins to have the ability to view/edit/approve their users and only their users- i.e., COU A's admins should not be able to modify COU B's users.
I've created self-signup enrollment flows, one for COU A, and one for COU B, which are correctly placing the incoming users into the right COU.

Historically, COU admins had full visibility (but maybe not full permissions) into all CO People because a COU admin could simply enroll somebody into their own COU and then by necessity have access to that person. (The idea was that COU admins would generally be trusted enough not to do something bad to other people's records.) Over time, we to some degree have added the ability to constrain COU admins' abilities to enroll people, but we haven't come up with a new visibility model yet.

User B goes to the enrollment page for COU B, and signs up.  At this point, I'd expect that admins for COU B can see the petition, but that admins for COU A can not.  However, in my tests, the COU A admin can not only see the petition, but can approve it, thereby creating a user in COU B.

Seeing the petition is the correct (current) behavior, but approval would depend on the Enrollment Flow configuration. By default any CO or COU admin can approve enrollment, however if you have set the Flow to Require Approval and the Approvers group to something like "CO:COU:COU B:admins" and COU A admins can still approve then that's a bug.

Once a user is created, COU A admins can still see COU B users, though it appears that most of the editing capability returns 'Permission denied' as I'd expect.  Unfortunately, if the COU A admin adds a CO Person role for COU A to the COU B user, then suddenly the COU A admin gains the full ability to change any attributes he wants on the COU B user.  Even more concerning, if the COU A admin then removes that role, he still appears to retain the ability to edit the COU B user's attributes.

Right, this is the historical behavior.

And finally, it appears that COU A admins are able to edit organizational identities for COU B's users.  This also seems undesirable for our use case.

Organizational Identities aren't attached to a COU, so there's no concept of that sort of permission. Relatedly, Organizational Identities created from Org Identity Sources are read only by everyone.

Am I trying to do something here the system isn't designed for?  From reading the documentation it seems to indicate that COUs should be administratively separated, but in practice it doesn't seem to be working that way.

In general, separate COs are currently required for full data separation, but that of course comes with different complexities (need for multiple enrollments, duplication of configuration, etc).

We've been floating some ideas for adding additional permissions levels (CO-1156 is a related but not identical concern), but haven't gotten to any specific proposals yet. I suspect some others on this list would be interested in this as well, so the first step would be agreeing on what a viable new permissions model would be.



Archive powered by MHonArc 2.6.19.

Top of Page