You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "VU, Thi Thu Thuy" <th...@sap.com> on 2010/02/23 10:30:58 UTC

Security in Shindig

Hello,

I'm new in Shindig. And i don't know how they make security in Shindig.
Could you give me some information?

Thanks very much.

RE: Security in Shindig

Posted by "VU, Thi Thu Thuy" <th...@sap.com>.
Oh, il helps very much.
Thank you
Have a nice day!
________________________________
From: Jacky Wang (王超) [mailto:chaowang@google.com]
Sent: Dienstag, 23. Februar 2010 11:11
To: VU, Thi Thu Thuy
Cc: dev@shindig.apache.org
Subject: Re: Security in Shindig

Hi VU,

Although I'm not quite sure what does your "security" specifically refer to, the high level of what Shindig does is:

Basically, Shindig is the reference implementation of OpenSocial Spec, and it's the de-facto production ready implementation, which has been deployed on 20+ SNS, as well.

According to the OpenSocial spec, there're 3 major ways to access social data: a) "client-side way" through JavaScript APIs, b) "server-side way" through server-to-server RESTful/RPC requests, and c) "inline way" through OSML + tags.

Let's discuss ways a & b first.

For the way a, JavaScript APIs actually call the underneath RPC APIs to fetch social data.  Thus we'll focus on the RESTful/RPC APIs' security.

Shindig provides 3 different ways to verify whether a incoming social data request is valid:
1) assume this user is an anonymous user.
    you may like to disable the anonymous bit in the container config file.
2) validate the "Security Token", or a.k.a "st token", through "URLParameterAuthentication".
    This st token is issued by the container when rendering this gadget.  It embeds the useful info like viewerId, ownerId, appId, etc., and signed + encrypted.  Therefore the Shindig server (Social Data Gateway) validates whether the st token is correct, and your data access logic (resides in your implementation of people/activity/appdata services) could response the request properly according to these embedded info.
3) validate the "OAuth token", through "OAuthAuthentication".
    For short, Shindig supports OAuth protocol thus the requester could integrate the OAuth authorization flow to generate a valid OAuth access token, and uses this token to issue the request.

For the way c, basically it happens on the gadget rendering stage (<iframe src="http://shindig/ifr?...").  In that stage a st token will be appended to the rendering request URL.  Thus the authentication follows the #2, URLParameterAuthentication flow.

Hope it helps.

Regards,
Jacky

On Tue, Feb 23, 2010 at 5:30 PM, VU, Thi Thu Thuy <thi.thu.thuy.vu<http://thi.thu.thuy.vu>@sap.com<http://sap.com>> wrote:
Hello,

I'm new in Shindig. And i don't know how they make security in Shindig.
Could you give me some information?

Thanks very much.



--
Best Regards,

Jacky Wang
(Office) +86-10-6250-3316
(Mobile) +86-1381-0018-677
Kejian Building, Tsinghua Science Park Building 6
No.1 Zhongguancun East Road, Haidian District
Beijing P.R.China 100084

Re: Security in Shindig

Posted by "Jacky Wang (王超)" <ch...@google.com>.
Hi VU,

Although I'm not quite sure what does your "security" specifically refer to,
the high level of what Shindig does is:

Basically, Shindig is the reference implementation of OpenSocial Spec, and
it's the de-facto** production ready implementation, which has been deployed
on 20+ SNS, as well.

According to the OpenSocial spec, there're 3 major ways to access social
data: a) "client-side way" through JavaScript APIs, b) "server-side way"
through server-to-server RESTful/RPC requests, and c) "inline way" through
OSML + tags.

Let's discuss ways a & b first.

For the way a, JavaScript APIs actually call the underneath RPC APIs to
fetch social data.  Thus we'll focus on the RESTful/RPC APIs' security.

Shindig provides 3 different ways to verify whether a incoming social data
request is valid:
1) assume this user is an anonymous user.
    you may like to disable the anonymous bit in the container config file.
2) validate the "Security Token", or a.k.a "st token", through
"URLParameterAuthentication".
    This st token is issued by the container when rendering this gadget.  It
embeds the useful info like viewerId, ownerId, appId, etc., and signed +
encrypted.  Therefore the Shindig server (Social Data Gateway) validates
whether the st token is correct, and your data access logic (resides in your
implementation of people/activity/appdata services) could response the
request properly according to these embedded info.
3) validate the "OAuth token", through "OAuthAuthentication".
    For short, Shindig supports OAuth protocol thus the requester could
integrate the OAuth authorization flow to generate a valid OAuth access
token, and uses this token to issue the request.

For the way c, basically it happens on the gadget rendering stage (<iframe
src="http://shindig/ifr?...").  In that stage a st token will be appended to
the rendering request URL.  Thus the authentication follows the #2,
URLParameterAuthentication flow.

Hope it helps.

Regards,
Jacky

On Tue, Feb 23, 2010 at 5:30 PM, VU, Thi Thu Thuy
<th...@sap.com>wrote:

> Hello,
>
> I'm new in Shindig. And i don't know how they make security in Shindig.
> Could you give me some information?
>
> Thanks very much.




-- 
Best Regards,

Jacky Wang
(Office) +86-10-6250-3316
(Mobile) +86-1381-0018-677
Kejian Building, Tsinghua Science Park Building 6
No.1 Zhongguancun East Road, Haidian District
Beijing P.R.China 100084