网络计算环境中基于策略的安全访问方法

摘要

网格计算环境中基于策略的安全访问方法是一种分布式计算的安全解决方案，主要用于解决网格计算的安全问题。这种结构主要表现在使用了xml文件格式来作为策略的载体，而不需要使用数据库来实现。客户端生成请求策略文件，服务提供节点生成策略文件，请求策略文件和策略文件都提交到网格服务端，服务端使用匹配程序对这两种文件进行匹配，匹配结果就存放在相应的响应策略文件中，该响应策略文件就包含了对客户端的请求是允许访问和拒绝访问的元素。图5是我们提供的网格服务提供节点所生成的四种策略，这四种策略都是针对网格服务提供节点对自身资源的保护所提出的，由这四种策略就组成了服务提供节点的策略文件。

说明书

技术领域

本发明是一种分布式计算的安全解决方案。主要用于解决网格计算的安全问题，属于分布式计算软件安全技术领域。

背景技术

网格计算(Grid Computing)是指通过高速网络把分散在各处的硬件、软件、信息资源连结成一个巨大的整体，从而使得人们能够利用地理上分散于各处的资源，完成各种大规模的、复杂的计算和数据处理的任务。与以前的协同工作(Cooperative work)、分布式计算(Distributed Computing)等概念相比较，网格计算的集成程度更高、使用更加方便、资源的利用更加充分和有效。它标志着现代信息技术应用有一个新的、更高水平。

由于网格计算的诸多优点，因而被人们认为是互联网之后最重要的技术，对网格计算的研究正成为学术界和工业界的热点之一。但是安全性是制约网格计算技术广泛使用的重要因素之一，因此研究网格计算的安全问题具有重要意义。

网格计算环境具有许多特殊性，包括网格中用户与资源的动态性，以及申请释放资源等操作的动态性，因此，在网格环境中，对系统的高可扩展性，灵活性等方面有更高的要求，这给对网格客户端进行授权方面提出了新的挑战。传统的使用访问控制列表(ACL)方式的访问控制模型通常都需要使用数据库来实现，而在网格计算环境中，信息的表达方式是xml的文件格式，因而使用访问控制列表还需要进行xml文件和数据库的互操作过程，这样就会影响到访问控制的性能；而基于角色的访问控制模型又比较复杂，目前还处于研究探索阶段。相对而言，若能够使用信息表达方式为xml格式的访问控制模型，则能够很好的适应网格计算环境的需要，因为xml是可扩展元标记语言，通过根据网格计算的需要来自行定义并增加相应的xml标记，这样在制定策略时就有很大的自主性和可扩展性。

发明内容

技术问题：本发明的目的是提供网格计算环境中基于策略的安全访问方法来构筑网格环境中的对用户进行授权的体系，通过使用本发明提出的方法，可以达到是否允许网格用户使用网格资源的目的，并且能够对用户使用资源的权限进行控制。

技术方案：与传统的使用访问控制列表(ACL)和强制访问控制(MAC)来进行授权的方法不同，本方法是一种策略性方法，根据网格计算提供者的不同资源的特性来制定不同的访问控制策略集合，其目标是解决网格计算环境中如何对用户访问资源时进行授权的问题。

下面给出该模型中的几个概念：

自治域(Autonomy Domain)：加入网格环境的内部具有一致的安全体系的个体、组织、部门和团体等。

虚拟组织(Virtual Organization)：所谓虚拟组织就是指在网格环境中，为了完成某一特定任务而由不同自治域的节点组成的一个跨地域，异构型并共享资源协同完成任务的一些个人、组织或者资源的动态组合。

网格服务提供域(Grid Service Provider Domain)：由提供某一特定服务或者通用服务而组成的一个网格域，该域可以为网格自治域，也可以是虚拟组织。

网格服务提供节点(Grid Service Provider Node)：在网格服务提供域中的能够对外提供资源服务的最小单位成员。

策略(Policy)：由一组规则、规则组合算法的标识符、一组义务和一个目标组成的一个xml文件。

请求访问策略(Request Access Policy)：网格用户生成的请求访问网格资源的策略，只包括主体、客体和操作三部分。该请求访问策略和网格服务中的策略进行匹配。

目标(Target)：包含三类属性(主体、资源、动作)及其属性值来实现的确定策略是否与请求有关。策略和请求的相关性决定了是否要为请求评估该策略。将这些属性的值与请求中具有相同属性的值进行比较，如果匹配，则认为该策略是相关的，并对其进行评估。

主体(Subject)：是指能够访问网格服务提供域的授权实体，可以包含有关身份、角色或其他属性的信息。

客体(Object)：是指网格服务中提供资源的节点，可以是网格服务提供节点，同样可以包含其身份或其他属性信息。

操作(Action)：是指对资源的使用方式，对于网格资源而言，可以是读、写、执行任务、修改、删除等。

规则(Rule)：是指用来对资源的访问进行限定的条目，每条规则由条件、结果和目标组成。

条件(Condition)：是关于属性的陈述，评估结果为True、False或Indeterminate。

结果(Result)：是符合规则的预期后果，值可以为Permit或Deny。

一、体系结构

图1给出了一个运用这种方法的访问控制的组成结构图，与传统的访问控制结构不同，这种结构主要表现在使用了xml文件格式来作为策略的载体，而不需要使用数据库来实现。客户端生成请求策略文件，请求策略文件的格式如图2所示，服务提供节点生成策略文件，策略文件的格式如图3所示，请求策略文件和策略文件都提交到网格服务端，服务端使用匹配程序对这两种文件进行匹配，匹配结果就存放在相应的响应策略文件中，响应策略文件如图4所示，该响应策略文件就包含了对客户端的请求是允许访问和拒绝访问的元素。图5是我们提供的网格服务提供节点所生成的四种策略，这四种策略都是针对网格服务提供节点对自身资源的保护所提出的，由这四种策略就组成了服务提供节点的策略文件。

下面我们给出四种策略的说明：

操作选择策略：对于每一个网格服务提供节点而言，根据提供的对外服务资源的特点，在某一时间期内，规定该外对服务资源的使用方式。比如，当提供的资源还处于开发期或者修改期时，可以以只读的方式对外提供服务，因而在制定策略时，<操作>子元素的值为“read”；而当资源能够正常对外提供服务时，可以规定<操作>子元素的值为“read|write|run-task”等。其中“|”表示“或”的意思，即可以是其中某一种或几种操作方式。“run-task”表示用户可以使用该资源运行任务，而“write”表示用户可以对资源进行修改更新操作。

服务时间策略：对于每一个网格服务提供节点而言，根据节点自身能够对外服务的时间来规定服务时间范围，这种规定是在元素“规则”中的子元素“条件”中完成。比如，服务提供者在“条件”元素中规定服务时间范围为：09:00:00-17:00:00，而在此时间段外的服务予以拒绝。

信任属性策略：信任属性策略即是对访问网格服务资源的客户的信任范围，是在策略中以“主体”的形式来表示的。比如，网格服务提供节点可能只是信任某个IP地址段内(如“10.10.9.*”)的用户，或者用电子邮件形式表示的(如*@grid.com)某个区域内的用户。

系统性能策略：系统性能策略是网格服务提供节点规定的能够对外提供服务的系统性能，是在策略中以“条件”的形式来表示的。比如，一个节点规定自己的cpu运行速度为1.5GHz，而客户端所需要的服务提供的cpu性能为2.0GHz，那么该匹配结果就为拒绝提供服务。

二、方法流程

1、生成策略文件

对于网格服务而言，每一网格服务提供节点都应该制定适合自身资源特点的策略文件，以保护资源的使用能够在自己的允许范围内，根据上面所列的四种策略和策略结构图我们就可以构造出相应的策略文件。

1)生成操作选择策略：根据图3的策略结构，对于操作选择策略，规定<动作>元素的属性为“regexp-string-match”，该属性表示相应的“动作值”是可选的字符串形式，而“动作值”则根据网格服务提供节点对资源保护的特点而自行决定，如前面所示可以为“read|write|run-task”。因而得到的<动作>元素内容为：

<动作 动作属性＝“regexp-string-match”>read|write|run-task</动作>

2)生成服务时间策略：根据图3的策略结构，服务时间策略需要制定元素<条件>，规定<条件>的属性为“time-in-range”，该属性表示相应的“条件值”为时间范围形式。“条件值”为服务提供节点自行定义的时间段，格式为“hour：minute：second”。对于时间范围的制定则需要给出两个“条件值”，一个为起始时间，另一个为终止时间。若用户要求的使用时间不在该时间段内，则拒绝用户使用该资源的请求。得到的<条件>元素内容为：

<条件 条件属性＝“time-in-range”>

   <起始时间 属性＝“time”>09:00:00</起始时间>

   <终止时间 属性＝“time”>17:00:00</终止时间>

</条件>

3)生成信任属性策略：根据图3的策略结构，信任属性策略根据主体的属性类型可以生成几类信任属性策略。规定<主体>的属性为“rfc822Name-match”时，“主体值”应该为“grid.com.cn”域名形式，表示只信任拥有*@grid.com.cn该邮箱的用户；而当规定<主体>的属性为“regexp-string-match”时，“主体值”可以为“10.10.*.*”IP地址形式；而当规定<主体>的属性为“x500Name-match”时，“主体值”可以为“O＝NJUPT，C＝CN”x500Name形式。这三种形式的<主体>元素内容分别为：

<主体 主体属性＝“rfc822Name-match”>grid.com.cn</主体>

<主体 主体属性＝“regexp-string-match”>10.10.*.*</主体>

<主体 主体属性＝“x500Name-match”>O＝NJUPT C＝CN</主体>

4)生成系统性能策略：根据图3的策略结构，系统性能策略要规定<规则>元素中的<条件>子元素，属性值规定为“double-less-than-or-equal”，表示条件值是double型，并且请求策略所要求的应该小于该条件值，条件值定义为cpu的运行速度。因而还需要生成一个<条件>元素，其内容为：

<条件 条件属性＝“double-greater-than-or-equal”>1.5</条件>

另外需要确定的是<资源>元素，资源就用拥有该资源的服务提供节点的IP地址来表示，其属性为“anyURI-equal”，因而资源元素的内容为：

<资源 资源属性＝“anyURI-equal”>10.10.9.71</资源>

最后是规则属性的确定，当上面的策略都能够满足时，则规则属性为“permit”，表示允许使用该资源。而若有一项没有满足则规则属性为“deny”，表示拒绝使用该资源。

2、生成请求策略文件

对于网格客户端而言，请求策略文件比策略文件要简单的多，只是包含了<目标>的三个子元素，而没有包含<规则>元素，对应于上面四种策略，相应的也有四种请求策略。

1)生成操作选择请求策略：根据图2的策略请求结构，在生成操作选择请求策略时，对于<动作>元素的属性选为“string”，而“动作值”则由客户端根据自己想进行的操作来确定。比如客户端想借用网格服务端的资源来运行任务，则“动作值”为“run-task”。

<动作 动作属性＝“string”>run-task</动作>

2)生成服务时间和信任属性策略：根据图2的策略请求结构，由于请求策略中没有<规则>元素，因而我们将服务时间中的关于<条件>元素的内容放到<主体>中来实现，因而<主体>元素需要确定三个子元素：一个是根据主体自身的属性确定的主体值，这是用来表达信任属性策略，同样，当主体属性不同时，得到的<主体>元素的内容也不一样。当信任属性策略定义的<主体>属性为“rfc822Name-match”，则“主体值”应该为“*@grid.com.cn”域名形式，其余两种类似；另外两个主体元素则是客户端所要求提供服务的“初始时间”子元素和“终止时间”子元素，其属性值为“time”，用来表示服务时间策略。

<主体 主体属性＝“rfc822Name-match”>chenjg@grid.com.cn</主体>

<主体 主体属性＝“regexp-string-match”>10.10.20.2</主体>

<主体 主体属性＝“x500Name-match”>CN＝Grid-Client O＝NJUPT C＝CN

</主体>

<主体>

   <起始时间 属性＝“time”>09:00:00</起始时间>

   <终止时间 属性＝“time”>17:00:00</终止时间>

</主体>

3)生成系统性能请求策略：根据图2的策略请求结构，在生成系统性能请求策略时，<资源>元素包含两个子元素：一个是根据资源自身的属性来确定的资源值，另一个则是客户端所要求提供服务的“cpu运行速度”，其属性为“double”，而元素值则是客户端所需要的服务提供节点的cpu运行速度。

<资源 资源属性＝“anyURI-equal”>10.10.9.71</资源>

<资源>

   <条件 条件属性＝“double”>2.0</条件>

</资源>

确定了<目标>元素中的<主体><资源><动作>这三个子元素的内容后，请求策略文件也就生成。

3、进行策略匹配

每个网格服务提供节点生成的策略文件都传输给网格服务端，网格服务端将这些策略文件存储起来。在客户端生成请求策略文件并传输给网格服务端后，如图1所示，网格服务端就运行一个匹配程序(用java语言来实现)将请求策略文件和存放在服务端的策略文件进行匹配，匹配的结果格式如图4所示。匹配的原则是对请求策略文件中的每个元素，首先检查其属性是否和策略文件中定义的属性相同，若相同则进行元素值的匹配，例如对于“操作选择请求策略”中规定的“动作值”为“run-task”，而相应的“操作选择策略”规定的“动作值”为“read|write|run-task”时，由于“操作选择策略”的“动作值”有“run-task”，则匹配成功，生成的响应策略文件中的元素<决策>为“permit”。说明客户端能够满足该服务提供节点的策略要求，因而能够使用该服务提供节点的资源执行“run-task”操作。

该方法所包含的具体步骤为：

步骤1).服务提供节点根据信任服务策略，确定<目标>元素中的<主体>元素的属性和值；

步骤2).服务提供节点根据操作选择策略，确定<目标>元素中的<动作>子元素的属性和值；

步骤3).服务提供节点根据服务时间策略，确定<规则>元素中的<条件>子元素关于“时间”的属性和值；

步骤4).服务提供节点根据系统性能策略，确定<规则>元素中的<条件>子元素关于“性能”的属性和值；

步骤5).服务提供节点确定<目标>元素中的<资源>子元素的属性和值；

步骤6).确定四种策略后，生成相应的策略文件；

步骤7).服务提供节点将策略文件提交给服务端；

步骤8).需要访问网格服务的客户端填写服务端提供的四种请求策略信息，并生成请求策略文件；

步骤9).客户端将生成的请求策略文件提交给服务端；

步骤10).服务端接收到策略文件后，检查策略文件所需要确定的元素，并相应的对外发布请求策略信息，分别为操作选择请求策略、服务时间请求策略、信任属性请求策略、系统性能请求策略，每种请求策略信息都提供了相应的元素名和所需要的属性，以供客户端填写；

步骤11).服务端得到请求策略文件后，将请求策略文件与每一个服务提供节点提交的策略文件进行匹配；

步骤12).服务端检查请求策略文件和策略文件中<目标>元素中的子元素<主体>的值是否相匹配，主体匹配成功，继续后面元素的匹配过程；若主体匹配失败，这时便生成响应策略文件，并且<决策>元素的值为“deny”，表示该服务提供节点拒绝为该客户提供服务；

步骤13).服务端检查请求策略文件和策略文件中<目标>元素中的子元素<操作>值是否相匹配，同样若匹配成功则继续后面的匹配过程，不成功就生成响应策略文件，并且<决策>元素的值为“deny”；

步骤14).服务端比较请求策略文件中<目标>元素中的子元素<主体>关于“服务时间”的元素值和策略文件中<规则>元素中的子元素<条件>关于“服务时间”的元素值是否匹配，即客户端所要求提供的服务时间是否在服务提供节点所能提供的服务时间范围内，若在则匹配成功，进行后面的匹配，若不在，则匹配失败，便生成响应策略文件，并且<决策>元素的值为“deny”；

步骤15).服务端比较请求策略文件中<目标>元素中的子元素<主体>关于“系统性能”的元素值和策略文件中<规则>元素中的子元素<条件>关于“系统性能”的元素值是否匹配，若匹配则生成响应策略文件，并且<决策>元素的值为“permit”，若匹配失败，便生成响应策略文件，并且<决策>元素的值为“deny”；

步骤16).服务端对请求策略文件和每一个策略文件都匹配完成后，得到一组相应的响应策略文件；

步骤17).服务端从响应策略文件中提取出<决策>元素的值为“permit”的响应策略文件，并从中得到相应的服务提供节点；

步骤18).客户端将任务提交给服务端；

步骤19).服务端将任务分别在通过授权的服务提供节点上运行，至此授权过程结束。

有益效果：本发明方法提出了一种针对于网格服务的高效简便的访问控制新方法，主要用于解决网格服务端对客户端进行访问控制的问题，通过使用本发明提出的方法可以避免过去访问控制需要使用数据库的低效性，在不降低授权能力的前提下提高了访问控制决策的速度，可以有效的达到网格服务端对客户端的访问控制的目的。下面我们给出具体的说明。

高效性：本发明方法的策略文件和请求策略文件使用的是xml文件格式，可扩展标记语言xml是一种元标记语言，它使用简单灵活的标准格式，为基于网格的应用提供了一个描述数据和交换数据的有效手段。因而不再需要使用数据库操作，提高了访问控制的运行效率。

灵活性：由于xml文件可以由使用者根据自己的需要来定义标记，因而服务提供节点在生成策略文件可以添加所需要的类型，比如可以添加<环境>元素，用来说明<主体>或者<资源>元素所要求的一些附加条件。这样使得使用基于策略的访问控制有很大的灵活性，服务提供节点可以灵活地来定义自己的策略文件；

可扩展性：在此只是提供了四种不同类型的策略，服务提供节点还可以定义别的策略，比如可以要求客户端必须是某一群体成员，或者必须得到服务提供节点所信任的个人或组织的授权等，这些都可以通过在<条件>元素中定义不同的属性和条件值来实现。

附图说明

图1是使用策略匹配来进行网格服务访问控制机制的参考体系结构示意图。

图2是请求策略文件的格式。

图3是策略文件的格式。

图4是响应策略文件的格式。

图5是本发明所规定的策略集合示意图，表示本发明方法包括的组件示例。

图6是本发明的流程图。

具体实施方式

为了方便描述，我们假定有如下应用实例：

一个网格客户要使用某个网格服务来完成某一项任务，我们假定该网格服务端已经对网格客户进行了认证过程，并且认证通过。接着就是对客户的授权过程，使用基于策略的访问控制(授权)的具体实施方式为：

(1)服务提供节点根据信任服务策略，确定<目标>元素中的<主体>子元素的属性和值；

(2)服务提供节点根据操作选择策略，确定<目标>元素中的<动作>元素的属性和值；

(3)服务提供节点根据服务时间策略，确定<规则>元素中的<条件>子元素关于“时间”的属性和值；

(4)服务提供节点根据系统性能策略，确定<规则>元素中的<条件>子元素关于“性能”的属性和值；

(5)服务提供节点确定<目标>元素中的<资源>子元素的属性和值；

(6)确定四种策略后，生成相应的策略文件；

(7)服务提供节点将策略文件提交给服务端，例如使用基于TCP/IP的Socket方法；

(8)需要访问网格服务的客户端填写服务端提供的四种请求策略信息，并生成请求策略文件；

(9)客户端将生成的请求策略文件提交给服务端，例如使用基于TCP/IP的Socket方法；

(10)服务端接收到策略文件后，检查策略文件所需要确定的元素，并相应的对外发布请求策略信息，分别为操作选择请求策略、服务时间请求策略、信任属性请求策略、系统性能请求策略，每种请求策略信息都提供了相应的元素名和所需要的属性，以供客户端填写；

(11)服务端得到请求策略文件后，将请求策略文件与每一个服务提供节点提交的策略文件进行匹配。

(12)检查请求策略文件和策略文件中<目标>元素中的子元素<主体>的值是否相匹配，比如当策略文件中的“主体属性”为“rfc822Name-match”，“主体值”为“grid.com.cn”，而请求策略文件的“主体值”为“chenjg@grid.com.cn”时，主体匹配成功，继续后面元素的匹配过程；而若而请求策略文件的“主体值”为“chenjg@sohu.com.cn”时，主体匹配失败，这时便生成响应策略文件，并且<决策>元素的值为“deny”，表示该服务提供节点拒绝为该客户提供服务。

(13)检查请求策略文件和策略文件中<目标>元素中的子元素<操作>值是否相匹配，同样若匹配成功则继续后面的匹配过程，不成功就生成响应策略文件，并且<决策>元素的值为“deny”。

(14)比较请求策略文件中<目标>元素中的子元素<主体>关于“服务时间”的元素值和策略文件中<规则>元素中的子元素<条件>关于“服务时间”的元素值是否匹配，即客户端所要求提供的服务时间是否在服务  提供节点所能提供的服务时间范围内，若在则匹配成功，进行后面的匹配，若不在，则匹配失败，便生成响应策略文件，并且<决策>元素的值为“deny”。

(15)比较请求策略文件中<目标>元素中的子元素<主体>关于“系统性能”的元素值和策略文件中<规则>元素中的子元素<条件>关于“系统性能”的元素值是否匹配，若匹配则生成响应策略文件，并且<决策>元素的值为“permit”，表示客户端的请求策略文件完全满足该服务提供节点的要求，该服务提供节点允许客户使用该资源；若匹配失败，便生成响应策略文件，并且<决策>元素的值为“deny”。

(16)服务端对请求策略文件和每一个策略文件都匹配完成后，得到一组相应的响应策略文件；

(17)服务端从响应策略文件中提取出<决策>元素的值为“permit”的响应策略文件，并从中得到相应的服务提供节点，这些节点即是能够向该客户提供服务的节点；

(18)服务端将客户端提交给服务端的任务分别在通过授权的服务提供节点上运行，至此授权过程结束。