使用WS-Security来执行消息级别的安全

    在美国两个州之间的边界上，经常会发生一个管理者认为另一个警长会负起管理责任的情况。为了拥有一个总的管理者，会安排一个地区联合管理者。它的责任是确保在国家内所有的州之间实行一致的安全管理。

    Web 2.0企业应用程序一般使用应用程序编程接口（API）或Web服务接口来与合作伙伴或企业内的其他应用程序服务来进行交互。这些可能传送机密数据的Web服务易于遭受到诸如参数操纵之类的攻击，在这种攻击中，在SOAP消息中的参数被利用来注入SQL、XPath（XML路径语言）和shell 脚本等。因此，确保在消费应用程序和服务之间流动的消息不被做手脚是非常重要的。使用安全套接字SSL的传输级别的安全和使用Web服务安全协议WS-Security的消息级别的安全都是必须需要的。XML加密也必须被用来维护数据一致性，而服务的真实性和完整性也应该使用XML签名来保证。企业应用程序应该确保这种类型的令牌文件被服务所支持，并将其封装作为SOAP头的一部分，这些令牌文件包括具有可选密码摘要的用户名、安全应用标记语言SAML令牌和其他内容。基于WS-Trust的解决方案可以被应用在合作伙伴之间必须达成信任的地方。开发者可以使用特定的框架来作为策略执行点的代理，它可以在不影响服务逻辑的情况下执行入站和出站的Web服务调用。诸如此类的框架可以提供一个分散的平台来配置跨服务的策略，并前瞻性的管理被应用程序所使用的服务。

管理跨应用程序和服务的角色和身份

    对于所有不同的法律执行机构来说，很明显都需要一个标准的方式来识别不同的个体。这样，一个徽章或一个星和一个相对的权限级别变得非常有必要，来确保每一个相关的人可以互相了解对方的角色。 

   根据企业中用户角色的不同，基于角色进行访问控制的RBAC模型可以被用来保护具有特殊权限的资源。因为它减少了安全规定的复杂度和成本，RBAC已经是当今企业中应用最普遍的许可模型。使用RBAC保护的资源大多数情况下由企业应用程序的管理员来创建和管理。但是，企业应用还必须处理这个访问控制模型，并执行不同的多人参与的服务。这些服务的角色和策略定义可能与不同的计划保持一致，并与那些企业应用程序有所区别。举个例子来说，如果一个企业应用程序使用一个提供内容管理功能的服务，一个具有在应用程序“查看”角色的用户将在内容管理后端具有“读者”角色。执行者因此将需要创建一个新的许可模型，来映射应用程序角色到服务角色上，那么任何在应用程序中被授予“查看者”角色的用户将相应的授予内容管理系统中的“读者”角色。因此，需要在应用程序和多人参与的服务之间建立一个合约（SPI/API），以推动这种新的许可模型，这样用户具有所有需要的访问控制权限来以一种一致的方式来使用应用程序，就如同在新的国家被建立后需要选举新的警长。

    Web 2.0应用程序所使用的服务的分布式的特点使其对现有的身份管理解决方案具有更进一步的要求。一个服务可以拥有自己的身份管理仓库，并使用一个与前端引用程序完全不同的认证模型。在应用程序身份库和服务的后端身份库中，用户可以具有不同的身份和证书。身份证书需要使用安全证书库来进行映射，或者身份应当使用WS-Security令牌文件进行再证实，以免服务暴露Web服务的接口。

使用分散授权

    对于任何一个行政辖区来说，通常有太多的人需要管理。因此，管理者必须提名一个代表来作为执行的角色。

    由于大多数基于Web 2.0的应用程序是需要合作的，并需要围绕用户产生的内容循环，访问控制经常基于用户档案的属性而不只是用户角色，就变得非常重要。授权检查还应该考虑发出访问一个资源请求的前后关系。这样的认证计划可以帮助管理员在一个更细化的级别来管理特权操作，诸如从wiki中删除一个项目页面。

总结

    企业员工已经开始询问，为什么通过互联网可以更容易的完成任何和问题的协作，但是在工作车间却不能。对此，企业开始将协作性的Web 2.0功能引入到企业应用程序中。随着越来越多的公司增加这类服务和技术到新的和现有的应用程序中，就需要一个新的“管理者”来确保信息不会被现代版的“车费路霸”和黑客所损坏。使用本篇文章中的一些非常好的实践经验，将有助于确保这些增强的Web 2.0功能的成功使用和部署。