>-----Original Message----- >From: Folke Mitzlaff [mailto:[email protected]] >Sent: Tuesday, March 08, 2011 12:57 PM >To: [email protected] >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 >(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.
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 (http://gadgetserver.com/gadgets/ifr?url=mygadget_url&other_params...#st=container:token) 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, > >.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/securit >y/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:[email protected]] >>> Sent: Monday, March 07, 2011 11:34 AM >>> To: [email protected] >>> 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 >>
