COmanage Developers List

[Steven Carmody <>]

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...

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).

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).

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....


> 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...