MAA Use Case UseridPwd

From MemberWiki

In this scenario the gadget server requires the end-user to authenticate to it. Functionally, this is just the gadget server popping up a password dialog for the user to enter credentials before the gadget download. There are a couple of variations on how the flows may work: The gadget server requires authentication before loading the gadget or the gadget is loaded immediately which then performs the authentication before invoking services or loading data. We should recommend that the second option be used as far as possible. Using the first option will impact for instance the timeouts in the SMash, the cross-frame provider used in the Hub and we would trigger the warnings about frame-phishing.

TBD: Detailed flow diagrams and gadget loading lifecyle discussions

Example of Loading a Widget with an Intermediate Page that does Redirection

This is a brief description of how a mashup application can load a widget through an intermediate page which redirects to the final widget page. The intermediate page would be in charge of setting the security policy. This example is more in line with the first option above, and as such would not be ideal for userid/password login, due to timeout issues.

A working version of this is checked into the OpenAjax SVN. You can see the code here: http://openajaxallianc.svn.sourceforge.net/viewvc/openajaxallianc/hub11/trunk/samples/redirection/.

There are three major components:

• Mashup - the mashup application
• Intermediary - the intermediate page which redirects to the final widget page
• Widget - the actual widget page

Loading the widget:

1. Mashup creates a Managed Hub.
2. Mashup creates an IframeContainer. The URI points to the Intermediary and the Widget URI is specified as a URL param (i.e. uri = "http://foo.com/intermediary.php?clientURI=http://foo.com/widget.php").
3. Intermediary loads and pulls Widget URI from URL params. Here we can implement our security policy, such as creating a cookie in the current domain based on a token passed as a URL param.
4. Intermediary redirects to the Widget URI.
5. Widget loads and creates an IframeHubClient, which establishes communication with Mashup.

Security

Note that in general using this method of authenticating to the gadget server has potential for increasing the attack surface for phishing attacks since the end-user is trained to enter user-id and password in the middle of the mashup page. Thus care must be taken to allow this only for authorized mashups.