Characteristics found in this use case:

  • A single platform managed by a single, central organization, with multiple, discrete VOs each with their own enrollment processes
  • Enrollment processes include self-signup, administrative/delegated signup, and conscripted signup
  • Individuals use various IdP with support for the Research and Scholarship entity category
  • Apps include typical collaboration apps we well as domain specific apps, ssh key management, github access
  • Administrators need to use audit capabilities for grant reporting on demographics and usage

 

Before you login to the COmanage Registry to start configuring the environment for your VO, consider the following questions:

  1. Do you want members of one collaboration to potentially be able see the members of another collaboration?
    1. A flat logical structure with multiple collaborative organizations (COs) implies an impact on the overall architecture for the COmanage Registry.  Each CO will have a set of people records underneath it; an individual might have multiple person records if they are members of multiple COs. This could become confusing for a user who would experience different access restrictions despite logging in with the same organizational identity.  Alternatively, the platform can be configured to have a single, master CO with multiple COUs underneath it. From the user perspective, their person record could then be attached to multiple COUs, giving them a complete view of what their information in the Registry. For more information on the differences between a CO and a COU, see CO vs. COU.

      If it is important to prevent users or even administrators from seeing who is in other collaborations on the platform, then it will be important to configure the environment with multiple COs instead of one CO with multiple COUs. The downside of that model, however, is that users will have a higher burden if they need to enroll multiple times, and the linking of applications may become more complicated.


  2. Do you want to delegate as much of the user enrollment process as possible to group or COU administrators?
    1. By default, only the CO admin can invite or add people to the CO. If you would like to delegate the ability to others to do the invitations or additions, the CO admin can enable that when they create the enrollment flows for the CO.   

      In smaller collaborations, this might not be necessary; one administrator can manage the enrollment processes. In larger collaborations, however, delegation may be a better model.