Grouper Developers Forum

[Chris Hyzer <>]

TomZ, please still respond, but my vision is:

> Will the Target Federated Grouper's Grouper Connector make SPML requests 
> (a pull model), or will the source Grouper (gsh) make the SPML requests 
> for the Target Federated Grouper?

I think there are three options:

1. Diffs, sent via push, based on the change log
2. Periodic refreshes of groups, pushed by the source
3. Periodic refreshes of groups, pulled by the target

I think we need diffs for real time, and we also need full refreshes.  If we 
already have the authn etc for #1, then we might as well do #2 instead of #3, 
though it shouldn't really matter we can support all if people want it...  
Note, I think we had discussed it before, but there is currently no way to 
pull diffs from WS...

> Assume that the Target Federated Grouper is operated by an organization 
> distinct from the Grouper at the left of the diagram. How should the 
> federated agents - Target Federated Grouper's Grouper Connector and 
> Ldappc's PSP - establish connections, ie, identify and authenticate each 
> other, and secure the SPML in some fashion?

I think we could do web service or xmpp for #1, web service only for #2 and 
#3 (since size could be large).  The authn is pluggable in web services, and 
we should have encryption/signing that is pluggable for xmpp...  there will 
probably be an easy way and a more correct/scalable way...  This would be a 
simple web service with an spml payload, I think REST seems like it makes 
sense, though we could wrap in it a soap envelope if people want it...

Thanks,
Chris



 On 8/26/2010 10:02 AM, Tom Zeller wrote:
> I've updated the wiki with an image of how federated groups might be
> provisioned through ldappcng :
>
> https://spaces.internet2.edu/display/GrouperWG/LDAPPC-NG+Development
>
> The work that needs to be done includes (1) converting Grouper
> changelog entries to spml and (2) writing the spml-to-Grouper
> connector, both of which should be straightforward.
>
> Feedback ?
>
> TomZ