CILogon is an integral part of our MUSES CI as our authentication identity provider, as we have explained in various other posts. The same organization that hosts CILogon also offers something called COmanage that provides a “collaboration management platform”. The purpose of this post is to explore what this service could offer MUSES and what we might learn from it to improve our own implementation.
From the description of the CILogon 2.0 service:
When scientists work together, they use web sites and other software to share their ideas and data. To ensure the integrity of their work, these systems require the scientists to log in and verify that they are part of the team working on a particular science problem. Too often, the identity and access verification process is a stumbling block for the scientists. Scientific research projects are forced to invest time and effort into developing and supporting Identity and Access Management (IdAM) services, distracting them from the core goals of their research collaboration. The “CILogon 2.0” project provides an IdAM platform that enables scientists to work together to meet their IdAM needs more effectively so they can allocate more time and effort to their core mission of scientific research.
The COmanage documentation includes a page about the Multi-institution collaboration use case which is exactly matches our MUSES collaboration:
Generalized top level use case for COmanage (hypothetical)
Research groups from Oxford University, Harvard University, and several other notable institutions form a collaboration to solve world hunger. Each institution manages the identity of the researchers associated with that institution, including authentication and attribute information, the local provisioning and deprovisioning of the user account. The collaboration cannot be housed under any one institution; it must form a separate “virtual” organization. The virtual organization relies on the information about the researchers as derived from the member institutions [1]. Administrators of the virtual organization are responsible for authorization based on group information which may or may not be derived from information received from the member institutions; some of it may come from within the VO itself [2]. The information in the virtual organization will in turn automatically populate/provision mailing lists, wiki space, groups, and domain science applications [3].
Administrators and power users will have an interface through which to manage the VO-specific groups and invitations to new researchers to join the VO [4]. Standard users will only see that they use their home institution’s credentials to log in, and that they are already provisioned in the appropriate mailing lists, wiki space, and so on.
When a researcher leaves one of the associated institutions, and that institution deprovisions their account, that information will automatically feed back to the VO which will in turn automatically deprovision their access to the VO space.
How MUSES CI implements similar capabilities:
- [1] CILogon is our identity provider and the initial name and email for collaborators is sent by their institution via CILogon through the OIDC protocol.
- [2] Authorization groups are managed in Keycloak, which is the OIDC auth portal used by all of our services.
- [3] The groups/roles granted to individuals in Keycloak are consumed by services to enforce access control.
- [4] We operate a webserver that serves registration forms that trigger automation flows. The collaborator registration form triggers a workflow that sends an approval request to admins, containing links that apply or deny membership in the releveant access control groups. The seminar registration form adds registrants to access groups that grant them access to a private Discourse forum category and thereby subscribes them to email notifications of upcoming seminars.
One notable “competitor” to this COmanage/IdaM platform is Globus Platform-as-a-Service.