OpenAJAX and similar mashups

The Problem

Mashups are an emerging class of web applications that are expected to gain widespread popularity. Loosely speaking, a mashup is an application that aggregates data and logic from different applications, often hosted by different service providers. In the “enterprise context” (as opposed to the “consumer context”) the fundamental allure of mashups is the promise of much faster deployment of business functionality by the IT Department. Or, better still (from the business point of view), the ability to deploy new functionality without any involvement of the IT Department.

So why is Joe the CSO troubled? While the business unit sees rapid functionality, and the IT Department sees cool new technology, Joe the CSO sees the mashup on the enterprise desktop as:

  • An unanticipated entry point for external sources into internal applications from a desktop inside the corporate perimeter.
  • An unanticipated exit point for sensitive corporate information.
  • A new way to compromise the desktop.

There have been several suggestions for reducing these risks. Almost all these suggestions fall into the category of “let us sandbox data/code from the external world and limit the harm it can do”. For instance, the OpenAJAX hub specification was recently augmented by a technology from IBM called SMash, which enforces policies on which widget can speak/listen to which widget. The problems and the proposed resolutions have much in common with trying to keep the desktop secure from Trojans, viruses and other malware, with the browser playing the role of the Operating System. In fact a research project from Microsoft, MashupOS, explicitly takes this stance.

There are two limitations to this general approach:

  • There is an obvious trade-off between functionality and security. Limit what the widget can do too much and you will lose functionality, and on the other hand, if an external widget has too many privileges then there is little security. This is a classic security problem. Ideally the enterprise would like to thread the needle by getting fine grained control of policy enforcement in a dynamic and context sensitive fashion. Observe that in the OpenAJAX architecture, the enterprise never gets to “see” the widget the hub has downloaded, and Joe the CSO need not be a control freak to feel some anxiety.
  • A second broader limitation is that it is very hard to ‘keep up’ with what malware can do. After decades of fighting the good fight against malware it is generally agreed that the anti-malware software on your desktop has severe limitations. This paper from Google Research for example makes rather dark reading. It has reached the point where in this instructive article, Mark Bregman, CTO of Symantec, argues that “whitelists” may become essential and that perhaps we will move to ‘reputation based systems’. Observe that in the context of widgets running within a browser mashup the code is likely to be dynamic Javascript and it is virtually impossible to collect ‘signatures’ of all allowed widgets to create a whitelist.

The intent of our work is not to argue against solutions like SMash or all the other approaches of constraining widgets. Rather we will simply show that all these solutions would benefit by being augmented with an approach where the enterprise plays an active real time role in controlling what widgets get downloaded from where, and craft a dynamic policy for that widget based on the context.

To summarize:

  1. The enterprise should have at least some control of interactions between an enterprise desktop and an external source. We believe that completely ceding enforcement of a policy to the browser is tantamount to losing control. The enterprise needs to be able to police what gets executed where.
  2. The enterprise should be able to “look behind the browser” to see where the browser is downloading widgets from and only allow such an action to proceed from a trusted source. This list of trusted sources will take the place of whitelists. While ‘signatures’ of every widget out there will be hard to obtain, we can at least ascertain the antecedents of the widget. Joe the CSO may have more faith in widgets coming from trusted business partners, than from other sites his enterprise user wants to mash with.

And optionally, while a widget might ‘run’ at the user’s desktop to take advantage of local computing power, perhaps Joe the CSO can sleep better if he has the option to inspect the widget before it gets loaded.

Integrating MashSSL

Let us return to Joe the CSO. He was nervous that uncontrolled mashups would create new points of ingress for attackers, egress for corporate data and, that malware ridden widgets would compromise the enterprise desktop. Let us assume that his enterprise uses the OpenAJAX specification to build mashups. He knows that the OpenAJAX SMash mechanism provides an inter-widget communication mechanism and the rules of who can talk to whom are governed by a static policy file.

He enforces three new rules:

  • Before a widget can be loaded into the enterprise hub (which runs on the user’s desktop), the web service it is being loaded from must create a MashSSL session with the enterprise hub control server through the user’s desktop. This allows him to be completely sure that the web service is run by one of the enterprise’s trusted partners.
  • Then based on who the enterprise user is, and who the partner is, he can dynamically send to the hub, customized for this user, policy settings that will govern inter widget communication for the newly loaded widget. We said earlier that such situations always have a functionality versus security trade off and that the smart enterprise wants to make fine grained context aware policy decisions. The architecture of MashSSL inherently allows it to let the enterprise be part of, and in control of, how the widget gets loaded.
  • And finally, Joe being the suspicious sort, is not entirely comfortable with how well some partners secure their sites. He is not quite ready to refuse to do business with them, but he wants to be able to run additional checks. For these sites, after MashSSL is established, he requires the remote site to send the enterprise hub control server the widget. It can be inspected for malware etc., and if it passes the test, then it (or a signature of it) is sent to the hub, which downloads the widget from the remote site, but only after ensuring it was the same one sent to the enterprise.

 

 

This is one, OpenAJAX based, example of how enterprise mashups can be deployed in a more controlled fashion using MashSSL. Different mashup architectures will find different ways to integrate and take advantage of MashSSL. The ability in MashSSL for an enterprise to securely look through the browser and see where the enterprise user is going is what architecturally provides the basis for enhanced enterprise security.

 

For the more technically inclined....