View source

<span style="color:blue">''NOTE: This wiki page used to be a chapter in the OpenAjax Hub 2.0 Specification. The Interop WG decided to transform this chapter into an OpenAjax white paper. So far, all that has been done towards the transition to white paper is extracting the chapter of the Hub 2.0 spec, include this comment at the top, and rename the wiki page''</span>

<br>

= OpenAjax Hub 2.0 and Mashup Assembly Applications =

<span style="color:red">2009-02-23 Howard said we need to make changes relative to frame phishing alerts</span> <span style="color:blue">''' 2009-04-27: Jon beefed up the security section substantially.'''</span>

== Introduction ==

<span style="color:red">2009-07-13 Jon added a handful of paragraphs to the introduction</span>

Mashups  represent a key technology component underlying "Web 2.0". Mashups allow easy integration of reusable Web components ("widgets"), data feeds (e.g., RSS or Atom), and Web services into a composite application. Mashups offer the potential for revolutionizing Web application development and provide the following benefit to companies:

*''Faster, cheaper delivery of applications''. A lower skill set is needed to assembly applications than to build new applications from scratch.
*''Support innovation and new business opportunities''. Users are empowered to innovate and explore.
*''Gain valuable insights''. Line-of-business users are able to remix Enterprise and Web information, which allows them to make connections and recognize patterns.
*''Better align IT and business''. The IT department can concentrate on building reusable Web services and making mashup tools available to the company’s employees. 
*''Extend reach and value of SOA''. Service reuse illuminates the business value of SOA.
*''Application development long-tail''. The IT department by necessity will focus its resources on the most important business systems. Mashups allow end users to address the long tail of company application development.

Mashups fall into two categories: 
*''Programmer-built mashups'' - Many Web applications built by individual Web developers fall into the programmer-built mashup category. In this scenario, a programmer uses Ajax technologies (e.g., HTML and JavaScript) to implement a Web page that combines 3rd-party web services, widgets and feeds as components within a Web page. 
*''User-built mashups'' - In this scenario, a non-programmer creates the mashup using mashup assembly tools, typically running in the browser. The mashup tools often allow the user to discover feeds and widgets from various sources, and then assemble those feeds and widgets onto a mashup canvas, possibly using drag-and-drop gestures to pull from a widget palette onto the mashup canvas. 

This white paper focues on ''user-built mashups'' that are enabled by ''mashup assembly applications''.

== How mashup assembly applications often work ==

=== Discovery and cataloging of useful widgets, feeds, and other data ===

Often, the first step in creating a user-built mashup is discovering the various data sources and widgets that provide the information and visualization features that is required in the mashup. Data sources typically consist of data feeds (often RSS or Atom), already-built widgets, and other miscellaneous forms of data (e.g., company spreadsheets). Various tools exist (in the illustration below, a "Discovery and cataloging tool") to help the user search for appropriate data sources and widgets, transform the data sources (e.g., applying filters and joins to data feeds), and build a catalog of mashup components. For the purpose of this discussion, it is assumed that all data sources (including feeds) and visual components are available in the form of widgets within a "widget catalog".


[[Image:Hub20WidgetDiscovery.png|600px]]


=== Assembling widgets onto the mashup canvas ===

Once the catalog contains the components needed by the mashup, the user runs a (perhaps different) mashup tool to assembly widgets onto the canvas, as shown below. Mashup tools often display a widget catalog from which the user drags widgets onto the canvas.

Often in a subsequent step, the widgets need to communicate with each other so that changes in one widget can trigger corresponding updates in other widgets. Sometimes the mashup tool is able to link widgets together automatically, but other times the mashup user needs to manually link widgets with each other. 

When a mashup tool includes OpenAjax Hub inside, widgets are linked together via the Hub's publish/subscribe engine. Whenever a widget needs to notify other widgets of a change in state, the widget ''publishes'' an event by calling one of the OpenAjax Hub's <code>publish()</code> methods. Other widgets ''subscribe'' to the given event topic. When the event is published, the Hub notifies subscribers, who are able to perform appropriate update actions in response to the event.


[[Image:Hub20MashupDesigner.png|600px]]


=== Running the mashup ===

Mashup tools that run in the browser typically have '''instant deployment''', meaning that upon completing the build and linking process on the mashup canvas, the mashup is available for immediate use both by the user who created the mashup and by other users who can access the URL at which the mashup was saved. To run the mashup, users simply navigate to the URL at which the mashup is stored.

In the picture below, note that upon deployment any design-time user interface, such as the widget gallery, does not appear. 

Also, observe that when the mashup executes, some of the widgets in the mashup communicate in the background with particular Web servers. This opens up the possibility of severe security vulnerabilities if the mashup does not have an appropriate mechanism for isolating widgets to prevent unauthorized information flow. For example, the company server in the picture may have granted read/write access to the data on the server to the mashup's Web page. This means if Widget-E or Widget-A were malicious, they could attempt to gather company confidential information or trigger malicious transactions. The Managed Hub feature in OpenAjax Hub addresses the security issues raised by mashups. The sections below describe how the Managed Hub feature provides a mechanism to isolate 3rd party widgets and includes a security manager mechanism such that the mashup container application can mediate the dispatching of messages that are passed among the widgets.


[[Image:Hub20MashupRunning.png|800px]]

== Widgets Overview ==

As mentioned previously, within this specification, the term "widget" refers to Web widgets, which represent a portable chunk of HTML/Ajax code that can be installed and executed within other HTML-based web pages. Widgets typically are placed within a rectangular area of the mashup canvas and present a user interface for viewing information and interacting with that information. Widgets often talk to a back-end web service in the background as they execute.

There are a significant number of proprietary widget formats used in the industry today. Some of the most popular proprietary widget formats support Ajax content (i.e., HTML+JavaScript+...) and use the browser engine to render that content. The main difference between these widget formats that support Ajax content is with the supplemental metadata file(s) that accompany the Ajax content. The metadata is often contained in a single XML file that provides information such as widget name, description, the URL for the server with which the widget needs to communicate, and the list of messaging topic names that the widget might communicate with other widgets.

OpenAjax Alliance provides a standard for Web widgets that has been designed to work closely with OpenAjax Hub, '''OpenAjax Widgets''', defined within its [[OpenAjax Metadata Specification]]. The OpenAjax Widget format includes appropriate XML metadata and JavaScript APIs that allow a widget to participate within a mashup assembly application that uses the OpenAjax Hub for widget isolation and message passing. The two specifications were developed in parallel by the members of OpenAjax Alliance to provide technologies that address two key issues with end-user mashups: widget interoperability and mashup security. OpenSocial Gadgets, developed by the [http://www.opensocial.org/ OpenSocial Foundation], represents another industry standard widget format.

== Mashup industry challenges ==

Two key challenges in the world of user-built mashups are ''interoperability'' and ''security''.

===Interoperability===
The industry has seen a rapid rise in the availability of widgets, but these widgets are expressed in several different widgets formats, which hinders interoperability, and thus goes against the remixability promise. OpenAjax Alliance is working to help the industry move towards greater widget interoperability, particularly due to its [[OpenAjax Metadata Specification]], which among other things defines an industry standard for Ajax-powered widgets.

===Security===
The Managed Hub features in OpenAjax Hub places a primary focus on the security challenges inherent with mashups. The full potential of mashups occurs when arbitrary users, without approval from a centralized authority such as a company's IT department, can import arbitrary widgets into their own mashup. However, the security techniques used in today's popular Web browsers did not anticipate the unique requirements of mashups, where 3rd party widgets co-exist with each other within the same Web page. A naively constructed mashup could very well allow malicious widgets to send the user's personal information to a malicious server, send company-private information to a malicious server, or trigger sensitive web transactions (e.g., an eCommerce transaction) using user credentials stored within cookies.

A key thrust for the Managed Hub is to prevent such attacks from malicious widgets. The Managed Hub feature extends the (typically intra-frame) publish/subscribe features found in the Unmanaged Hub by adding the ability to set up a managed hub (typically inter-frame) that allows incorporation of untrusted widgets from third parties. Untrusted widgets are isolated from the rest of the mashup (often using Iframes) such that all information exchange to and from each untrusted widget occurs over a secure, mediated message bus.


== Using the OpenAjax Hub within a Mashup Assembly Application ==

Mashup assembly applications typically use the OpenAjax Hub for the following features:

* Widget isolation using the Managed Hub
** Untrusted widgets can be isolated into secure sandboxes (typically using the IframeContainer within the Managed Hub)
** Trusted widgets can be either isolated into secure sandboxes or, typically for performance reasons, placed inline within the mashup assembly application's frame (typically using the InlineContainer)
* Secure message passing among the various widgets and the mashup assembly application, under control of a security manager provided by the mashup assembly application

The following illustration, repeated from the Managed Hub Overview chapter, shows typical usage of the Managed Hub. The key difference within a mashup assembly application is that the components will consist of widgets, typically using an industry standard widget format.


[/images/ManagedHubUsage.png /images/ManagedHubUsage.png]


=== Additional features added on top of the Hub ===

In practice, mashup assembly application typically will add higher-level logic on top of the OpenAjax Hub in order to provide a mashup assembly solution to the end user. Among the common things that might be added to the Hub:

* '''Initialize the Managed Hub''' - The mashup assembly application will need to instantiate at least one Managed Hub instance
* '''Support for one or more widget formats'''. Typically, a mashup assembly application will include support for particular well-documented widget formats. Two industry standard formats for mashable widgets are:
** '''OpenAjax Widgets''' - defined in the [[OpenAjax Metadata Specification]].
** '''OpenSocial Gadgets''' - defined by [http://www.opensocial.org/ OpenSocial] specifications
* '''Widget discovery''' - A mashup assembly application typically includes user interface element that allow the end-user to find useful widgets, where the widgets might be located on company servers and/or located on the general Internet
* '''Widget assembly''' - A mashup assembly application typically includes user interface that allows a user to add widgets onto the mashup canvas and customize property settings on individual widgets. The process of adding a widget to the mashup canvas typically requires the mashup assembly application to invoke OpenAjax Hub APIs as follows:
** Parse the widget's metadata. (Note: both OpenAjax Widgets and OpenSocial Gadgets specify widget metadata in XML)
** Instantiate a '''Container''' (e.g., '''IframeContainer''' or '''InlineContainer''') and attach the new Container to the Managed Hub
** Instantiate a corresponding '''HubClient''' object  (e.g., '''IframeHubClient''' or '''InlineHubClient''')
** Extract the widget's presentation markup (often HTML, CSS and images) and logic (typically, JavaScript) and incorporate into the assembly, making the HubClient object available to the widget's JavaScript logic
** Note that when using the IframeContainer, it is usually necessary to manufacture a new HTML page for each widget whose URL will be the <code>src</code> attribute on the <code>&lt;iframe&gt;</code> element that will contain the widget. This URL will typically have a different sub-domain than the mashup assembly application or any of the other widgets (see "Security concerns" below).
* '''Widget wiring''' - A mashup assembly application typically includes user interface that allows a user to control message passing among widgets, some of which will be message publishers, some which will be message subscribers, and some which will do both.
* '''Mashup load and save''' - Once the user has assembled his mashup and wired the widgets to each other, he will want the mashup to be saved for later use. Often, mashup assembly applications will save a particular mashup at a particular URL on a Web server. The user (or other users) typically can retrieve that mashup by returning to that URL.
* '''Security''' - It is imperative that mashup assembly applications pay close attention to security concerns. One of the key design goals for OpenAjax Hub is to deliver a framework for secure mashups via its Managed Hub features. See below for "Security concerns".

=== Security concerns ===

To deliver a secure environment to end-users and their organizations, mashup assembly applications that use OpenAjax Hub must pay close attention to security concerns. Each implementation of the OpenAjax Hub should implement various security techniques to guard against malicious attacks and include clear documentation of what a Manager Application must do in order to provide a secure mashup runtime. This section highlights various security concerns and describes some of the techniques used within OpenAjax Alliance's open source reference implementation of OpenAjax Hub 2.0 (the "reference implementation").

One fundamental issue facing mashup assembly application is classifying clients as either trusted or untrusted. This determination should be made by IT experts. When not absolutely sure about the trustworthiness of a particular client, then that client should be classified as untrusted. When using the reference implementation, trusted clients that are suitable for inclusion inline within the main mashup application are candidates for the InlineContainer, which has performance advantages over the IframeContainer. All other clients should use the IframeContainer so that they are isolated into a secure sandbox.

Mashup assembly applications need to provide a security manager component that includes a policy manager to control message flow among the clients. The policy manager APIs in Hub 2.0 are fine-grained and provide the manager application with the ability to allow or deny each separate client subscription request and, for each published message, whether to allow or deny transmission of that message to a particular client. In the reference implementation, the security manager is fully configurable. It is critical that the mashup assembly application establish and implement a carefully crafted conservative security manager that defaults to deny all requests from untrusted clients, and only allows requests from untrusted clients for selected actions that are known to be appropriate for that client. One simple technique for establishing a security manager is to default to deny all, but then allow requests between particular message publishers and message subscribers on particular (usually non-wildcard) topics, based on explicit end-user actions when running the mashup application's GUI, such as drag-and-drop gestures that link a particular client publisher with a particular client subscriber on a single message topic.

One common requirement with implementations of the OpenAjax Hub is for the server to provide a large set of sub-domains. In the reference implementation, the IframeContainer isolation feature within the Managed Hub takes advantage of the same-domain security features found in modern Web browsers. Each separate client must be in a different domain or sub-domain to achieve successful isolation.

<span style="color:blue">''Therefore, it is often a requirement that the mashup assembly application's server provide a pool of sub-domains (e.g., a001.mydomain.com, a002.mydomain.com, etc.) and that the mashup assembly application ensure that each different client that uses the IframeContainer have its Iframe URL (i.e., the <code>src</code> attribute on the <code>&lt;iframe&gt;</code> element) within a different sub-domain than the mashup assembly application and any of the other clients.''</span>

Mashup assembly applications also need to manage the life cycle of clients, particularly loading and unloading actions, to guard against frame phishing attacks. The open source reference implementation of Hub 2.0 passes a unique randomly-generated manager security token at load time to each client and has a short timeout period within which the client must respond. The reference implementation includes other safeguards, such as raising errors if the client application unloads unexpectly and requiring that each message from clients include the manager security token.

Mashup assembly applications should establish safe, private communications channels that prevent malicious clients from monitoring communications with other clients in the mashup and prevent malicious components from generating forged messages that can be sent to other clients. The alliance's reference implementation takes advantage of HTML5 postMessage in recent browsers and fragment-identifier messaging (FIM) techniques on older browsers, where each of the methods is used in a manner such that only the manager application and a single client can read and write on their private communications channel.

The alliance's reference implementation makes use of two encypted unique randomly-generated security tokens, one on the manager side and one on the client side. This technique helps the manager application ensure that it is receiving a message from the same client that it previously loaded and helps the clients ensure that they are interacting with the manager application and not a malicious software component.

== Open source mashup assembly application that uses OpenAjax Hub and OpenAjax Widgets ==

The members of OpenAjax Alliance have developed an open source reference implementation of OpenAjax Hub that supports OpenAjax Widgets (as defined in the [[OpenAjax Metadata Specification]]) and can be adapted to support proprietary widgets via message bridging technologies. Key URLs:

* [/2008_InteropFest/mashupapp/gadgets/samples/newmashup.php running application]
* [http://sourceforge.net/projects/openajaxallianc open source project]

<span style="color:red">Probably need a new URL for sample mashup application that doesn't include "2008_InteropFest" in the URL.</span>