COmanage Developers List

[Chris Hyzer <>]

Ok, thanks, that makes sense.  In fact, I like that idea.  I was thinking of 
the case where not all group memberships are public, and you would have the 
IdP (attribute provider) send the entity of the SP to grouperWS, which has 
the entityId as a subject, and that subject has privileges to read only 
certain groups, so different entity IDs would get certain groups names in the 
memberOf attribute... anyways, that sparks some ideas :)

Thanks,
Chris

-----Original Message-----
From: Niels van Dijk 
[mailto:]
 
Sent: Tuesday, May 03, 2011 6:24 PM
To: Chris Hyzer
Cc: 
;
 Scott Koranda; Steven Carmody
Subject: Re: [comanage-dev] architecture questions and asserting group 
membership

Hi Chris,

Basically the latter I would say, as there will be additional attributes 
beyond group membership that will also need to be provided. Well that is at 
least for both comanage and SURFconext. In identity federation speak the 
thing providing the additional CO/VO attributes is not an IdP by the way but 
a attribute provider. It does provide attributes, as an IdP would most likely 
do, but is does not do the authentication bits. To make things more unclear, 
it is the Shibboleth IdP product that implements this functionally though...
To hook the attribute provider up to grouper, a basic LDAP would do I guess, 
but I am in no way a Shib IdP expert.

Cheers,
Niels

----- Oorspronkelijk bericht -----
> Van: "Chris Hyzer" 
> <>
> Aan: "Scott Koranda" 
> <>,
>  "Steven Carmody" 
> <>
> Cc: 
> 
> Verzonden: Dinsdag 3 mei 2011 21:29:36
> Onderwerp: RE: [comanage-dev] architecture questions and asserting group 
> membership
> 
> 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...
>