COmanage Developers List

[Benn Oshrin <>]

My first thought is that LIGO Identity Management would be a fourth CO, 
with members enrolled from the other COs. This would preserve groups as 
being attached to COs.

Another option would be to explore federated group memberships across COs.

I think we should enforce the notion of the CMP enabling multi-tenancy 
(ie: multiple unrelated entities/COs/VOs hosted on the same platform), 
and allowing CMP-rooted groups would violate that design. (The only data 
that can be rooted at the CMP right now are org identities, and only if 
configured as such, and only because they're not really data that 
belongs to the CMP or the COs in the first place.)

Hmm, we should capture "CMP = multi-tenant" somewhere... that'll 
resonate with systems-oriented people.

-Benn-

On 4/3/12 10:47 AM, Scott Koranda wrote:
> Hi,
>
> We had been thinking of a CO and COU structure like this:
>
> CO: LIGO Laboratory
>      COU: Caltech
>      COU: MIT
>      COU: LHO
>      COU: LLO
>
> CO: LIGO Laboratory Collaborators
>      COU: GEO
>          COU: AEI
>              COU: Theory
>              COU: Experiment
>          COU: Cardiff
>      COU: UW-Milwaukee
>      COU: Syracuse
>
> CO: Virgo
>
> We need, however, some groups to have members across all COs
> and COUs. A good example is the LIGO Identity Managment
> Project. It has members from at least 2 different COs and
> multiple COUs.
>
> Right now the data model assumes a group is rooted in a CO. Is
> that correct for all use cases?
>
> Do we need a CMP wide option on whether groups must be
> "rooted" (and hence only visible) to a CO?
>
> Scott