COmanage Users List

[Benn Oshrin <>]

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.

Thanks,

-Benn-