Web服务实体及其安全供求策略匹配的实现方法

文档序号:7895215阅读:182来源:国知局
专利名称:Web服务实体及其安全供求策略匹配的实现方法
技术领域
本发明涉及网络技术,尤其涉及网络安全匹配的技术。
背景技术
Web服务作为一种新的分布式计算模型,为Web上数据和应用的集成提供了有效机制,也是面向服务架构(Service Oriented Architecture, SOA)和云计算等新兴计算模式的主要实现与呈现方式。Web服务具有平台无关性、开放性、动态性、松散耦合和分布式等特征,这在给基于异构平台的应用集成带来便利的同时,其自身也面临许多独特的安全问
题。 Web服务的一个首要问题是如何准确地表示和匹配各Web服务参与方的安全供求策略。这里所说的安全供求是指一个Web服务实体(包括服务提供者和请求者)的安全需求和安全能力,是Web服务的一种非功能属性,安全供求策略就是对这种非功能属性的策略表示。确定一个服务是否适合于一个特定的请求,除了功能方面要满足需求之外,服务提供者和请求者的安全需求与安全能力也应该相互匹配。只有当对应的安全需求和安全能力相匹配时,Web服务实体之间才实现下一步动作,如建立链接、传输数据等。然而,Web服务环境具有开放、动态和分布式的特征,Web服务各参与方可能位于不同的安全域,而不同的安全域中通常具有不同的安全等级和安全需求。在这种情况下,与Web服务安全相关的各种机制、协议和规范也具有多样性和冲突性。因此,要清楚无误地、以能被共同理解的方式来表示Web服务各参与方的安全供求策略、并对它们进行正确匹配是比较困难的。现有的策略框架,如Web服务策略框架(Web Service PolicyFramework, WS-Policy)能够用来描述Web服务的安全需求和安全能力。但是,WS-Policy对这些非功能属性的描述是句法级的(syntactic),表达能力较弱,对具有异构和分布式特征的Web服务环境来说其适应性有限。此外,WS-Policy在实际应用中对策略兼容性计算的效率较低,并且容易导致错误的匹配结果。

发明内容
为了改善网络安全匹配技术的现状,本发明提供了一种Web服务实体及其安全供求策略匹配的实现方法。一种Web服务实体,用于在网络中提供一预先设定的功能,包括安全本体模块、安全需求策略模块和安全匹配模块。其中,该安全需求策略模块定义若干安全需求和安全能力,且所述安全需求和安全能力取值于所述安全本体模块;该安全匹配模块基于所述安全需求与另一 Web服务实体的安全能力、或者基于所述安全能力与另一 Web服务实体的安全需求,判断本Web服务实体与所述另一 Web服务实体的安全供求匹配与否。本发明另提出一种Web服务安全策略的匹配方法,该方法用于对一第一 Web服务实体和一第二 Web服务实体进行安全策略匹配,包括以下步骤
取得所述第一 Web服务实体的安全需求属性;取得所述第二 Web服务实体的安全能力属性;判定所述安全需求属性和安全能力属性是否匹配;其中,所述安全需求属性和安全能力属性预先定义在一个安全本体模块中。综上所述,本发明提出的匹配方法不需要对任何已有规范做出改动,具有较好的适应性和可扩展性。对于匹配算法,主要是基于对概念的包含推理来进行,通过对概念蕴含关系的推理来确定安全能力与安全需求是否匹配以及匹配的程度。也就是说,将安全供求策略的匹配问题转化成了基于语义概念的包含推理问题,提高了策略匹配的效率和准确性。


图I为本发明实施例中的安全本体的示意图。
具体实施例方式为了更了解本发明的技术内容,特举具体实施例并配合所附图式说明如下。本实施例中的网络系统至少包括第一 Web服务实体和第二 Web服务实体。本发明中,Web服务实体至少能够实现某种功能,例如对另一 Web服务实体的请求作出响应,或者向另一 Web发出请求。同时,Web服务实体也具有安全等级,定义对应的安全能力和安全需求。在实际应用中,该Web服务实体可以作为一个装置,如计算机实现,也可以作为多台计算机互联的形式出现。Web服务实体包括功能模块和安全本体模块,其中,功能模块用以实现特定的功能,如资源存储、信息访问等。安全本体模块则对各种与Web服务安全相关的标准、机制和协议以及它们相互间的关联特性进行基于语义的描述。这样,当基于安全本体模块来定义安全策略时,所定义的安全策略内容就包含了必要的语义信息,从而能够提高策略匹配的准确性。安全本体模块的基本层次结构如图I所示。图中的类来自于语义本体,即、从语义上讲,图中的各个类是对现实世界中个体的抽象和集合。本实施例中,安全本体模块(SecurityOntology)的子类包括安全目标类(SecurityObject),协议类(Protocol),算法类(Algorithm),加密类(Encryption),签名类(Signature)和证书类(Credential)。SecurityObject子类用来表示各种安全概念或目标,它的实例可能包括数据完整性(DataIntegrity),机密性(Confidentiality),验证(Authentication),授权(Authorization),访问控制(AccessControl)和密钥分发(KeyDistribution)等。Protocol子类表示各种与Web服务安全相关的具体规范,比如用来认证和授权的安全断言标记语言类(Security Assertion Markup Language, SAML);用来执行访问控制的可扩展访问控制标记语言类(extensible Access Control Markup Language, XACML);可用于认证和密钥分发的可扩展标记语言密钥管理规范类(extensible Markup LanguageKey Management Specification, XKMS)等。Algorithm子类用来表示各种可能被其他协议或规范采用的安全算法。其子类对称算法类(Symmetric)对应对称加密算法,包含的实例可以是数据加密标准(DataEncryption Standard, DES) , 3DES (3 重 DES),国际数据加密算法(International DataEncryptionAlgorithm, IDEA)和高级加密标准(Advanced Encryption Standard, AES)等;子类非对称算法类(Asymmetric)对应非对称加密算法,包含的实例为公钥加密算法和数字签名算法(Digital Signaure Algorithm, DSA);子类哈希算法类(Hash)对应哈希算法,其实例可以是消息摘要算法第5版(Message Digest Algorithm 5, MD5),安全哈希算法第一版(Secure Hash Algorithm I, SHAl)和安全哈希算法第二版(Secure Hash Algorithm 2,SHA2)。Encryption和Signature子类主要关注Web服务最基本的消息安全如机密性和完整性。它们包含的子类表示可用于实现各自目标的主要方法,比如开放私有最佳加密类(Open Pretty Good Privacy Encryption, OpenPGP-Enc)用于加密,可扩展标记语言签名类(Extensible Markup Language signaure, Xml-Dsig)用于签名。Credential子类表示Web服务实体要求或者能够提供的各种安全凭证,主要用于身份验证和访问控制。比如其子类可能包括用户名令牌类(UserNameToken)、X. 509证书类 (X509Cert if icate)、公钥类(PublicKey)等。以上对于安全本体模块的子类的介绍仅是列举性的,在应用中可以按照实际需要来选择和定义安全本体模块。为了更好地描述安全本体模块中各子类之间的相互关系,便于对语义安全供求策略进行概念层次的描述和推理,本实施例定义了一种基于属性约束的特殊命名类。基于属性约束的命名类是指通过限定某个对象属性的取值,并在命名空间中指定唯一名称而形成的特殊类。以下给出了采用网络本体语言(Web Ontology Language, OWL)对这种约束类进
行描述的实例
<owi: Restriction rdf:iD="Authentication_RC">
<ow!: on Property rdf:resource=M# refSecObject"/>
<ovvl:hasValue rdf:resource="#Authentication 7>
</owl: Restriction〉
<owl: Restriction rdf: I D=" AES_RC">
<o\vl :onI)roperty rdf:resource="#refAlgorithm"/>
<owl:hasValue rdf:resource="#AES"/>
</owi: Restriction〉
<owi: Restriction rdf:ID="X509Certificate_RC">
<o w I: on Property rdf: resource="#refC redential 7>
<owl:hasValue rdf:resource="#X509Certificate "/>
</owi: Restriction〉根据定义的约束类,可对安全本体中的其他子类作进一步的扩展定义,从而更好地描述各子类之间的语义关系。比如,以下代码给出了基于约束类的扩展描述实例<owl:C!ass rc1f:iD="XML-Enc">
<rd fs isubClassof rd f:resource="#Encrypti on"/>
<rdfs:subClassof rdf:resource="#AES_RC 7 >
</owl:Class>
<owl:Class rdf:ID="SAML">
<rdfs:subClassof rdf:resource="#PiOiocol"/>· <rdfsisubClassof rdf:resource="#Authentication_RC "/> </owl:Class>
<owl:Class rdf:iD="SAML_X509">
<rdfs:subClassof rdf:resource="#SA!VIL"/>
<rdfsisubClassof rdf:resource="#X509Certif[cate_RC "/> </owl:Class>从以上定义中可以推断出Protocol子类中的可扩展标记语言加密(ExtensibleMarkup Language encryption, XML-Enc)可用于消息加密,支持 Algorithm 子类中的 AES加密算法!Protocol子类中的SAML是一种身份认证规范,支持基于Credential子类中的X. 509证书(X. 509Certificate)的认证方式等语义信息。以下介绍在安全本体模块的基础上,描述Web服务实体的安全需求和安全能力的·方法。在描述Web服务的安全需求和安全能力时,需要满足两条原则。第一,每个Web服务实体可以有多个安全需求和多个安全能力,但应对安全需求和安全能力加以明确区分,分别进行定义;第二,由安全需求和安全能力构成的安全供求策略应该形成一个独立的策略文件,分别与Web服务描述文件或服务请求进行绑定。其中,Web服务描述文件描述了 Web服务提供者所提供的功能,而Web服务请求者则根据自身的需求提出Web服务请求。这里,对安全需求和安全能力分别进行定义是为了更加符合实际情形,并为匹配过程提供便利;而形成一个独立的策略文件可以使服务功能匹配与安全策略匹配的过程分离开来,降低复杂性。另外,Web服务描述文件要是用来刻画服务功能的,功能内容相对于非功能属性来说也更加稳定,因此使用独立的策略文件更具灵活性,安全属性的变化不会影响到相对稳定的服务功能描述文件,同时也能避免要求对服务描述文件做出改动。根据上述原则,本实施例基于XML语法格式,定义Web服务语义安全供求策略的基
本框架如下所示〈Policy name=" Po I icy N ame" xmlns:so="#SecurityOntology"> <secCapabilities>
<secCapabilityID-'CapabiltiylD"
resource="so:SubClassOf^ecurityOntology"/>+
</secCapabilit.ies>
<secRequirements>
<sec Requi I'ementI D=" Requi rementID"
resource="so:SiibClassOfSecurityOntology"/>+
</secRequirements>
</Policy>其中,属性“身份标识(IDentity,ID)”用来声明某个安全需求或安全能力的唯一标识,属性“resource”的取值为安全本体模块中的某个子类,“so”表示对安全本体模块的引用;符号“?”表示O或1,表明对应元素是可选的,即可以没有关于安全能力或安全需求的定义;符号“ + ”代表I个或多于I个,表示可以定义多个安全能力和安全需求。以下介绍Web服务实体之间对安全需求和安全能力的匹配判定过程。由上述可知,本实施例中的Web服务实体的安全供求策略是根据安全本体模块中的各种子类来描述的,因此其匹配算法是基于对概念的包含推理来进行。也就是说,通过对概念蕴含关系的推理来确定安全能力与安全需求是否匹配以及匹配的程度。在本实施例的网络中,假设第一 Web服务实体中描述安全能力的是子类A,第二 Web服务实体中描述安全需求的是子类B,那么匹配算法可以表示如下
权利要求
1.一种Web服务实体,用于在网络中提供一预先设定的功能,其特征是,包括 安全本体模块; 安全需求策略模块,定义若干安全需求和安全能力,且所述安全需求和安全能力取值于所述安全本体模块; 安全匹配模块,基于所述安全需求与另一 Web服务实体的安全能力、或者基于所述安全能力与另一 Web服务实体的安全需求,判断本Web服务实体与所述另一 Web服务实体的安全供求匹配与否。
2.根据权利要求I所述的Web服务实体,其特征是,该安全本体模块的子类包括Web服务的标准、机制和/或协议。
3.根据权利要求2所述的Web服务实体,其特征是,该安全本体模块对其子类进行语义 化表述。
4.根据权利要求2所述的Web服务实体,其特征是,该安全本体模块具有属性约束模块,该属性约束模块限定了所述安全属性信息的名称和取值。
5.根据权利要求I所述的Web服务实体,其特征是,该安全需求策略模块包括安全需求模块和安全能力模块,分别对安全需求属性和安全能力属性进行单独定义。
6.根据权利要求5所述的Web服务实体,其特征是,所述安全策略模块绑定到一功能模块,该功能模块被用来定义或描述所述预先设定的功能。
7.根据权利要求3所述的Web服务实体,其特征是,所述安全匹配模块基于语义推理实现安全匹配。
8.—种Web服务安全策略的匹配方法,用于对一第一 Web服务实体和一第二 Web服务实体进行安全策略匹配,包括以下步骤 取得所述第一 Web服务实体的安全需求属性; 取得所述第二 Web服务实体的安全能力属性; 判断所述安全需求属性和安全能力属性是否匹配; 其中,所述安全需求属性和安全能力属性预先定义在一个安全本体模块中。
9.根据权利要求8所述的Web服务安全策略的匹配方法,其特征是,所述安全本体模块对Web服务的标准、机制和/或协议进行语义化表述。
10.根据权利要求9所述的Wb服务安全策略的匹配方法,其特征是,基于语义推理判断所述安全需求属性和安全能力属性是否匹配。
全文摘要
本发明提供一种Web服务实体,该Web服务实体用于在网络中提供一预先设定的功能,包括安全本体模块、安全需求策略模块和安全匹配模块。该安全本体模块对各种Web服务安全相关的标准、机制和协议进行了语义化表述。安全需求策略模块中定义了若干个安全需求属性和安全能力属性,且所述安全需求属性和安全能力属性都从所述安全本体模块中取值。安全匹配模块基于语义推理,判断Web服务实体之间安全供求策略匹配与否。本发明从语义层次上对Web服务安全的相关属性进行了描述,从而可以利用包含推理规则实现安全供求策略的匹配问题,具有高效、准确的优势。
文档编号H04L29/08GK102857489SQ201210142898
公开日2013年1月2日 申请日期2012年5月10日 优先权日2012年5月10日
发明者吴礼发, 赖海光, 郑成辉, 贺正求, 李华波, 黄康宇 申请人:中国人民解放军理工大学
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1