COmanage Developers List

[Chris Hyzer <>]

Just curious, if the part in the IdP which resolved the extra attributes 
about group memberships going to be grouper specific, or comanage-specific 
which has a grouper implementation?  I think there is something that exists 
for this that TomZ wrote which uses the Grouper API, and I am interested in 
making a lighter-weight version which just uses the Grouper client...

Thanks,
Chris

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Scott Koranda
Sent: Tuesday, May 03, 2011 2:29 PM
To: Steven Carmody
Cc: 

Subject: Re: [comanage-dev] architecture questions and asserting group 
membership

Hi,

Thanks, this is quite helpful.

Comments interspersed below...

> On 5/3/11 9:51 AM, Scott Koranda wrote:
> 
> >
> >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 
> >?
> >
> 
> My assumption is that use case goes like this:
> 
> scott.koranda is a user with an identity at ligo.org
> john.smith is a user at lcgt.org
> 
> LIGO is operating a CO instance
> 
> >A CO is created named "Joint LIGO LCGT work".
> >
> 
> I'll assume that implies that you're also creating a group called
> "Joint LIGO LCGT work" (since down below you're using isMemberOf).
> 
> At this point, the only entity that *I* would trust to assert
> "isMemberOf: JointLIGO_LCGT_CBC" would be the newly created CO
> instance... which is *probably* different from where LIGO and LCGT
> members authenticate...

I see your point. 

> 
> This means that the newly created CO instance must also include an
> *interesting* deploy of a Shib IDP. No one authenticates AT the CO
> instance; but, the Shib IDP can answer SAML Attribute Queries about
> the users who are in the CO's ldap server (ie users registered at
> the CO).
> 
> >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.
> >
> 
> If this wiki is inside the newly created CO, then the problem is
> simple -- the wiki obtains groups memberships from the "local" ldap
> (the one inside the CO).

Aha. I had not been thinking conceptually about SPs and
applications they host being "inside" or "outside" of a CO. So
this is helpful.

I will, of course, in my use case need to support both.

> 
> If this wiki is outside the newly created CO, then configure Shib in
> front of the wiki, and configure the Shib SP to use this feature:
> 
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPInterestingFeatures#NativeSPInterestingFeatures-%22Simple%22AttributeAggregationNativeSPAttributeResolver%23NativeSPAttributeResolverSimpleAggregationAttributeResolver%2528Version2.2andAbove%2529
> 
> The SP feature is called ""Simple" Attribute Aggregation".
> 
> So, when scott.koranda logs into the wiki, the wiki obtains
> attributes describing scott from ligo.org (his idp). The SP is also
> configured to issue a SAML attribute query to the new CO instance
> (using one of the values provide by Scott's home organization to
> identify Scott; this is a collaboration environment, that value
> would typically be Scott's EPPN value).

Got it.

(I also appreciate the point Niels made about this currently
being available only for NativeShibSPs right now. Thanks.)

> 
> The SP aggregates the attribute values obtained form Scott's home
> org and from the CO, and presents them tot he wiki....
> 
> I'm sure I managed to skip something in the middle of that
> explanation... so ask questions where things aren't clear....

I think I have enough for now to move forward with some work I
am doing that will eventually be replaced entirely with
COmanage/Gears.

Thanks much,

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?
> 
> Some info here:
> 
> https://spaces.internet2.edu/display/Grouper/Grouper+external+users
> 
> and a link to a demo server supporting this idea.
> 
> basically, Chris creates another "source" for Grouper; Federated
> users come to your site and "register"; that adds them to this new
> source (and you must replicate from this new source to -- presumably
> -- a different branch of your ldap tree (think "immigrants"  ;-)  );
> you can then use the Grouper GUI to add people from this other
> source (ie the external users) to your local groups. because these
> people are now represented by user objects in your local ldap
> directory, group objects int hat directory can now reference these
> people...