SMash – Something Useful from the OpenAjax Alliance?

Dietrich Kappe, Friday, February 8, 2008 @ 3:06 pm

In the announcement that the OpenAjax Alliance had released OpenAjax Hub 1.0, and would start to work toward 1.1, there was one thing that caught my interest: the news that 1.1 would support secure mashups. Given that proxies and JSONP are both pretty open to abuse by unscrupulous service providers, this was certainly welcome news? So, what exactly does this secure mashup support look like?

The nascent SVN repository at Sourceforge wasn't much help -- mostly just a placeholder for future work. A little digging reveals that the OpenAjax technology will be based on a technique known as 'SMash', developed at IBM for performing secure mashups. I was able to locate a copy of a research paper on SMash (not sure if this is meant to be public, so grab a copy).

The nut paragraphs here are the following:

 

Our abstraction involves encapsulating content from different trust domains as components running in a browser. Components are wired together using channels. The channel abstraction and security policies associated with channels are implemented by an event hub that is part of the Trusted Computing Base (TCB) from the mashup provider’s perspective. The only inter-component communication in the browser is realized using these channels.

   

We realize the component abstraction using the HTML <iframe> element, which was designed as a container for loading sub-documents inside the main document. Some technical challenges that we address are (1) enabling parent to child document communication links when the parent and child are from different trust domains, (2) ensuring integrity and confidentiality of information on these links, and (3) guarding against component phishing, where an untrusted component in a mashup can change which component is loaded in another part of the mashup.

So we're back to using iframe's
to do client-server communication. Very pre-Ajax, but still, it allows
you to do secure mashups without modifying the browser. What are the
essentials of SMash?

1. Each component is loaded into a separate iframe.
2. Communication
   between the messaging hub and the iframes takes place through
   modification of the iframe's 'location', specifically the fragment,
   i.e. the stuff after the '#' character. Changing that doesn't require a
   reload.
3. Embedded in each component's iframe is another iframe
   from the original, top-level mashup host. The component can modify the
   fragment, and this iframe can access the JavaScript context of the
   top-level window (i.e. window.parent.parent). So, now two-way communication is possible.
4. Fragment identifiers are picked up through polling in the targer iframe.
5. The messaging hub controls which components can send what sorts of messages to other components.

There's
a lot more detail in the paper, along with some security consideration,
and alternative implementation options. Obviously there is a limit on
the size of URL's, so there must be a limit on the size of fragment
identifiers and thus a limit on the maximum size of messages that can
be sent.

It's all a long way to go for secure mashups in
unmodified browsers, but the alternative -- modification of some W3C
standards -- looks unlikely at this point. You'll definitely want a
framework for this.

Technorati Tags: ajax, openajax, secure mashups, smash

Related posts:

1. My Mash Note to Microsoft, Newest Member of the OpenAjax Alliance
2. Mashup Styles
3. Remove/Cancel Bubbling for an Event in Flex3
4. Tibco GI/Craigs List Bashup
5. The Problem with JSON

Comments (1)

Software Development

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I think window.name is a much better approach than using iframes.

   Comment by Justin Meyer, Saturday, August 9, 2008 @ 4:17 pm

Leave a comment