面向服务构架下Web服务安全问题和策略探讨

　Web服务（Web Service）是基于XML和HTTPS的一种服务，其通信协议主要基于SOAP，服务的描述通过WSDL，通过UDDI来发现和获得服务的元数据。Web 服务提供了一个基于一系列开放标准的解决业务级和应用级互操作性的体系结构，通过组合一系列平台中立的技术来实现Internet和Intranet上业务和应用的快速交付与使用，为充分利用各种形式的网络资源提供了一种新的途径 。Web Services通过Web服务描述语言WSDL来描述在线业务；通过简单对象接入协议SOAP完成跨平台的交互通信；通过统一描述、发现和集成UDDI实现业务注册和广泛环境内的业务发现和集成[1]。
　　面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
　　虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（extensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了[2]。
　　目前Web 服务已经是实现 SOA 的一种重要的方式，以至于很多人将两者的概念混淆。现在SOA要求服务间广泛的互操作性，SOA虽然能解决异构平台下Web服务的互相调用，在开发Web服务的逻辑功能时，如果把安全特性也设计进来，使其能实现SOA安全之目标，无论对理论与技术实践，都提出了挑战。
　　1 异构平台安全特性
　　SOA要求服务间广泛的互操作性。在开发Web服务的逻辑功能时，如果把安全特性也设计进来，Web服务将变得异常复杂，服务的性能与可伸缩性会大大降低。就安全需求本身分析，仅仅把各种安全措施集合在一起，不能肯定安全组件的组织是否恰当，也不能肯定能使一个系统更加安全。因而SOA中Web服务的安全问题应与服务的功能脱离，通过适当的安全配置与安全机制实现Web服务的安全需求。这样，既能保证Web服务设计与调用的简洁性，又能实现SOAP信息传递与服务调用的安全性。
　　一个应用系统通常是基于某个平台实现的，如基于Microsoft .NET或Apache Axis。这些服务平台都有独立的安全解决方案，如Microsoft 的WSE（Web Service Enhancement） 、Axis 的Rampart等。对于同一个安全策略，如采用证书对消息签名，服务请求方对消息签名，服务的提供方对签名验证，在相同平台中是可以实现的。但如果请求方与服务提供方处于不同的平台中，安全的互操作性通常无法保证。
　　每个应用平台都有自己的安全机制与安全API，这类商业软件使用自己的策略配置为安全建模。但是，在使用SOA进行企业应用集成时，不同应用系统的服务可能在不同的应用平台上，采用不同的安全策略与平台技术实现安全需求。这时需要一个处理服务安全的代理机制从逻辑上包装平台安全的特定实现，使异构平台下的SOAP安全信息能够被异构平台一致地理解与处理[3] [4]。
　　异构平台下Web服务安全处理机制提供了相关安全策略配置与SOAP消息安全的实现方法。安全服务代理使用WS-Security等规范实现SOAP消息安全，分为以下三个方面：
　　1） 消息完整性：使用XML签名对SOAP消息进行数字签名，保证SOAP消息经过中间结点时不被篡改。
　　2） 消息保密性：使用XML加密对SOAP消息进行加密，使消息发送方可以确保SOAP消息内容仅对预定的接收方可见，保证SOAP消息即使被监听，监听者也无法提取出有效信息。
　　3） 消息真实性：引入安全令牌的概念，用其代表消息发送方的身份。通过与多种数字签名结合，消息接收者可以确认SOAP消息发送者的合法性。
　　2 异构平台的策略框架
　　2.1 NET平台WSE 3.0安全策略
　　在WSE的安全实现框架中，针对SOAP消息从客户端发送请求、服务端接收请求、服务端发送响应和客户端接收响应设计了四个过滤器，并分为两组。在SOAP请求后和SOAP响应前截取SOAP，然后对截取的SOAP消息的数据进行处理。每个过滤器负责一项特定任务，既可以是安全事务，也可以是跟踪等管理事务。该框架结构实现了安全逻辑与业务逻辑的分离，WSE安全框架结构如图1所示。
　　WSE 3.0提供的安全机制保证了Web 服务的安全。实现安全的方式有两种，一是通过WSE3.0策略工具根据应用系统的安全规格为服务端和客户端设置相应的安全策略；二是用代码实现具体的安全策略相同的功能。前者方便快捷，通过简单的设置即可完成Web服务的安全。后者用户可以定义更具体的代码来扩展自己的安全策略。不论采用那种方式都可以利用WSE 3.0提供的安全机制保证Web服务的安全交互。
　　由于策略由策略断言组成，并且每个断言都会在管道中插入过滤器对进入和离开终结点的SOAP消息执行预处理和后续处理。通过将断言放到策略中，可以在运行时控制构建和组织过滤器管道。在WSE 3.0中，管道是由安全策略框架驱动的。
　　2.2 Axis平台Rampart安全策略
　　Rampart的结构如图2所示，其中mod-rampart模块的作用是为Rampart和Axis2引擎提供接口。Rampart内部由Rampart引擎（Rampart Engine）、Rampart功能实体（Utile）和Rampart安全策略（Security Policy）组成[5]。
　　在Rampart中，Security Policy具有配置安全模块的作用。Rampart使用WS-Security Policy规范中定义的安全策
　　略断言进行配置，WS-Secu rity Policy中的每一个策略断言，都定义了一个断言构建器（Builders）和一个断言模型（Models）。
　　Rampart作为WS-Security的实现模块加载到Axis2引擎后，既可以对所有的有效服务进行安全处理，也可以选择对一个或者多个具体的服务或者某一服务中的特定方法进行安全处理。
　　3 异构平台Web服务安全模型
　　异构平台之间的安全框架、配置策略等都有较大的不同，因此实现异构平台间Web服务的安全交互必须增加一个第三方认证机构，根据客户端的请求完成相关验证，验证通过后才能发送调用Web服务的请求；根据本项目对于Web服务的安全需求.结合WS—Security和WS—Policy规范.构造了一个Web服务的安全模型系统。
　　3.1安全模型体系构架
　　该系统实现安全的基础主要是基于SOAP头的扩展.分别实现SOAP加密、SOAP签名、SOAP认证与授权、SOAP安全属性扩展（时间戳等）。对于访问控制。我们设计了Web服务访问控制器，该控制器的实现主要基于X—RBAC模型，动态的控制用户对Web服务的访问权限。遗留系统包括一个私有CA 中心，这方便了安全模型的实现，它主要负责密钥和证书的生成和管理。此外，安全日志也保证了模型系统具备审计的功能，安全策略管理器则是负责对安全策略文件的管理。安全策略库保存着Web服务所对应的特定安全
　　策略文件。安全模型体系架构如图3所示。
　　3.2安全模型组成及其功能
　　安全模型主要包括安全组件包（Security Utility）、访问控制器以及安全策略管理器三部分。安全组件包由若干个SOAP消息过滤器（Filter）组成。安全组件包主要功能如下：
　　1）消息加密：基于XML Encryption实现SOAP消息的加密以及解密功能.密钥管理基于XKMS技术。
　　2） 消息签名：基于XML Signature实现SOAP消息的签名以及签名验证功能。密钥管理也基于XKMS技术。
　　3） 认证信息处理：通过WS—Security所支持的Username/Password Token或X.509证书安全令牌实现对用户身份的认证。
　　4）附加安全属性：附加的安全属性主要是防止对Web服务的重传攻击，通过时间戳机制来实现。当然.附加的安全属性也可根据用户额外的安全需求进行扩展，实现更加安全可靠的S0AP消息。
　　3.3模型的通信过程
　　在介绍完整的通信过程之前，首先给出所涉及的符号及其描述，如表1所示。
　　通信过程说明：
　　·在安全通信过程开始前，服务请求者通过SOAP消息或者其他方式获得服务提供者所提供的Web方法对应的安全策略文件。
　　·服务请求者根据安全需求对请求消息中需要进行安全保护的部分进行签名/加密处理，然后使用服务请求者的私钥对整个消息进行签名，并使用服务提供者的公钥对整个消息进行加密，最后将结果连同证书发给服务提供者。
　　·服务提供者收到请求消息后，先提取消息中服务请求者的证书，验证其有效性.验证通过，利用证书所提供的公钥验证消息签名的有效性，同时解密整个消息。
　　·如果安全验证全部有效，则建立整个通信过程。实现对服务的调用，然后按照安全策略文件的要求对响应的消息进行安全处理后发送给服务请求者。
　　·服务请求者接收到经过安全处理的消息.如果通过有效的安全认证，则按照安全策略文件的要求对消息进行签名验证和解密，最终获得原始响应消息。上述通信过程都设有超时机制，若超时则重新执行整个通信过程。若在通信过程中发生致命错误，例如，认证未通过.解密、验证失败等，则终止通信，发出错误响应消息[6]。
　　4 研究的方向
　　4.1安全策略的改进
　　安全策略：是指在某个安全区域内（一个安全区域，通常是指属于某个组织的一系列处理和通信资源），用于所有与安全相关活动的一套规则。这些规则是由此安全区域中所设立的一个安全权力机构建立的，并由安全控制机构来描述、实施或实现的。
　　下一步的研究方向针对安全服务机制没有实现的安全策略，开发实现相应的安全服务。现在的安全策略都是对所有的消息进行加密，这样效率不高，资源浪费。下一步的研究准备针对部分机密消息加密，从而提高效率。
　　4.2 Kerberos票据
　　网络认证使用最为广泛的协议是Kerberos和X.504.K。Kerberos是基于对称密码机制的，X.509是基于非对称密码机制的，两者各有特色。Kerberos在分布式网络环境中得到了广泛的应用；X.509在PKI中发挥重要作用。下一步在学习研究Kerberos协议的基础之上，分析了麻省理工大学（MIT）和微软对Kerberos认证协议的实现，在此基础之上，针对Kerberos的某些局限提出并实现了一个切实可行的解决方案。
　　4.3通用安全模型
　　现阶段仅就两个具体的平台来探索了异构平台下Web服务安全交互的模型和应用。对于基于广泛平台的异构平台下的Web服务，还没有一种统一可靠的安全模式能保证SOAP消息在多平台间传输过程中的安全性，这种安全模式也是我们下一阶段研究的重点。
　　5 结束语
　　本文介绍了在 SOA构架下Web安全，具体介绍了在Microsoft .NET和Apache Axis平台下自带的不同安全策略，并且提出了在这两个异构平台一个安全模型下互相通信的模型。下一步将具体进一步研究异构平台的安全策略并验证。
　　参考文献：
　　.冉晓旻，译.北京：清华大学出版社，2003.
　　[2] http：//？wtp=tt.
　　[3] 唐柳英，卿斯汉.混合RBAC-DTE策略的多角色管理[J].计算机学报， 2006，29（8）： 1419-1425.
　　[4] 王小明，赵宗涛.基于角色的时态对象存取控制模型[J].电子学报， 2005，33（9）： 1634-1638.
　　.计算机应用与软件，2009， 26（9）： 31-33.