Security for Services and Mashups

Posted by Steven Robbins on Apr 17, 2008 06:42 AM

Community

Architecture,

SOA

Topics

Enterprise Architecture ,

Web 2.0 ,

Security

Tags

Enterprisey ,

IBM ,

Mashups ,

BEA

Security has become a rising concern in most applications and systems today. Whether you are building small mashups, enterprise applications, or a platform for SOA, there are several issues and approaches that are being discussed. Erica Naone talked about dealing with security in the world of mashups recently while Bob Rhubart and David Garrison from BEA discussed securing the services you deploy. Naone talked with experts in the industry from the OpenAjax Alliance, Microsoft Research, information security firm Mandiant, and mashup maker JackBe in assessing the current state and future concerns of mashup security. In general, the browser security model is not up to the task of providing a model for security mashups.

Web browsers weren't designed with mashups in mind, and 'the warts have been there from day one', [David Boloker, cofounder of the OpenAjax Alliance and IBM's CTO of Emerging Internet Technologies] says. Browsers contain a security feature called the same-origin policy that's meant to keep malicious code hosted on one site from grabbing data, such as stored credentials, off another site. The same-origin policy prevents websites from one domain from requesting data belonging to another domain.

Helen Wang from the systems and networking group at Microsoft Research goes further into the failing of the same-origin policy:

[T]he same-origin policy fails by forcing 'Web applications today to either sacrifice security or functionality.' She says that a lot of great functionality, such as that of mashups, comes from using tools from multiple sources. The problem is that when the website creator embeds code written by a third party on her site, the same-origin policy no longer offers any protection, and the embedded code likely has access to information stored on the creator's site.

Some of the solutions proposed include relaxing the same-origin policy in the browser coupled with adding additional controls. Wang suggest that the controls work within the browser in the form of "sandboxing" the external code to prevent it from having too much access. Others recommend external, third-party tools to secure communications and applications without changing the browser. One such example is SMash, a "secure mashups" application recently announced by IBM:

SMash addresses a key part of the browser mashup security issue by keeping code and data from each of the sources separated, while allowing controlled sharing of the data through a secure communication channel.

Most of the industry seemed to indicate that mashup security is still not a solved problem and will be a rising concern as Web 2.0 applications become more ubiquitous. Not all applications are mashups, though and BEA has focused on developers who are creating services that will be deployed in their organizations. Bob Rhubart talked about security as part of the overall SOA initiatives in a company. He said that security is a fundamental piece to the overall governance of any SOA:

To describe security as an important part of SOA Governance is bit like describing water as an important part of the lives of fish, which is to say, it's an obvious point. Like everything else in SOA governance, security is a multifaceted issue. But SOA security boils down to knowing the answer to one simple question: Who is using your stuff? Each service deployed within your SOA represents a significant investment, and significant potential ROI. One of the fundamental goals of SOA governance, of course, is to insure that the use of each service generates the expected return. Key to realizing that return is controlling who has access to those services, and controlling how those who have access actually use those services.

Rhubart pointed out David Garrison and BEA's Security Services framework as an example of how to get it done. Garrison pointed out that BEA uses a Security Services framework model within their products and then discussed the fundamentals of designing such a framework using the AquaLogic Enterprise Security (ALES) products. Garrison identified that there are 5 major services/providers in a security services framework and described the responsibilities of each. The 5 items are:

• Authentication
• Role Mapping
• Authorization
• Credential Mapping
• Audit

Unsurprisingly, the listed items are not really different from a traditional application-focused security framework.

• Older >