iPhone Developer

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:

1. Mashups are often created by ‘end-users’ themselves;
2. Mashups can be shared with others who may be outside the firewall;
3. Mashups can be created from disparate sources which may be outside the firewall;
4. 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.

1. 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.
2. 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.
3. 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.