shindig-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Folke Mitzlaff <mitzl...@cs.uni-kassel.de>
Subject Re: Integration with Custom Authentication
Date Tue, 08 Mar 2011 17:57:22 GMT
Hi Jesse,

thank you for your for your fast response! I implemented a draft version 
of the authentication integration which works as expected 
(http://web.archiveorange.com/archive/v/xmLKo1VvCZVCl9YdqZyA also gives 
a practical hint).

Now I'm curious: You already mentioned, that the security tokens might 
be easily spoofed - especially when using the 
UrlParameterAuthenticationHandler. 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?

Again - thanks a lot,

.folke

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 gadgets.io.makeRequest or opensocial.newDataRequest -- and for
that we use the SecurityToken:
>
> http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/SecurityToken.java
>
> 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:
>
> http://code.google.com/p/osec/source/browse/src/org/mitre/portal/security/impl/EncryptedBlobSecurityTokenService.java
>
> 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 [mailto:mitzlaff@cs.uni-kassel.de]
>> Sent: Monday, March 07, 2011 11:34 AM
>> To: users@shindig.apache.org
>> Subject: Integration with Custom Authentication
>>
>> Dear List,
>>
>> I plan to integrate Shindig into our web application which uses sessions
>> 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 the
>> intended way of integrating (our) external authentication framework into
>> Shindig. More precisely: Whenever a gadget requests data, e.g., via rpc,
>> 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
>


Mime
View raw message