Skip to Content.
Sympa Menu

comanage-dev - [comanage-dev] architecture questions and asserting group membership

Subject: COmanage Developers List

List archive

[comanage-dev] architecture questions and asserting group membership


Chronological Thread 
  • 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?



Archive powered by MHonArc 2.6.16.

Top of Page