comanage-dev - [comanage-dev] architecture questions and asserting group membership
Subject: COmanage Developers List
List archive
- From: Scott Koranda <>
- To:
- Subject: [comanage-dev] architecture questions and asserting group membership
- Date: Tue, 3 May 2011 08:51:53 -0500
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=sZBdO14tOCm1h+oY9PC7VIKkH8RFk4rbUkEPgVLlgitULGZBeQFCunQTrRYDLkojUj 38QZl3eywflNro8N8JzpcjbdXQ7NtHMvSexwUqbJ2tAtEzp5rM9/YHko3II6pAH7Sfiq FBPD5RAkSbU/rGzDe4sIm8TpuMYnIihavEcA8=
Hi,
I would be grateful if you would consider my naive
architecture questions. I want to understand at a detailed
level how adding someone to a group through COmanage/Gears
ends up as an assertion by an IdP to be consumed by a SP.
Consider LIGO's IdM architecture.
''
is
a Kerberos principal. When it was registered/created an entry
was put into the LIGO LDAP server of the form
dn: employeeNumber=882,ou=people,dc=ligo,dc=org
employeeNumber: 882
givenName : Scott
sn: Koranda
cn: Scott Koranda
eduPersonPrincipalName:
mail:
LIGO also has a Grouper deployment and it runs ldappc-ng so
that the LDAP entry also includes
isMemberOf: ComputingCommittee
LIGO has an IdP. It authenticates against the KDC and pulls
attributes from the LDAP and asserts them for consumption by
SPs. A number of SPs use the attributes, in particular
isMemberOf, for authz.
Now suppose our sister project LCGT had a parallel
infrastructure--its own LDAP, Grouper, and IdP. The IdP also
asserts 'isMemberOf' for LCGT users.
Next, suppose LIGO deploys COmanage Gears as a CMP and invites
LCGT and LIGO scientists to use it for collaboration
management. A CO is created named "Joint LIGO LCGT work".
So
"logs in" to COmanage. As a COadmin
for "Joint LIGO LCGT work" he creates a "group" called
"JointLIGO_LCGT_CBC" (CBC = compact binary coalescence, a type
of source we study). He adds to that group
A wiki behind a SP is set up and the ACLs configured so that
only identities that assert "isMemberOf: JointLIGO_LCGT_CBC"
can access the application.
My main question is, what is the architecture that enables the
LIGO IdP to assert "isMemberOf: JointLIGO_LCGT_CBC" for
and the LCGT IdP to assert "isMemberOf:
JointLIGO_LCGT_CBC" for
?
Some specific questions:
1) When
logged into Comanage and
created "the group" "JointLIGO_LCGT_CBC" specifically which
COmanage gears data model "tables" were exercised? (Note that
LIGO really wants to use Grouper as the store for Group
membership if possible)?
2) Which Grouper instance was the group created in? The LIGO
Grouper, the LCGT Grouper, or a distinct Grouper?
Thanks,
Scott
P.S. Where is the best place for me to read up to understand
what is meant by "federated groups", especially in the Grouper
2.0 context?
- [comanage-dev] architecture questions and asserting group membership, Scott Koranda, 05/03/2011
- Re: [comanage-dev] architecture questions and asserting group membership, Steven Carmody, 05/03/2011
- Re: [comanage-dev] architecture questions and asserting group membership, Niels van Dijk, 05/03/2011
- Re: [comanage-dev] architecture questions and asserting group membership, Steven Carmody, 05/03/2011
- Re: [comanage-dev] architecture questions and asserting group membership, Scott Koranda, 05/03/2011
- RE: [comanage-dev] architecture questions and asserting group membership, Chris Hyzer, 05/03/2011
- Message not available
- RE: [comanage-dev] architecture questions and asserting group membership, Chris Hyzer, 05/03/2011
- Message not available
- RE: [comanage-dev] architecture questions and asserting group membership, Chris Hyzer, 05/03/2011
- Re: [comanage-dev] architecture questions and asserting group membership, Niels van Dijk, 05/03/2011
- Re: [comanage-dev] architecture questions and asserting group membership, Steven Carmody, 05/03/2011
Archive powered by MHonArc 2.6.16.