如今，安全问题在大多数应用和系统中正日益受到关注。无论你是创建小型的 mashups、开发企业级应用或是构建 SOA 平台，总会牵扯到有一些（安全相关的）问题和手段。Erica Naone 最近就在 mashup 的世界里如何处理安全问题发表了他的看法，与此同时，来自 BEA 的Bob Rhubart和David Garrison讨论了怎样来确保你部署服务的安全。 Naone 和来自OpenAjax 联盟、微软研究院、信息安全公司Mandiant，以及 Mashup Maker（mashup maker 是用于运行和创建 Mashup 的组装环境。）公司JackBe的业界专家一起讨论并评估了 mashup 安全的现状以及未来的关注点。总体而言，现有浏览器的安全机制已经不足以为安全的 mashup 应用提供模型上的支持了。
Web 浏览器设计之初并未考虑进 mashup 应用，‘这个疮疤自它诞生之日就有了’[David Boloker，OpenAjax 联盟创始人之一，IBM 新兴网络技术 (Emerging Internet Technologies) 的 CTO] 说到。浏览器包含一种叫同源策略的安全机制，能够防止一个站点的恶意代码从另一站点上抓取诸如存储的证书之类的数据。同源策略限制了来自一个域的站点向另一个域请求数据。来自微软研究院系统与网络组的 Helen Wang 进一步指出了同源策略的失败之处：
同源策略的失败在于它迫使‘现在的网络应用，要么选择牺牲掉安全，要么选择牺牲掉功能。’她提到很多很棒的功能（比如 mashup）来自于使用各个来源的工具。问题是当站点的创建者在自己的站点嵌入第三方代码时，同源策略不再提供任何的保护，因此这些嵌入代码极有可能获得对存储于该站点的信息的访问权限一些提出的解决方案包括：在辅以额外控制的同时，放宽同源策略的限制。Wang 建议以“沙盒”的形式在浏览器内对外部代码加以控制，避免（这些代码）获得过多的权限。也有人推荐用外部的、第三方工具来确保应用程序通信安全，这种方式不必改动现有的浏览器。一个这样的例子是 IBM 最近宣布的sMash，一个“安全的 mashup”应用：
sMash 致力于解决浏览器 mashup 安全问题中的一个关键部分，使来自于异源的数据和代码相互分离，与此同时，通过一个安全的通信通道充许数据在受控状态下得以共享业界的大多数人都试图表明 mashup 安全仍是一个悬而未决的问题，随着 Web2.0 应用的普及，这一问题将会得到越来越多的关注。尽管 mashup 并不是应用的全部，但 BEA 一直以来都把重点放在为组织创建服务的开发者身上。Bob Rhubart 在一家公司讨论“作为 SOA 项目整体一部分的安全性”时提到，安全是任何 SOA 全局治理的基石：
要说明安全之于 SOA 治理的重要性，将它比作水之于鱼的生存也不为过。这是显而易见的。就像 SOA 治理中的其他环节一样，安全问题也是一个多方面的问题。但它的本质归根结底在于回答一个简单的问题：谁在使用你的东西？部署于 SOA 中的每一个服务都代表着一笔重大的投资，同时也代表着潜在的重大回报。当然了，SOA 治理的一个根本目的，就是保证每个服务的使用都能产生所预期的回报。实现这个回报的关键，一是控制好谁能访问这些服务，二是控制好那些有权使用的人到底是怎样使用服务的。Rhubart 援引了 David Garrison 和BEA 的安全服务框架作为如何实现这一目标的例子。Garrison 指出，BEA 在他们的产品中使用了一个安全服务框架模型，并讨论了如何用 AquaLogic 企业安全套件 (ALES) 来设计这样一种框架的基本理念。Garrison 为一个安全服务框架标定出了 5 个主要的服务 / 提供者，并阐述了它们各自的职责。它们是：
- 认证
- 角色映射
- 授权
- 证书映射
- 审计
查看英文原文：Security for Services and Mashups
译者简介：黄璜，毕业于重庆邮电大学计算机学院。现从事软件开发工作，供职于成都 ISSC, 主要负责 Java Web 开发，熟悉 struts,spring,ibatis，关注语义网，SOA，云计算等领域。个人主页：http://www.chinacomputing.org， 联系方式huangh@cn.ibm.com。参与 InfoQ 中文站内容建设，请邮件至china-editorial@infoq.com。
注册/登录 InfoQ 发表评论