Problems with two-legged OAuth, Single Sign-on, and gadgets.rpc working together

["Shtein, Ilya" <Il...@fisglobal.com>]

Hello,
We are having trouble getting gadgets.rpc - based remoting to work in
scenarios that involve OAuth and Single Sign-on. I wonder if I can get
any help finding a solution here.

We are developing an enterprise application portal using Shindig as a
gadget renderer. The portal serves as a single entry point, so that the
user can login once, and then work with gadgets representing data from
multiple applications. We are using a company standard single sign-on
solution, which requires SSO tokens to be sent to the application in a
form. The workflow is:
1. A lightweight, HTML -style gadget loads and posts a request (through
makeRequest) to Shindig-based Portal server to build OAuth tokens.
2. Once the portal server receives the request, it builds the OAuth
tokens and posts them to the service provider component.
3. The service provider verifies the tokens and replies with a form
containing SSO tokens.
4. The form is sent back to the lightweight gadget, which submits the
form to the appropriate application.
5. As a result, the entire contents of the gadget-hosting iframe is
completely replaced with an application page (JSP or ASP.NET) containing
actual data from the application the user wants to work with. This page
establishes a session with its application, and the user is ready to
interact with the application directly.
 
As part of the workflow, the gadget must be able to communicate with the
portal page (for example, to display a popup window in the context of
the page). The obvious choice here would be gadgets.rpc, which takes
care of the involved cross-domain issues in a browser-independent way
(we support IE6 and up, Firefox 3. and Safari). However, in the scenario
explained above, the iframe content is no longer rendered by Shindig,
which results in gadget-to-container communication failing
(container-to-gadget still works). While playing with both legacy (ifpc)
and windows.postMessage communications, we traced the ifpc failure to
the way target frame is determined in rpc_relay.html; this failure
results in a cross-domain security exception. It's not yet clear what is
causing the HTML5 channel to fail in gadgets.rpc. 
As a quick workaround, I built a channel for gadget-to-container
communications using an invisible iFrame technique (the lowest common
denominator, because we have to support browsers that are not
HTML5-compliant). But it seems wrong that I have to build a workaround
rather than simply use a channel that is part of the Gadget
specification (gadgets.rpc). 

So the question is: Is gadgets.rpc broken? After all, its purpose is to
facilitate *cross-domain* communications according to the Gadget spec;
the spec doesn't impose any limitations on what its endpoints may be.
Any suggestions regarding how to make this work? Any ideas are
appreciated!

Thanks in advance!
Ilya Shtein

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________

Re: Problems with two-legged OAuth, Single Sign-on, and gadgets.rpc working together

[John Hjelmstad <fa...@google.com>]

Hi Ilya:

It doesn't sound like gadgets.rpc is broken, just that it's not properly
reinitialized.

The OAuth/SSO issues don't sound to me to be particularly relevant aside
from the fact that your full scenario involves changing the IFRAME
fundamentally - new URL, new content (not actually a "gadget" anymore, just
a gadget-generated IFRAME), and importantly from the perspective of
gadgets.rpc's impl, A) at a different time than the IFRAME was generated, B)
perhaps without key parameters necessary for it to be initialized.

Due to the underlying transport techniques it uses, as well as to ensure
security properties, gadgets.rpc's initialization requires the following:
1. IFRAME rendered with parameter &parent=<protocol://host[:port] of
container> and &rpctoken=<random/unguessable string>. These may be provided
as fragment or query parameters.
2. IFRAME's "name" and "id" are set to the same value. Call it <gadgetId>.
This isn't a strict requirement - only "name" is really required - but is a
convenience used by the library.
3. Container calls "gadgets.rpc.setAuthToken(<gadgetId>, <rpctoken>);" or
the new API "gadgets.rpc.setupReceiver(<gadgetId>);", the latter recently
introduced to better facilitate use of the lib as a generic IFRAME <->
Container communication library (despite its only prescribed use being
gadget-related, many have requested this).
  - Importantly, this call must be made whenever the IFRAME URL changes.

With all this said, gadgets.rpc wasn't initially designed for use in this
way, so there may be some quirks to work out.

--j

On Thu, Jan 7, 2010 at 3:34 PM, Shtein, Ilya <Il...@fisglobal.com>wrote:

> Hello,
> We are having trouble getting gadgets.rpc - based remoting to work in
> scenarios that involve OAuth and Single Sign-on. I wonder if I can get
> any help finding a solution here.
>
> We are developing an enterprise application portal using Shindig as a
> gadget renderer. The portal serves as a single entry point, so that the
> user can login once, and then work with gadgets representing data from
> multiple applications. We are using a company standard single sign-on
> solution, which requires SSO tokens to be sent to the application in a
> form. The workflow is:
> 1. A lightweight, HTML -style gadget loads and posts a request (through
> makeRequest) to Shindig-based Portal server to build OAuth tokens.
> 2. Once the portal server receives the request, it builds the OAuth
> tokens and posts them to the service provider component.
> 3. The service provider verifies the tokens and replies with a form
> containing SSO tokens.
> 4. The form is sent back to the lightweight gadget, which submits the
> form to the appropriate application.
> 5. As a result, the entire contents of the gadget-hosting iframe is
> completely replaced with an application page (JSP or ASP.NET) containing
> actual data from the application the user wants to work with. This page
> establishes a session with its application, and the user is ready to
> interact with the application directly.
>
> As part of the workflow, the gadget must be able to communicate with the
> portal page (for example, to display a popup window in the context of
> the page). The obvious choice here would be gadgets.rpc, which takes
> care of the involved cross-domain issues in a browser-independent way
> (we support IE6 and up, Firefox 3. and Safari). However, in the scenario
> explained above, the iframe content is no longer rendered by Shindig,
> which results in gadget-to-container communication failing
> (container-to-gadget still works). While playing with both legacy (ifpc)
> and windows.postMessage communications, we traced the ifpc failure to
> the way target frame is determined in rpc_relay.html; this failure
> results in a cross-domain security exception. It's not yet clear what is
> causing the HTML5 channel to fail in gadgets.rpc.
> As a quick workaround, I built a channel for gadget-to-container
> communications using an invisible iFrame technique (the lowest common
> denominator, because we have to support browsers that are not
> HTML5-compliant). But it seems wrong that I have to build a workaround
> rather than simply use a channel that is part of the Gadget
> specification (gadgets.rpc).
>
> So the question is: Is gadgets.rpc broken? After all, its purpose is to
> facilitate *cross-domain* communications according to the Gadget spec;
> the spec doesn't impose any limitations on what its endpoints may be.
> Any suggestions regarding how to make this work? Any ideas are
> appreciated!
>

> Thanks in advance!
> Ilya Shtein
>
> _____________
>
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. Thank you.
> _____________
>