shindig-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ciancetta, Jesse E." <>
Subject RE: Integration with Custom Authentication
Date Tue, 08 Mar 2011 20:52:46 GMT
>-----Original Message-----
>From: Folke Mitzlaff []
>Sent: Tuesday, March 08, 2011 12:57 PM
>Subject: Re: Integration with Custom Authentication
>Hi Jesse,
>thank you for your for your fast response! I implemented a draft version
>of the authentication integration which works as expected
>( also gives
>a practical hint).
>Now I'm curious: You already mentioned, that the security tokens might
>be easily spoofed - especially when using the

Well -- not spoofed -- but potentially misused if they get leaked in HTTP referrers.  I've
seen different recommendations on how this could be avoided, like using a very short lived
token in the iframe URL and replacing it on the Shindig side during the gadget rendering process
with a longer lived token -- but I've never really dug into the mechanics of how that might
work.  I've also seen talk of including the security token after a hash in the URL (
since content after the hash doesn't get sent in HTTP referrers, but then the Shindig server
wouldn't have access to the token at gadget render time either which limits some of the useful
things you can do server side like data pipelining.

>What about implementing a custom
>AuthenticationHandler which builds for every incoming http-request a new
>security token based on the cookie/session credentials? Doing so - the
>incoming security token might be ignored. Does this sound like an odd
>idea which breaks with some fundamental security considerations?

I think whether or not something like this would work depends on your configuration.  If you're
rendering potentially untrusted gadgets written by a third party you'll want to be sure to
render them on jail domains (search the archives of this list for more details on that) which
means that your gadgets would be running on a different domain than your container page --
so the authenticated session that exists for your users on your container page likely wouldn't
propagate back to your Shindig server.  If you don't need to run gadgets on a jail domain
though and you have everything running on the same domain I don't really see any reason why
you couldn't do something like what you've proposed.

>Again - thanks a lot,
>On 03/08/2011 01:57 PM, Ciancetta, Jesse E. wrote:
>> Hi folke,
>> It sounds like you're trying to figure out how to tell Shindig who the
>current user is when gadgets use API's like or
>opensocial.newDataRequest -- and for that we use the SecurityToken:
>> SecurityTokens are typically generated by the container (your
>application) and then added to the gadget iframe URL as a request
>parameter (st=container:security-token-here).  Shindig can then pick it
>up to be used at gadget render time for things like server side data
>pipelining, and then on the client side the gadgets API parses out the
>token to be used when making calls back to Shindig for things like
>makeRequest or OpenSocial data calls.
>> Security tokens are typically encrypted and usually short lived since
>(depending on how they're passed to shindig) they can be easily leaked
>in HTTP referrers.
>> You can find an example of generating security tokens in OSEC (a Java
>based OpenSocial container) here:
>> Or if you're working with PHP you can also have a look at Partuza (a
>PHP based OpenSocial container).
>> --Jesse
>>> -----Original Message-----
>>> From: Folke Mitzlaff []
>>> Sent: Monday, March 07, 2011 11:34 AM
>>> To:
>>> Subject: Integration with Custom Authentication
>>> Dear List,
>>> I plan to integrate Shindig into our web application which uses
>>> and cookies for authentication/authorisation based on the spring
>>> security framework.
>>> Though I searched and browsed the web, I wasn't able to stumble upon
>>> intended way of integrating (our) external authentication framework
>>> Shindig. More precisely: Whenever a gadget requests data, e.g., via
>>> our container 'knows' who is querying - based on the session/cookie
>>> information. But how should I inject these credentials into Shindig,
>>> e.g. for validating the viewer id?
>>> Any hint is appreciated.
>>> Best wishes,
>>> .folke

View raw message