基于SRP协议的Web服务移动agent访问控制研究摘要：针对Web服务安全问题中的访问控制，提出将移动agent引入Web服务的安全访问控制模型，基于SRP协议对Web服务附加了一个独立的访问控制代理层，实现了基于移动agent的Web服务访问控制模型，并对控制流程进行了描述。关键词：Web服务;访问控制;SRP协议;移动代理中图分类号：TP309文献标志码：A文章编号：1001－3695(2008)06－1822－03服务作为目前网络应用比较热门的技术，如果实现大规模企业应用，将带来巨大的经济效益，但其中的安全问题成为Web服务普及的主要障碍之一。企业级的访问控制系统不会孤立存在，它们同后台的用户目录服务器和访问策略服务器连接。这些服务器可以提供用户信用标记以及基于访问策略作出访问控制决定。典型的访问控制系统需要处理验证和授权任务。基于不同的配置方案，系统可以接受许多种类的信用标记。对于Web服务访问控制系统，除其他需求外，特别地需要支持不同的基于Web服务安全的方案。系统需要从输入的Web服务信息头部的WS－Security信息部分提取并使用用户信用标记来验证请求者[1]。因此，企业Web服务的开发者不得不手工编写代码来提取信用标记并对输出信息进行适当的安全处理。这需要对XML进行手工解析,或者利用常见的XML签名加密、SAML或WS－Security等工具包。由于Web服务安全涉及相当广泛的技术，其实现必然依赖于许多外部的软件开发包。现在可用的软件开发包不少，不过彼此之间存在的兼容性很差，利用所有的工具包使其兼容本身就是一大挑战。不兼容的问题可表现为：支持的算法集合不同、不兼容的证书格式、使用的JDK版本的冲突、依赖的XML解析器的不兼容性等[2]。因此，寻求一种具有通用性的Web服务访问控制机制和模型具有十分重要的现实意义。??1Web服务安全代理??Web服务相对于过去的CORBA、COM组件技术，提供了耦合度更为松散的分布式模式。Web服务体系中存在服务的提供者(serviceprovider)和服务的调用者(serviceinvoker)，对于一个最简单的Web服务应用，只存在以上两个角色，此时安全性可以通过调用者和提供者的应用完成，没有增加安全代理的必要。但是，Web服务的优势决定了在现实世界中，它面向的是更多企业之间的复杂集成。从一个提供Web服务的企业角度来看，它可能存在多个合作伙伴(partner)，每个partner可能会访问多个服务，每个服务，可能同时被多个partner使用。如果多个企业之间形成战略联盟，还可能存在连锁式的Web服务调用。在这条调用链上的企业，作为服务提供者的同时，还需要作为调用者访问partner的服务。此时将Web服务的安全功能从系统中剥离出来形成独立的Web服务安全代理(Webservicessecurityproxy，WSSP)就十分必要了[3]。图1是改进后的基于安全代理的服务机制体系。?グ踩?服务代理可以检查进入的SOAP消息，然后只让那些经过授权的请求方穿过代理。这种体制运行过程如下:??a)发送方构造一条SOAP消息并将其发给Web服务。发送方在不在消息中包括签名都可以。??b)在发送方通过签署和加密消息提供了端到端的安全性后，发送方另添加了一条〈security〉报头块，并把安全代理列为SOAP参与者。请求方在该报头块包含了对加密的数据的签名。发送方还将在路由报头块中指定路由信息。??c)通过传输协议将消息发送到安全代理。安全代理会确定目标是它本身的〈security〉报头块的位置，并抽取安全性令牌和签名。??d)安全代理验证加密的数据的签名以及所包括的(或被引用的)安全性令牌的有效性。继而安全代理就是否授权这条消息穿过安全代理作出决定，很可能要利用外部数据。如果消息获得发送过安全代理的许可，则安全代理会删除指向它本身的〈security〉报头块，并修改路由报头块上的返回路径?┬畔?。??e)安全代理使用单独的传输把改过的消息路由到最终目的地。??f)服务将验证到它的〈security〉报头块，并认证消息。??g)服务处理请求并返回一个答复。?ピ诘玫桨踩?代理的授权以后，消息被修改(路由报头发生了变化，删除了第一个〈security〉报头块)并发送到最终目的地。安全代理可以选择在到最终目的地的〈security〉报头块中预设新的安全性令牌来添加新的安全性信息。?ケ疚难芯康陌踩?...