Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Fwd: [comanage-tac] Fwd: [collab-intl] VOOT proof of concept

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Fwd: [comanage-tac] Fwd: [collab-intl] VOOT proof of concept


Chronological Thread 
  • From: Michael R Gettes <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>, Niels van Dijk <>
  • Subject: Re: [grouper-dev] Fwd: [comanage-tac] Fwd: [collab-intl] VOOT proof of concept
  • Date: Mon, 21 Nov 2011 15:34:01 +0000
  • Accept-language: en-US

I was about to fire a note to this group regarding VOOT and Box.  It is, in fact, what we have been discussing with them.  While I have yet to get a firm response from Box I can say the comments thus far have been rather warm to the idea.  I believe the idea is to allow the user to interact with Grouper.  It's unclear to me whether or not any real restrictions should be placed on which groups can be exposed to a federated provider if we can have a reasonable way of dealing with the FERPA'd individuals.  For example, if I as a grouper admin decide to restrict FERPA'd people from being exposed to unblessed external providers, then I as a grouper user should be able to expose any group to an external service.

I believe it is also the case, for Box, to utilize SCIM as the mechanism for keeping groups in sync once they are selected and provisioned into the external service.

/mrg

On Nov 21, 2011, at 9:55, Tom Barton wrote:

More VOOT. This foodle POC is a good model for one way that a box.net integration with grouper might be styled, which leads to several questions. How should an oauth-protected opensocial provider for grouper be designed? Can we use someone else's (SAML-protected) oauth server, and are there opensocial parts that are re-usable in our context?

And then there's the business of managing which groups it might make sense to expose to a given external service like foodle or box.net. The usual criteria seem to be either (1) groups I'm a member of or (2) groups I can manage. Probably both need some qualification in our context, either because sometimes a user belongs to groups having very large membership, or sometimes a user can manage a large number of groups. What role should the enterprise have in making such choices, and what role should the user have?

Tom

-------- Original Message --------
Subject: [comanage-tac] Fwd: [collab-intl] VOOT proof of concept
Date: Tue, 15 Nov 2011 16:16:18 -0600
From: Heather Flanagan
To:


For those of you not on the international collab list...

-------- Original Message --------
Subject: [collab-intl] VOOT proof of concept
Date: Tue, 15 Nov 2011 21:33:51 +0100
From: Andreas Åkre Solberg
To:


I've taken the proof of concept integration between Foodle and SurfConext to the next step.

Here is a series of screenshots demonstrating an example of how federated groups can be made use of in a real service:

	https://rnd.feide.no/2011/11/15/voot-in-real-life-federated-groups-proof-of-concept/

Andreas




Archive powered by MHonArc 2.6.16.

Top of Page