COmanage Developers List

[Scott Koranda <>]

Hi,

> 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.

No, that won't scale. There will be 100s of these types of
groups. If we go that route then the distinction between a CO
and a group becomes much less meaningful.

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

Hmmmm.

That expands the notion of federated a bit since here the
identities do not need to be asserted from distinct identity
providers. They could all be asserted by a single identity
provider yet in different COs but needing to be the members of
the same group.

> 
> 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.)

If we want to preserve the notion of COmanage being the
front-end to group management I don't see how we can get away
from this. 

Groups cross CO boundaries but are not necessarily themselves
COs.

Users may want to quickly spin up groups across COs in order
to enable some type of collaboration without all the
enrollment and policy baggage of COs.

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

Not yet...this is far from settled I fear.

Scott

> 
> -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
>