OpenSocila + OAuth Architecture & Implementation Advice

[hertzel]

Hi

We have investigated a while the OAuth & OpenSocial/Shindig projects,
actually reviewed every piece of documentation and specification about
these technologies including design/best practices, installed the open-
source references (shindig, google-oauth, etc.)

We have a "ACTIVITY CENTRIC" product with some social features based
on J2EE as server-side and Adobe AIR (RIA) as client-side.
Now, we are intended to socialize our product and would like to get
your advice and recommendations, before start-coding.

(1) Our requirements are as follow:
(1.1) Exposing our data and services to the community, developers
(1.2) Developing our opensocial gadgets to be installed on existing
opensocial networks
(1.3) providing a new opensocial network based on our current services

(2) As of our understanding these requirements' implementations
should be as following accordingly:
(2.1) 'RESTify' our services and secure them by GOOGLE-OAUTH SERVER,
implemented & deployed locally + registration module which provides
consumer key & secrets to social consumers
(2.2) Developing gadgets based on opensoial-gadgets which consume our
services from (2.1) - no server is required here beside a web server
hosting the gadgets' xml
(2.3) Deploying the Shindig (java project) container, enhanced by data
server (beside xml)


(3) Other question:
(3.1) How could we feed the opensocial activity streams in any
opensocial network by our activities which have been produced in our
product by the viewer?
(3.2) What's your recommendations about mashup gadgets which provide
services/data - from our product + other social sites - in the same
gadget
As of unclear documentation about implimentation of (google) OAuth
Servers (for service providers) & Container servers, we would be much
appreciated to get some advice/directions and best practices beside
what already published on the web!

Hertzel


Hertzel Karbasi Enterprise Architect OPTinity eSolutions, CEO
Her...@OPTinity.com +972.54.431.431.9 MeadoWare is Coming soon!

[Louis Ryan]

Hertzel,

Answers below...

-Louis

On Thu, Dec 11, 2008 at 7:16 AM, hertzel <her...@optinity.com> wrote:

Hi

We have investigated a while the OAuth & OpenSocial/Shindig projects,
actually reviewed every piece of documentation and specification about
these technologies including design/best practices, installed the open-
source references (shindig, google-oauth, etc.)

We have a "ACTIVITY CENTRIC" product with some social features based
on J2EE as server-side and Adobe AIR (RIA) as client-side.
Now, we are intended to socialize our product and would like to get
your advice and recommendations, before start-coding.

(1)   Our requirements are as follow:
(1.1) Exposing our data and services to the community, developers
(1.2) Developing our opensocial gadgets to be installed on existing
opensocial networks
(1.3) providing a new opensocial network based on our current services

(2)   As of our understanding these requirements' implementations
should be as following accordingly:
(2.1) 'RESTify' our services and secure them by GOOGLE-OAUTH SERVER,
implemented & deployed locally + registration module which provides
consumer key & secrets to social consumers

Yes, though I should point out that OAuth is an open standard. You can use the social-api package from Shindig to get a leg up on building the REST APIs in Java or you can build them from scratch or use the Java library from OAuth.net and roll your own.

 

(2.2) Developing gadgets based on opensoial-gadgets which consume our
services from (2.1) - no server is required here beside a web server
hosting the gadgets' xml

Yup thats it, you'll want to make sure the communication between the container and your services are secure. Some containers will require you to register your application and generate a shared-secret before OAuth signing is enabled.

 

(2.3) Deploying the Shindig (java project) container, enhanced by data
server (beside xml)


(3) Other question:
(3.1) How could we feed the opensocial activity streams in any
opensocial network by our activities which have been produced in our
product by the viewer?

If the container grants permission for you to do so then you use the REST API to POST an activity. Containers have different permission models for their activities but you can rely on the status codes in response to the API call to figure out what happened.

 

(3.2) What's your recommendations about mashup gadgets which provide
services/data  - from our product + other social sites - in the same
gadget
As of unclear documentation about implimentation of (google) OAuth
Servers (for service providers) & Container servers, we would be much
appreciated to get some advice/directions and best practices beside
what already published on the web!

There are a number of ways to do this. Your gadget running in container A can make calls to your backend which can then call container B for information. It will also be possible to have container A manage the credentials for Container B on behalf of your gadget and so your gadget can make the request without going through your server.  See the definition of the OAuth services in the gadget specification for details on this. An example is included in the Shindig code. See oauth.xml

[hertzel]

Hi
Thanks Louis.
The main issue here is the Oauth stuff.

Any insights/ correctness and assistance about the following (common)
opensocial-ouath scenario, would be much much appreciated:
(1) a gadget is deployed to a opensocial container - MySpace, iGoogle,
Hi5, Linkedin, ...
(2) the gadget communicates with the hosting opensocial-container (1)
and retrieves the viewer & owner profiles & activities
(3) the gadget communicates to OUR Product's Ouath-Restfull services
to retrieve and update the viewer/owner activities & profiles
(4) the gadget communicates to other oauth-enabled (& not aouth-
enabled) service providers (opensocial or not) to retrieve/update
profiles/activities like MYSpace, rememberthemilk, ...

Some questions:

As of my understanding the current gadgets-oauth extensions provides
OAuth Proxy, which "OAuths" the gadget against ONE Oauth Provider
through Oauth.json. How this (json configuration) should be done, on
public opensocila-containers (MySpace, iGoogle, ....)?

As of my understanding there is no container which provide the OAuth-
Proxy beside Orkut & iGoogle, so is the only path is using "manual
SIGNED" requests?

As of my understanding consuming services from more than one service
provider has to be done through our back-end (see louis answer) as the
current opensocial-containers do not provide the means for "multi-
server provider registration". is it true?!

In general, What's the straight-forward, COMMON and AVAILABLE
techniques to accomplish the 1-4 flow above?
Specifically: What are your recommendations to implement a opensocial-
gadget which accesses OAuth-enable and NOT OAouth-enabled Service
providers (Opensocials and not)?


I have red the most of specs & threads regarding the Oauth+opensocial
and could not conclude the common and right path!
Again any directions would be much appreciated.

Hertzel

> oauth.xml<http://svn.apache.org/viewvc/incubator/shindig/trunk/javascript/sampl...>

>
>
>
> > Hertzel
>
> > Hertzel Karbasi Enterprise Architect OPTinity eSolutions, CEO

> > Hert...@OPTinity.com +972.54.431.431.9 MeadoWare is Coming soon!
>
>

[Louis Ryan]

Hi,

Notes and comments below.

On Sun, Dec 14, 2008 at 4:05 AM, hertzel <her...@optinity.com> wrote:

Hi
Thanks Louis.
The main issue here is the Oauth stuff.

Any insights/ correctness and assistance about the following (common)
opensocial-ouath scenario, would be much much appreciated:
(1) a gadget is deployed to a opensocial container - MySpace, iGoogle,
Hi5, Linkedin, ...
(2) the gadget communicates with the hosting opensocial-container (1)
and retrieves the viewer & owner profiles & activities
(3) the gadget communicates to OUR Product's Ouath-Restfull services
to retrieve and update the viewer/owner activities & profiles
(4) the gadget communicates to other oauth-enabled (& not aouth-
enabled) service providers (opensocial or not) to retrieve/update
profiles/activities like MYSpace, rememberthemilk, ...

Some questions:

As of my understanding the current gadgets-oauth extensions provides
OAuth Proxy, which "OAuths" the gadget against ONE Oauth Provider
through Oauth.json.  How this (json configuration) should be done, on
public opensocila-containers  (MySpace, iGoogle, ....)?

Container support for the Oauth proxy feature as your rightly point out varies currently and so there are essentially two choices available. One where the container supports the 3-legged Oauth proxy and your gadget can make the calls to the needed targets without involving your backend and the other which requires your backend to route requests. Have you attempted to use the Oauth feature in a gadget on the networks you care about?

As of my understanding there is no container which provide the OAuth-
Proxy beside Orkut & iGoogle, so is the only path is using "manual
SIGNED" requests?

Those are the ones I know of but you should validate with the other containers you care about directly. 

As of my understanding consuming services from more than one service
provider has to be done through our back-end (see louis answer) as the
current opensocial-containers do not provide the means for "multi-
server provider registration". is it true?!

Thats not the case for containers that do have proxy support, you can register more than one OAuth service in the gadget. 

In general, What's the straight-forward, COMMON and AVAILABLE
techniques to accomplish the 1-4 flow above?
Specifically: What are your recommendations to implement a opensocial-
gadget which accesses OAuth-enable and NOT OAouth-enabled Service
providers (Opensocials and not)?

The one way thats guaranteed to work is to have your own servers route the requests but you should check with your target containers to see if you can do better. Accessing non-OAuth enabled services that are completely public can be done with makeRequest/Preload calls on ALL containers today. Acessing services protected by an authorization scheme other than OAuth is not supported by the spec currently and so you should use your own backends for those.