Last updated 17 Jun 2022.


Current COmanage platform version: 4.0.x

Introduction

This article covers several topics for admins and developers working with collaborative communities using the CILogon platform.


New Platform/Collaborative Organisation Checklist

CILogon is for collaborative communities, whose members come from more than one organisation and who share data, compute or storage resources. CILogon extends COmanage which is a federated identity management system that enables inter-organisational member management. Community leaders need to evaluate their needs against the suggested deployment patterns. The COmanage Administrative Manual provides an introduction to deployment scenarios and provides guidance in determining a community's requirements.


Common CILogon integration patterns

The CILogon developers suggest the following integration patterns : https://docs.google.com/document/d/1IkXMdILtmDk_btwFrAPF8NtMDofDTkMsEDw3ioZifVs


To assist a community with their integration with CILogon, the following items require consideration.

  • For the Collaborative Organisation (CO) configuration, is a shared or single tenant required?
  • How many COs will be required for each workspace/cohort/project
    • CO Names
      • Short/abbreviated name
      • Long name
      • CO Description(s)

There are several approaches to integrate with CILogon (covered below) requiring specific configuration changes. These options should be reviewed and if needed requested.

  • OA4MP admin client enables integration with OIDC services

    • Feature is enabled per CO.

    • All CO admins receive the elevated privilege manage connection to services

    • All CO admins must read and agree to the policy on OIDC Client Administration (outlined below)

  • LDAP search capability

    • only for those developers who require LDAP searching capability access to provision identities to a service

  • Enrolee Document Upload Plugin

    • enables submission/upload of a document during an enrollment flow - simple process for collecting a document (PDF) from an enrolee

  • Enrolment Authorisation for ORCID iD release to a CILogon CO
    • Plugin to request user authorisation to read/store a enrolee's ORCID iD
  • Provision of a primary identifier for researchers - this is an internal identifier shared with connected services as a primary key, in place of using transient identifiers like email
  • A list of the institutions whose members will use the service.


The OIDC Client Administration and the granting of admin privileges to a CO also confers administrative permission to connect OIDC clients and use CILogon authentication flows (and hence eduGAIN IdPs) without any further approval. This privilege requires responsible use of the service and must only connect services that support the CO capabilities and research services.

Collaborative Management Platform(CMP) and CO admins must acknowledge that they will use these elevated privileges responsibly.


CO permission model

The COmanage permission model is not that fine-grained and it assumes that people within a CO are generally within the same "collaboration" and so there is no need for high walls.


For example, a COU admin is able to "see" but not manage people in other COUs. So one question asked when mapping organisations into the COs and COUs is "if a team leader can see who is on the other team, is that a problem?" If the answer is yes, multiple COs are required. If the answer is no, then one CO with multiple COUs is an option.


Each CO can be a source for organisational identities in the community CO and in that community CO the CO Person record functions as a "community" view of the CO Person.


COmanage Services are logical representations of the external services a user may access as part of collaborating, and a Service can be "attached" to a COU, but that is mostly used for portal rendering (different portals for different COUs).


The OIDC plugin has a simple delegation model right now. The ability to manage OIDC clients can be delegated to any CO Group (the default is the CO admins group).


Delegating by COUs is an interesting idea that has not been requested yet.


CO Registry Administration has a simple permission model, with a single administration role that assumes management of the following CO items (not an exhaustive list):

  • people

  • groups

  • roles

  • enrollment flows

  • Service and API connections

  • OIDC connections (when enabled)

  • most other CO settings


Integration with CILogon

(for example a GA4GH Passport Server or a REMS system)

There are several approaches to integrating and connecting services to CILogon that follow the CILogon developers integration patterns. 


These are outlined in the Integration with CILogon Guide.

COmanage Configuration Guide

A intro guide to a step-by-step COmanage Configuration Guide for SAML is available. Most of the steps typically occur before its made available to community admins. This guide outlines the item dependence between configuration items - certain items must exist before others.


In the main, the CILogon team or the AAF will prepare a Collaborative Organisation and onboard the initial admin/dev users.


Enrolment Flows and Petitions


Every organization has one or more ways of bringing new people into that organization. There are a number of terms used to described this process: application, enrollment, intake, invitation, petition, signup, etc. These processes vary significantly across organizations. Read more about    


https://spaces.at.internet2.edu/display/COmanage/Registry+Enrollment+Flow+Configuration#RegistryEnrollmentFlowConfiguration-RegistryEnrollmentFlowConfiguration-EnrollmentFlowAttributes