Thursday, March 13, 2008

Enterprise Mashup Security 101

Gartner published a report recently on Web 2.0 security, ‘Security Features Should Be Built Into Web 2.0 Applications’, a follow-up to their November 2006 ‘Web 2.0 Needs Security 101'. Excerpting straight from the more recent report: ‘The distributed and dynamic nature of Web 2.0 complicates security protection for enterprises and individuals.’ Understated, to say the least.

So this got me thinking on the unsexy-but-critical topic of mashup security. We have posted in the past about ‘Confidence’ and ‘Governance’, but these have generally been non-specific. So let me try to get a bit practical. The question isn’t a simple one but it is certainly worth noodling: How do we execute mashups safely in the context of the enterprise?

I think we are all aware of the security landscape today. On the technology level alone, security is a messy word of old and new systems that do or do not have any connection to corporate monitoring, authentication, authorization, and logging solutions. And it gets even more complicated once you add the ever-changing set of mandated and self-imposed privacy and data control policies and regulations. You can begin to understand why Enterprise Security Architects don’t get much sleep.

Mashups must play nicely in this complicated security ecosystem. For the sake of this discussion, let’s use this working definition of a mashup: ‘an enterprise mashup is a user-driven micro-integration of internal and external data’. From this definition, we can extract the following important security meta-requirements:

Mashups are often created by ‘end-users’ themselves; Mashups can be shared with others who may be outside the firewall; Mashups can be created from disparate sources which may be outside the firewall; Mashups can be created from disparate sources which may be of disparate interface formats (RSS, REST, WSDL, and SQL Databases, most likely).

Generally, meeting these meta-requirements can get very complicated very quickly. But it can’t be done as an afterthought! You must be proactive and persistent. Based on these meta-requirements, I’d propose the following Enterprise Mashup Security Guidelines.

Entitle and Propagate. Your enterprise mashup must manage the user authentication inherently, delegate the credentials the appropriate identity management system and all mashed-up services. Your enterprise mashup solution must also allow the mashup creator to specify desired entitlements. And all of this must be treated uniformly and seamlessly when mashing up internal and external services. Standardized but Agile. Your enterprise mashup must propagate credentials in the format the source services require. And this security/credential propagation must be built into the architecture because standards are weak here. Of the four service types, only JDBC/ODBC compliant databases and WSDL (via WS-SecurityPolicy) have a somewhat ‘standard’ credentials format, albeit ill-adopted. Therefore, your enterprise mashups must have the flexibility to pass user credentials in whatever form the service providers require, perhaps leaving a placeholder for new standards or custom formats. Portable and Syndicatable. Mashups and mashlets provide the portability for mashups to be syndicated. Imagine your mashlet embedded in a Web 1.0 portal such as BEA and Oracle Portal or in a Web 2.0 interface such as Netvibes, Pageflakes, or your iPhone, that mashup widget must maintain portable security and governance no matter where it goes.

Enterprise Mashups have the potential to be the technology equivalent of the Wild West. Follow the Guidelines and you’ve got yourself a sheriff. Ignore the Guidelines and you could get yourself some quality time in the pokey.


Posted by Chris Warner

Labels: enterprise mashups, gartner, mashup security

DiggIt!

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

You are viewing a mobilized version of this site...
View original page here

Mobilized by Mowser Mowser