| Warning |
|---|
Page is very much a work in progress. |
| Info |
|---|
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; primarily campus IdP with support for federated identities; apps include typical collaboration apps we well as domain specific apps, ssh key management, github access; need to demonstrate audit capabilities for grant reporting |
Before you login
...
to the COmanage Registry to start configuring the environment for your VO, consider the following questions:
- Do think about what structure you need for your platform.
If you want members of one CO collaboration to potentially be able see the members of another collaboration?- A flat logical structure with multiple 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. If siloed access to information, particularly around participation within a collaboration, is important, note that the 'CO If with multiple COUs' architecture would allow for COU administrators to see the population of other COUs. From the application standpoint, if multiple collaborations can access a single service, then the CO/COU model may be significantly easier.
- Do you want to delegate as much of the user and enrollment management to group or COU administrators as possible
| Tip |
|---|
Need more here re: the definitions, and pros / cons of CO/COU structure Need a pointer to how to connect apps to the registry |
- ?
- 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. See
Steps to set up your first VO
- The site administrator will have set up the first CO; this is the one CO that bootstraps all the rest. You will need to be enrolled in that CO and set up as a platform administrator.
- "Platform Administrators are configured by adding the appropriate Organizational Identity to the COmanage Registry, and then adding the corresponding person to the
admingroup within the COmanage CO."
- "Platform Administrators are configured by adding the appropriate Organizational Identity to the COmanage Registry, and then adding the corresponding person to the
- Go to the COmanage Registry URL (address TBD for your site). During the installation process, the site administrator should have set up the discovery service so you can login with your institution's preferred IdP.
Delegating Administration
- Creating CO administrators
- Creating COU administrators
Enrollment in a CO