COmanage Developers List

[Benn Oshrin <>]

Consider the VO-as-Enterprise model (ie: LIGO, iPlant, ESWN, etc). 
Consider a CMP hosting multiple VOs (ie: COmanage).

Our original thought was that Organizational Identities (ie: 
) would be CMP wide, and that all VOs hosted on the 
CMP would have access to all Organizational Identities. In the scenario 
where Organizational Attributes are basically self-asserted (ie: not 
being pulled from LDAP or SAML) this is fine.

However, now consider the case where attributes are pulled from 
Organizational IdPs. There will be, presumably, some sort of attribute 
release policy whereby the IdP determines what attributes it is willing 
to release to what SP. We can ignore packaged attribute policies 
provided via federations here, because that won't cover all possible 
scenarios... we have to consider the worst case, which is point to point 
attribute release policy. In this worst case, the IdP will be agreeing 
to a policy with the VO, not the CMP.

[The case where a CMP hosts only a set of related VOs with one 
encompassing policy reduces down to 1 CMP = 1 VO, and so does not change 
things.]

[The VO-as-Federation model (ie: SWITCH, GakuNin) also reduces down to 1 
CMP = 1 VO.]

So what I think this means is that we need to update the COmanage data 
model so Organizational Identities are attached to COs. If 
 wants to join both LIGO and ESWN, and both are hosted 
on the same COmanage CMP, then LIGO and ESWN will both have copies of 
's attributes, subject to whatever relevant attribute 
release policies were put in place.

-Benn-