InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Security for Services and Mashups

Posted by Steven Robbins on Apr 17, 2008

Sections
Architecture & Design,
Development,
Enterprise Architecture
Topics
SOA ,
Web 2.0 ,
Enterprise Architecture ,
Architecture ,
Security
Tags
BEA ,
IBM ,
Enterprisey ,
Mashups
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.
  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.