COmanage Users List

["Kevin M. Hildebrand" <>]

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.

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.

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.

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.

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.

Thanks,

Kevin

---

Kevin Hildebrand

University of Maryland, College Park

Division of IT