CN104050220A - 动态的基于策略的来自外部数据仓库的权利的方法和装置 - Google Patents

Abstract

本发明内容涉及动态的基于策略的来自外部数据仓库的权利的方法和装置。一种用于评估具有属性集合的基于情境的（例如XACML）策略的由机器实现的方法利用基于被评估的安全策略动态生成的查询来制定对一个或多个现有外部仓库的搜索。该方法将可能可允许的资源的候选集合的构建转移到授权引擎（例如策略判决点（PDP））。在操作中，应用利用权利请求调用PDP，并且作为响应，PDP通过生成对外部数据仓库的查询并接收该查询的结果来基于定义的安全策略构建值的候选集合。此方法使得能够在运行时实现由策略驱动的权利查询。

Description

动态的基于策略的来自外部数据仓库的权利的方法和装置

技术领域

本公开大体上涉及分布式计算环境中的访问控制机制，具体而言涉及评估基于情境的策略（context-based policy）以用于授权（authorization）和权利（entitlement）处理的技术。

背景技术

可扩展访问控制标记语言（eXtensible Access Control MarkupLanguage）或者说XACML是由结构化信息标准促进组织（Organization for the Advancement of Structured InformationStandards，OASIS）管理的用于管理访问控制策略的行业标准。该行业标准可从OASIS的网站获得。XACML提供了一种用于指定访问控制策略的基于XML的、基于情境的安全语言。当用于访问控制时，诸如XACML之类的现有开放标准格式集中在返回单个访问判决，例如“许可”或“拒绝”。相对照地，“权利”涉及如下概念：返回一组项目，对于该组项目，允许访问。通常，权利是管治某一身份对信息、应用和系统的访问的（通过策略呈现的）一组控制规范，其中用户是一个这种身份。对于权利的支持是促进更高效的访问控制模型的常见要求。

在诸如XACML之类的其中访问控制请求由包含关于请求本身和相关环境的属性的情境构成的情境性安全策略中，权利经常是通过从策略中选择这些属性的子集来“索引”和支持而提供的。然而，此方法不会缩放以适应于要返回的数据是在外部仓库中定义的大数据集合。当然，授权引擎检查（来自外库数据库的）每一个可能的返回值的“蛮力”方法不是可缩放的。

更概括地说，要解决的问题是如何确定来自一个非常大的数据集合的哪些资源被授权让用户对它们执行动作。应该准予访问的标准被定义在安全策略集合中；然而，例如在诸如数据库或LDAP服务器之类的现有外部仓库中，正被访问的资源被存储在安全策略集合之外。

此问题的现有解决方案（除了蛮力方法以外）要么要求在咨询判决引擎之前对数据进行预过滤，要么要求将可能资源的集合复制到安全策略或补充数据存储库中。在预过滤方法中，实现一种两阶段过程。应用首先调用数据库来构建允许值的候选集合；然后，对于每个值，应用通过利用授权请求来调用授权引擎以判决当前用户是否被允许访问。这个方法具有多个局限性，包括安全策略在应用和授权引擎两者中都被复制或部分复制。因为查询经常被硬编码到应用中，所以任何改变都要求开发、测试、生产和Q/A周期，这是昂贵且耗时的。另外，在此方法中，过滤责任从策略判决点转移到了应用，并且这对应用产生了进一步的负担，因为其需要为每个候选者作出一系列的个体授权请求（或者关于所有事的大型访问查询）。在数据复制方法中，数据被从现有仓库复制到安全策略中或补充数据存储库中；然后，调用授权引擎的应用使用权利请求来获得值的集合。此方法的局限性在于不再有数据的单个规范存储，并且数据复制可要求大量使用盘空间和存储器。另外，如果使用安全策略方法，则对可能值的集合的改变要求修改策略并将其加载到授权引擎中，从而可能牵涉工作流和管治过程。

将希望允许利用诸如XACML之类的情境性安全策略语言来评估权利，而不管被访问的资源是否存储在安全策略外部。

发明内容

一种用于评估具有属性集合的基于情境的（例如XACML）策略的由机器实现的方法利用基于被评估的安全策略动态生成的查询来制定对一个或多个现有外部仓库的搜索。该方法将可能可允许的资源的候选集合的构建转移到授权引擎（或者更概括地说是策略判决点（PDP））。在操作中，应用利用权利请求调用PDP，并且作为响应，PDP通过生成对外部数据仓库的查询并接收该查询的结果来基于定义的安全策略构建值的候选集合。此方法使得能够在运行时实现由策略驱动的权利查询。

在说明性实施例中，响应于在授权引擎处接收到权利请求，确定可适用于当前权利请求的一个或多个XACML规则的集合；在替换方案中，可以预先确定或以其他方式获得这些规则。对于每个可适用的规则，基于该规则动态生成对外部仓库的查询以找出返回值的“候选集合”。查询不必是XACML规则的精确转化——其主要作为一种缩窄搜索空间以避免对数据库或仓库的蛮力搜索的方式而存在。查询可以为许多形式，包括——但不限于——到SQL语句的直接转化、到LDAP过滤器的直接转化、到后端不可知的中间形式的转化，等等。这样，潜在值的“候选集合”被限制到由安全策略本身（或者由特制的补充存储库）定义的值的集合，而不是来自现有的外部源本身。为了完成操作，作为授权请求对照完整策略评估（从对外部数据存储库的查询返回的）此候选集合的每个元素以确保安全策略的所有要求得到满足。

以上概述了本发明的更相关特征中的一些。这些特征应当被理解为只是说明性的。通过以不同的方式应用所公开的发明或者通过修改将会描述的发明，可以获得许多其他有益的结果。

附图说明

为了更完整地理解本发明及其优点，现在参考以下结合附图的描述，附图中：

图1描绘了说明性实施例的示范性方面可在其中实现的分布式数据处理环境的示范性框图；

图2是说明性实施例的示范性方面可在其中实现的数据处理系统的示范性框图；

图3是用于促进本文描述的技术的策略评估管理器的高级别组件的框图；

图4示出了用于编写、分布和实施策略的代表性策略管理系统；

图5示出了根据本公开的应用如何与策略判决点（PDP）交互以及对外部数据仓库的查询的动态生成；

图6是示出根据本公开的外部数据仓库的策略驱动查询的处理流程；

图7是示出用于生成对外部数据仓库的动态查询的技术的处理流程；

图8是用于根据第一示例场景使用的代表性数据库表格；

图9是利用本公开的动态的基于策略的权利查询方法（在第一示例场景中）在PDP处实施的代表性XACML安全策略；

图10是在第一示例场景中从交易应用发出并被PDP接收以处理的代表性权利请求；

图11是用于根据第二示例场景使用的代表性数据库表格；

图12是利用动态的基于策略的权利查询方法（在第二示例场景中）在PDP处实施的代表性XACML安全策略；以及

图13是在第二示例场景中从银行应用发出并被PDP接收以处理的代表性权利请求。

具体实施方式

现在参考附图，特别是参考图1和图2，提供了可实现本公开的说明性实施例的数据处理环境的示范图。应当领会，图1和图2只是示范性的，而并不打算断言或暗示关于所公开的主题的方面或实施例可在其中实现的环境的任何限制。在不脱离本发明的精神和范围的情况下，可进行对描绘的环境的许多修改。

现在参考附图，图1描绘了说明性实施例的各方面可在其中实现的示范性分布式数据处理环境的图示。分布式数据处理系统100可包括计算机的网络，说明性实施例的各方面可在其中实现。分布式数据处理系统100包含至少一个网络102，该至少一个网络102是用于提供在分布式数据处理系统100内连接在一起的各种设备和计算机之间的通信链路的介质。网络102可包括连接，例如有线、无线通信链路或光缆。

在描绘的示例中，服务器104和服务器106与存储单元108一起连接到网络102。此外，客户端110、112和114也连接到网络102。这些客户端110、112和114例如可以是个人计算机、网络计算机等等。在描绘的示例中，服务器104向客户端110、112和114提供数据，例如引导文件、操作系统镜像和应用。客户端110、112和114在描绘的示例中是服务器104的客户端。分布式数据处理系统100可包括没有示出的额外的服务器、客户端和其他设备。

在描绘的示例中，分布式数据处理系统100是因特网，其中网络102代表使用传输控制协议/因特网协议（TCP/IP）协议组来与彼此通信的网络和网关的世界范围集合。在因特网的中心处是由路由数据和消息的成千上万的商业、政府、教育和其他计算机系统构成的主要节点或主机计算机之间的高速数据通信线路的骨干网。当然，分布式数据处理系统100也可实现为包括数个不同类型的网络，例如内联网、局域网（LAN）、广域网（WAN）等等。如上所述，图1打算作为示例，而不是作为对于所公开的主题的不同实施例的体系结构限制，因此，图1中所示的特定元素不应当被认为是对于本发明的说明性实施例可在其中实现的环境的限制。

现在参考图2，示出了示范性数据处理系统的框图，说明性实施例的各方面可在其中实现。数据处理系统200是计算机的示例，例如图1中的客户端110，实现本公开的说明性实施例的处理的计算机可使用代码或指令可位于该计算机上。

现在参考图2，示出了数据处理系统的框图，说明性实施例可在其中实现。数据处理系统200是计算机的示例，例如图1中的服务器104或客户端110，对于说明性实施例实现处理的计算机可使用代码或指令可位于该计算机中。在这个说明性示例中，数据处理系统200包括通信架构202，该通信架构202提供处理器单元204、存储器206、持久性存储装置208、通信单元210、输入/输出（I/O）单元212和显示器214之间的通信。

处理器单元204用来执行可加载到存储器206中的软件的指令。取决于具体实现，处理器单元204可以是一个或多个处理器的集合或者可以是多处理器核。另外，处理器单元204可利用一个或多个异构处理器系统来实现，其中主处理器与次处理器一起存在于单个芯片上。作为另一说明性示例，处理器单元204可以是包含同一类型的多个处理器的对称多处理器系统。

存储器206和持久性存储装置208是存储设备的示例。存储设备是任何能够临时地和/或永久地存储信息的硬件。存储器206在这些示例中可以例如是随机访问存储器或任何其他适当的易失性或非易失性存储设备。取决于具体实现，持久性存储装置208可采取各种形式。例如，持久性存储装置208可包含一个或多个组件或设备。例如，持久性存储装置208可以是硬盘驱动器、闪存、可改写光盘、可改写磁带或者上述的某种组合。持久性存储装置208使用的介质也可以是可移除的。例如，对于持久性存储装置208可使用可移除硬盘驱动器。

通信单元210在这些示例中提供与其他数据处理系统或设备的通信。在这些示例中，通信单元210是网络接口卡。通信单元210可通过使用物理和无线通信链路中的任一者或两者来提供通信。

输入/输出单元212允许与可连接到数据处理系统200的其他设备输入和输出数据。例如，输入/输出单元212可提供用于通过键盘和鼠标的用户输入的连接。此外，输入/输出单元212可将输出发送到打印机。显示器214提供向用户显示信息的机制。

用于操作系统和应用或程序的指令位于持久性存储装置208上。这些指令可被加载到存储器206中供处理器单元204执行。不同实施例的处理可由处理器单元204利用由计算机实现的指令来执行，这些指令可位于存储器中，例如存储器206。这些指令被称为程序代码、计算机可使用程序代码或计算机可读程序代码，其可被处理器单元204中的处理器读取和执行。不同实施例中的程序代码可实现在不同的物理或有形计算机可读介质上，例如存储器206或持久性存储装置208。

程序代码216以功能形式位于可选择性移除的计算机可读介质218上并且可被加载到或传送到数据处理系统200上以供处理器单元204执行。程序代码216和计算机可读介质218在这些示例中形成计算机程序产品220。在一个示例中，计算机可读介质218可以是有形形式的，例如光盘或磁盘，其被插入或放置到作为持久性存储装置208的一部分的驱动器或其他设备中，以便传送到存储设备上，例如作为持久性存储装置208的一部分的硬盘驱动器。在有形形式中，计算机可读介质218也可采取持久性存储装置的形式，例如连接到数据处理系统200的硬盘驱动器、指状储存器或闪存。计算机可读介质218的有形形式也被称为计算机可记录存储介质。在一些场合中，计算机可读介质218可以不是可移除的。

或者，程序代码216可通过到通信单元210的通信链路和/或通过到输入/输出单元212的连接被从计算机可读介质218传送到数据处理系统200。通信链路和/或连接在说明性示例中可以是物理的或无线的。计算机可读介质也可采取非有形介质的形式，例如包含程序代码的通信链路或无线传输。对于数据处理系统200说明的不同组件并不意欲提供对可实现不同实施例的方式的体系结构限制。不同的说明性实施例可实现在包括除了对于数据处理系统200说明的那些以外或者取代对于数据处理系统200说明的那些的组件的数据处理系统中。图2中所示的其他组件可与所示出的说明性示例不同。作为一个示例，数据处理系统200中的存储设备是任何可存储数据的硬件装置。存储器206、持久性存储装置208和计算机可读介质218是有形形式的存储设备的示例。

在另一示例中，总线系统可用于实现通信架构202并且可包括一个或多个总线，例如系统总线或输入/输出总线。当然，总线系统可利用提供附接到总线系统的不同组件或设备之间的数据传送的任何适当类型的体系结构来实现。此外，通信单元可包括用于发送和接收数据的一个或多个设备，例如调制解调器或网络适配器。另外，存储器可以例如是存储器206或缓存，例如在可存在于通信架构202中的接口和存储器控制器中心中找到的那种。

用于实现本发明的操作的计算机程序代码可由一个或多个编程语言的任何组合来编写，这些编程语言包括诸如Java、Smalltalk、C++之类的面向对象的编程语言，和诸如“C”编程语言或类似编程语言之类的传统的过程式编程语言。程序代码可完全在用户计算机上执行，部分在用户计算机上执行，作为独立的软件包执行，部分在用户计算机上并且部分在远程计算机上执行，或者完全在远程计算机或服务器上执行。在后一种场景中，远程计算机可通过包括局域网（LAN）或广域网（WAN）在内的任何类型的网络连接到用户计算机，或者可以与外部计算机进行连接（例如，利用因特网服务提供商通过因特网进行）。

本领域普通技术人员将领会到，取决于实现，图1和图2的硬件可有所不同。除了图1和图2中描绘的硬件以外或者替代这些硬件，可以使用其他内部硬件或外围设备，例如闪存、等效的非易失性存储器或光盘驱动器等等。另外，在不脱离所公开的主题的精神和范围的情况下，除了先前提到的SMP系统以外，说明性实施例的处理可应用到多处理器数据处理系统。

数据处理系统支持本领域中已知的基于情境的安全策略机制。一个这种机制是可扩展访问控制标记语言或者说XACML。假定熟悉XACML。XACML策略由策略集合和策略组合算法构成。策略集合是策略集合或策略的序列，以及目标，并且策略是目标、规则集合和规则组合算法。目标指定策略或策略应用到的请求的类型。仅当一请求满足策略的目标时，然后才对照策略规则集合检查该请求。规则集合是规则的集合，并且规则具有目标、可选的条件和效果（例如，许可或拒绝）。规则目标指定该规则是否可适用于该请求。如果一请求匹配规则的目标和任何条件，则效果被作为判决返回。XACML提供了若干种规则或策略组合算法，包括但不限于：第一可适用、仅一个可适用、拒绝推断（deny-overrides）、许可推断（permit-overrides）。XACML访问控制通过利用一个或多个基于XACML的访问控制策略评估XACML请求（包含经认证的主体、所访问的资源和所执行的动作）并且返回许可或拒绝所请求的访问的XACML响应来工作。

作为额外的背景，图3示出了已知的策略评估管理器的高级别组件。策略管理配置300是图2的数据处理系统200的情境内的评估管理器302的示例实现。具体地，策略评估管理器302被示为在图2的数据处理系统200的存储器206内。根据需要，策略评估管理器302也可位于其他存储器位置内，直到需要使用为止。其他存储器位置包括图2的持久性存储装置208。策略评估管理器302包括数个合作的组件，以实现安全策略相关请求的有效评估。这些组件通常包括索引构建器304、解析器306、编辑器308、取回器310、评估器312和规则数据库（DB）314。这些组件与彼此合作工作，但也与其他系统相关组件合作工作。虽然被示为分开的实体，但这些组件也可实现为共同产品内的服务集合，或者以其他方式组合来实现相同的功能能力。

索引构建器304提供了基于词汇元素的规则的值产生密钥的能力。索引的密钥是为了使得规则可适用而必须包含在请求中的属性值的组合。密钥因此是从属性值组合构建的。索引密钥减少了确定与请求相关的可适用策略元素所需的时间。策略元素是属性和值组合。例如，属性“subject-id”和关联的值“Craig”定义了策略元素“subject-id=Craig”。策略于是是当利用关联的条件来评估时可提供单个结果的策略元素的集合。解析器306提供解析能力，以分析请求、规则信息和策略词汇。解析器可以是用于解释所使用的标记语言的那个解析器或者可以专用于额外的任务。编辑器308具有创建、修改和删除规则以及策略元素的能力。编辑器308可以是适合于与为策略元素和规则实现选择的数据格式一起工作的典型文本编辑器或其他具有编辑能力的组件。取回器310根据评估请求的需要从规则数据库或存储系统取得规则。取回可针对稍后评估的候选规则的列表或集合进行。规则也可被编辑器取回以供后续处理。评估器312提供检查依次提供的规则以确定结果的能力。如前所述，为了使得规则可适用，结果必须返回“真”。规则数据库（DB）314包含规则的集合。规则由目标部分和条件部分组成。目标部分定义规则的目标或主体。条件部分定义为了使规则为真而必须结合主体满足的可适用于目标的标准。例如，用于薪资处理的规则可具有目标“年薪”和条件部分“少于20,000”。索引316是通过索引构建器304的构建处理获得的相关密钥的集合。索引316的密钥表示相应策略元素的有序列表。策略表格318是包括关于策略元素和规则标识符的条目的数据结构。当实现为表格时，该数据结构中的每一行包含策略和相应的规则条目。策略元素定义密钥。

一旦（通过已知技术）平坦化（flatten）了XACML策略，结果就是不同的策略元素的集合。通常，每个规则仅可适用于一个请求。这个适用性是由诸如“字符串等于”和“整数大于”之类的函数的组合确定的。对于这些函数的唯一限制是它们必须取两个参数作为参量并且返回布尔值。索引处理只要求相等函数存在于策略元素的目标中。这个限制确保了可执行高效的集合查找，而不是XACML通常要求的对于匹配值的顺次检查。为了实现这一点，不等于匹配函数被从规则的目标区段移动到规则的条件区段或部分中，利用布尔AND运算符与任何现有的条件相组合。

可对策略进行索引处理，以便能够迅速且高效地确定可适用于给定请求的策略元素。在一种已知的方法中，策略被简化为不同规则的集合，其中每个规则可适用于仅一个请求。为这些不同的规则创建索引，其中索引的密钥是为了使规则可适用而必须存在于请求中的属性值的组合。为了确保从索引进行高效查找，不涉及相等检查的所有函数都位于规则的条件部分中。这个索引处理通常允许更高效地评估安全策略的大集合。包含策略元素的请求被接收。该请求被处理以便通过对策略元素的集合的规则的索引查找来分析策略元素。然后针对策略元素评估该规则。索引处理提供了更高效的机制来确定规则对于给定策略的适用性。

本领域中还已知提供了一种机制，用于构建和游走树数据结构以评估对于给定的权利请求要返回的潜在权利值。这种类型的一个方法在本申请的申请人所拥有的美国公布2011/0246498号中描述，在此通过引用并入该美国公布的公开内容。在该方法中，利用加权索引树来评估具有属性集合的基于情境的（例如XACML）策略，其中该加权索引树具有从根节点延伸的一个或多个叶子。该树的每个叶子表示一个策略规则。沿着叶子往下的深度优先路径表示该属性集合中为了使规则可适用而必须存在于请求中的一个或多个属性。对照该加权索引树来评估输入以生成响应。一类输入是授权请求，在此情况下响应是授权判决（例如许可或拒绝）。另一类输入是对于权利集合的查询，在此情况下响应是权利的集合。

图4示出了本领域中也已知的一种代表性企业策略管理系统400。系统400可跨一个或多个机器实现，这些机器在例如图1中所示的计算环境中操作。通常，系统包括策略管理点（policy administrationpoint，PAP）402、策略判决点（policy decision point，PDP）404和策略实施点（policy enforcement point，PEP）406。一般地，策略管理点402用于定义策略，该策略可被指定为XACML策略表达式的集合。此策略使用从用户仓库408提供的主体属性，以及从策略信息点（policy information point，PIP）410接收的运行时和环境数据。策略判决点（PDP）404接收类似的信息并对从策略实施点（PEP）406接收的XACML策略查询作出响应以对主体并针对由主体发起的特定动作来实施策略。PDP404实现策略判决。在此方法的一种商业实现中，PAP402由安全策略管理器（Security PolicyManager，TSPM）策略服务/控制台实现，PDP404在TSPM运行时安全服务中实现，并且PEP实现为应用服务器——例如IBM应用服务器——的TSPM插件。

策略管理系统可利用例如图2中所示的一个或多个计算机器来实现。

策略管理点通常包括基于web的用户界面，通过该用户界面可编写和分布企业私有策略。

来自外部数据仓库的动态的基于策略的权利

以上述作为背景，现有描述本公开的主题。根据本公开，要解决的大致问题是如何确定来自非常大的数据集合的哪些资源被授权让用户对它们执行动作。应该准予访问的标准在安全策略集合中定义；然而，被访问的资源被存储在安全策略集合之外，例如存储在诸如数据库或LDAP服务器之类的现有外部仓库中。

将可以看出，本公开的技术可在传统的基于XACML的处理链内实现，该处理链优选包括适当的请求和响应协议来处理查询。优选地，功能在策略判决点（PDP）（或其他授权引擎）内实现，或者实现为其附件（adjunct）。例如图4中所示的策略管理系统代表了操作环境，虽然这并非限定。本文使用的“授权请求”是对PDP的要求许可/拒绝判决的请求，例如“用户Craig能够对资源“resource-1”执行“读取”动作吗？”。“权利请求”是对PDP的要求值的集合的请求，例如“用户Craig被允许对哪个（或哪些）资源执行“读取”动作？”

图5示出了实现动态的由策略驱动的查询操作的基本操作环境。如图所示，应用500利用权利请求501调用PDP502，并且PDP502基于定义的策略504来构建值的候选集合。可以是任何类型的进行调用的应用500优选地仅与PDP502交互，从而该应用不关心数据是如何存储的或者存储在何处。在此，应用500是应用组的权限，而PDP在安全组的权限内。PDP通过与至少一个外部数据仓库506交互来（基于定义的策略）构建值的候选集合。数据仓库在数据库管理员的权限内。外部数据仓库506可以是许多不同类型中的一种，并且这些外部数据源在结构、设计和查询语言以及位置上可以彼此不同。根据本公开，如将会描述的，PDP502在运行时——即在对由PDP从应用500接收的权利请求的处理期间——动态地生成对外部数据仓库506的查询503。虽然示出了对外部数据仓库506的一个查询503，但可以有对该仓库的多个查询，和/或对多个不同的外部仓库的多个不同的查询。

查询是在PDP的“运行时”动态生成的，即，是在从应用接收到要被PDP评估的权利请求时动态生成的。

图6示出了可在图4所示的PDP中实现的基本操作。在步骤600，确定可适用于当前权利请求的一个或多个XACML规则的集合。此确定可以以若干种已知方式中的一种来执行，例如通过利用加权搜索树进行的基于情境的安全策略评估，例如美国公布2011/0246498号中描述的那种，或者其他已知的方案。对于每个可适用的XACML规则，来自外部仓库的任何返回值将必须满足该规则的要求。从而，在步骤602，根据本公开，对于每个可适用的规则，基于该规则动态地生成对外部仓库的查询以找到返回值的“候选集合”。如下文将描述的，在步骤602中生成的查询不是必须是XACML规则的精确转化——其主要作为一种缩窄搜索空间以避免对数据库或仓库的蛮力搜索的方式而存在。查询可以为许多形式，包括——但不限于——直接转化成SQL语句、直接转化成LDAP过滤器、转化成后端不可知的中间形式，等等。这样，潜在值的“候选集合”被限制到由安全策略本身（或者由特制的补充存储库）定义的值的集合，而不是来自现有的外部源本身。在步骤604，为了完成操作，作为授权请求对照完整策略评估此候选集合的每个元素以确保安全策略的所有要求得到满足。

图7示出了可用于基于特定规则利用动态生成的查询针对外部数据库制定和执行搜索的优选技术。图7所示的处理优选是自动化的并且对于返回的每个规则（在PDP中）执行。该例程在确定（或接收到）规则时开始于步骤700。在步骤702，为了跨后端数据存储库类型（例如，DB2、LDAP，等等）的一致性，XACML“条件”中的逻辑被映射到中间格式。在步骤704，该中间格式随后被映射到可用于外部仓库中的特定查询格式。在步骤706，来自请求的已知值随后被填充到此查询中。如以上联系图6所述，随后对外部数据存储库来执行该查询。在步骤708中对外部数据仓库执行查询，并且其导致返回允许值的候选集合。作为一种优化，每个返回的值被认为是“候选”权利，并随后被对照完整策略来加以检查。这是步骤710。如图7所示，步骤700、702、704和706表示查询制定，并且步骤708和710表示查询执行（即，外部数据仓库的搜索）。如上所述，取决于策略（以及其中的规则条件），可以有多个查询被生成并对该仓库或者多个仓库（包括不同类型的仓库）执行。

本领域普通技术人员将领会，上述技术提供了一种作为（来自应用的）权利调用的一部分高效地（且动态地）查询外部数据仓库的方式。创建查询的中间（或正规化的）形式并随后创建被填充来自请求的已知值的特定查询格式的方式带来了对外部数据仓库的更有针对性的搜索，从而使得数据的更精细子集被作为最终结果返回。与使用蛮力或其他已知方法（预过滤或复制方法）相比，这个方法带来了高得多的效率。

以下提供了若干个示例场景来说明上述操作。

考虑一个数据库表格，其包含股票代码的列表，以及其所挂牌在的相关股票交易所。此形式的表格在图8中示出。由于此数据被频繁更新，所以其是被置于任何可适用的安全策略之外的天然数据集。现在，考虑交易应用需要知道一个交易员被允许对哪些股票代码执行交易。于是可定义XACML属性的以下集合：（Section/AttributeId），描述；Subject/subject-id，用户的区分名称；Subject/group-id，用户的群组成员资格的集合；Subject/trade-exchange，用户被允许进行交易的交易所；Resource/resource-id，被交易的股票；Resource/exchange，该股票所挂牌在的交易所；以及Action/action-id，对该股票执行的动作（例如“交易”）。为了说明，假定仅为示范性的这个属性集合被用于定义安全策略并且被应用在（向PDP）发出授权请求或权利请求时使用。

现在，假定PDP也具有将这些属性绑定到其来源的配置数据集合，该来源可以是应用或者外部数据源。例如，这些可以是对上述属性的绑定：Subject/subject-id，由应用提供；Subject/group-id，由应用提供；Subject/trade-exchange，基于subject-id从策略信息点（PIP）（例如图4中的元件410）即公司目录取回；Resource/resource-id，（列出（一个或多个）股票代码及其相应的（一个或多个）交易所的）STOCK_SYMBOLS表格中的“代码”列；Resource/exchange，STOCK_SYMBOLS表格中的“交易所”列；以及Action/action-id，由应用提供。注意，此示例中的Subject/trade-exchange属性被配置为是利用策略信息点（PIP）从公司LDAP目录中取回的。具体地，PDP将使用在由应用提供的Subject/subject-id属性中找到的区分名称（DN），在LDAP服务器中找到该条目，并且从该条目返回一可能多值的属性，该属性包含交易员被允许执行交易的股票交易所。另外，注意，属性Resource/resource-id和Resource/exchange被配置为是从将（一个或多个）代码与（一个或多个）交易所相关联的外部数据库表格取回的。也可以有额外配置来允许这些属性被用作来自外部权利的数据。

现在，考虑以下安全策略：“当前用户被许可交易一股票，如果其交易所在该用户的允许交易所的列表中的话”。这个安全策略于是可由图9中记载的XACML片段来表示。利用该安全策略，交易应用随后将对PDP作出权利请求，指定已知的属性和作为权利请求返回值请求的属性。该权利请求可如图10中记载那样来指定。根据本公开，在评估期间，PDP确定（图9中的）XACML规则可适用。PDP还确定，因为该规则对于Resource/resource-id没有指定值，所以随后要求对外部仓库的调用（以获得此属性的可能值）。另外，由于Action/action-id值（在此示例中）是从输入请求匹配的，所以XACML<Condition>是请求的需要被转化成外部查询的相关部分。

为此，根据本公开的这个查询生成处理，XACML<Condition>首先被转化成以下正规化形式：[Attribute][Function][Attribute]。当然，取决于XACML条件，可利用布尔逻辑来组合属性。为了说明的清晰起见，此示例省略了这种细节。继续此示例，并且代入属性，上述正规化形式于是被改写如下：[Resource/exchange][equals][Subject/trade-exchange]。现在，因为希望获得Resource/resource-id属性的返回值，所以通过（利用Find运算元）将此属性前置于上述正规化形式来生成查询：

Find[Resource/resource-id]for which[Resource/exchange][equals][Subject/trade-exchange]

以上语句表示动态生成的查询的中间（或正规化）格式（如图7中的步骤702中所述）。这个通用格式随后被转化成依要查询的数据仓库的类型而定的本地查询。在此示例中，假定外部数据仓库是SQL数据库。从而，考虑到搜索将是对数据库表格的搜索，示例正规化查询被转化成SQL（如图7中的步骤704中所述），例如：

SELECT[Resource/resource-id]WHERE[Resource/exchange]EQUALS[Subject/trade-exchange]

考虑到存在一些属性到此表格中的列的已知映射，这些映射于是被代入到查询中（如图7中的步骤706中所述），从而产生SQL查询的近最终形式：

SELECT SYMBOL FROM STOCK_SYMBOLS WHEREEXCHANGE EQUALS[Subject/trade-exchange]

此查询的缺失部分可由PDP通过利用公司目录从PIP取回来解决。假定对PIP的查询只返回了值“NYSE”。此值随后也可被代入来产生最终查询：

SELECT SYMBOL FROM STOCK_SYMBOLS WHEREEXCHANGE EQUALS“NYSE”

此查询随后对外部数据库被执行并返回候选集合，例如{IBM BAC}。如上所述，这些值包括从当前权利查询返回的候选集合。这是图7中的步骤708。随后对照安全策略的完整集合来分别评估这些值（图7中的步骤710），因为可能有其他可适用的规则或者不能被转化成SQL子句的条件部分。

作为另一示例，考虑银行账户数据库表格CUST_ACCOUNTS，其包含以下信息：ACT_ID，账户的唯一号码；CUST_ID，客户的内部标识符；TYPE，账户的类型，例如支票或储蓄；以及BAL，账户中的余额。对于此示例，假定如图11中的表格中所示那样填充该数据库。利用（定义外部仓库中的资源的）已知方法，各种列可被映射到属性标识符，例如ACT_ID=“Resource/db:account-id”，CUST_ID=“Resource/db:customer-id”，TYPE=“Resource/db:account-type”，以及BAL=“Resource/db:account-balance”。此示例中的Resource指的是XACML请求的一个区段，然而这里的方法不限于XACML。

在此示例中，还假定可适用的安全策略指出客户可查看其自己的账户。此规则的伪XACML表示在图12中示出。这个规则指出，如果主体的“customer-id”属性等于Resource的“db:customer-id”属性，则将许可请求。作为一个用例，假定希望对列出客户被许可查看的特定账户的权利进行查询，给定以下输入：Subject/subject-id=craigf，Subject/customer-id=“Cust001”，Action/action-id=“view”并且Return attribute?Resource/db:account-id。这个权利请求在图13中示出。

根据本公开的查询生成方法，首先生成XACML规则<Condition>的正规化形式：

[Subject/customer-id][equals][Resource/db:customer-id]

注意“equals（等于）”子句是基于包含“字符串等于”函数的<Condition>的。<Condition>中的其他函数将被映射到其他通用函数，例如“大于”或“小于”。然后添加尝试定位的值以生成查询的初始形式：

Find[Resource/db:account-id]for which[Subject/customer-id][equals][Resource/db:customer-id]

这就完成了将<Condition>中的逻辑映射到中间格式的步骤。该处理随后继续将该中间格式映射到在外部数据源中可使用的特定查询格式。这里，仓库再一次是数据库表格，因此查询被转换成SQL格式：

SELECT[Resource/db:account-id]FROM CUST_ACCOUNTSWHERE‘Cust001’EQUALS[Resource/db:customer-id]

如果查询是对LDAP目录的，则通用表示（中间格式）将是LDAP搜索过滤器。在将中间格式映射到特定查询格式的这个初始映射之后，已知的数据字段随后被填充到查询中。假定当前用户的客户ID是已知的，则此值被代入：

SELECT ACT_ID FROM CUST_ACCOUNTS WHERE‘Cust001’EQUALS[Resource/db:customer-id]

给定将数据库表格列映射到属性标识符的知识，随后可利用特定列名称来替换属性引用以完成查询生成处理：

SELECT ACT_ID FROM CUST_ACCOUNTS WHERE‘Cust001’EQUALS CUST_ID

随后可对数据存储库执行此查询，仅返回可适用的账户标识符，在此示例中是“000-001”。优选地，如上所述，返回的每个值仅被认为是“候选”权利，该“候选”权利随后被对照完整安全策略来加以检查。

如上述示例所说明的，外部数据仓库可被表示为一组条目，其中每个条目具有唯一标识符，以及多值属性的集合。可按其唯一ID来提取个体条目，并且可基于其属性的值来搜索条目。

上述查询生成技术可被扩展来处理更复杂的场景（即，更复杂的XACML条件，这些条件将被转化成更复杂的查询）、具有更复杂的架构的仓库源、可经由应用编程接口（API）来暴露的非标准仓库源、大数据集合、以及从多个PIP填充的查询中的属性。

所描述的主题提供了许多优点。主要优点是其将可能允许资源的候选集合的构建转移到了PDP。如前所述，应用利用“权利请求”来调用PDP，并且PDP基于定义的策略来构建值的候选集合。实际上，不是将查询硬编码到应用中，而是PDP在运行时（并且特别是在权利查询执行时）构建由策略驱动的查询。利用此方法，应用组只与PDP交互，这意味着应用不关心数据是如何存储的或者存储在何处。不会在IT环境内的多个地方复制安全策略。安全组可更新策略，而不要求应用更新。存在要被用作返回值的数据的一个规范存储库——现有仓库。这个解决方案不要求将此数据复制到仅由PDP使用的补充存储库或者安全策略中。返回值是基于实时数据的，而不是基于复制或拷贝的数据的。应用组与安全组交互，并且安全组与DB管理员交互。

如上所述，优选地，PDP既以中性表示又以语言中性查询语言来表示XACML策略，该查询语言可被配置为映射到不同的数据仓库（这些数据仓库的结构、设计和查询语言可以是不同的），但可将查询主体、术语和动作以所描述的方式导出到应用。PDP中的这些功能的联合促进了作为权利调用的一部分对一个或多个外部仓库的高效查询。

非限制性地，如上所述，上述PDP功能可以用软件实现为一个或多个专用或“特定”机器。策略评估可实现在专用或“特定”机器中，例如权利服务器。可针对此目的来适应性地修改传统的身份管理工具和系统，例如Tivoli安全策略管理器和集成解决方案控制台，或者可以以任何其他方便的方式来实现这些技术。

所描绘的不同实施例中的框图图示了装置、方法和计算机程序产品的一些可能实现的体系结构、功能和操作。在此，流程图或框图中的每个方框可表示包括用于实现指定的一个或多个功能的一个或多个可执行指令的模块、片段或代码部分。在一些替换实现中，方框中记述的一个或多个功能可不按图中记述的顺序发生。例如，在一些情况下，取决于所涉及的功能，相继示出的两个方框可基本同时执行，或者这些方框有时可按相反顺序来执行。

所公开的主题可采取完全硬件的实施例、完全软件的实施例或者包含硬件和软件元素两者的实施例的形式。在优选实施例中，本发明是用软件实现的，软件包括但不限于固件、驻留软件、微代码，等等。

所公开的主题可采取可从计算机可使用或计算机可读介质访问的计算机程序产品的形式，该计算机可使用或计算机可读介质提供程序代码来供计算机或任何指令执行系统使用或与计算机或任何指令执行系统联系使用。对于本说明书而言，计算机可使用或计算机可读介质可以是可包含或存储程序来供指令执行系统、装置或设备使用或与计算机可使用或计算机可读介质联系使用的任何有形装置。

介质是有形的，并且其可以是电子、磁、光、电磁、红外或半导体系统（或装置或设备）。计算机可读介质的示例包括半导体或固态存储器、磁带、可移除计算机盘、随机访问存储器（RAM）、只读存储器（ROM）、刚性磁盘和光盘。光盘的当前示例包括致密盘-只读存储器（CD-ROM）、致密盘-读/写（CD-R/W）和DVD。

适用于存储和/或执行程序代码的数据处理系统将包括通过系统总线直接或间接耦合到存储器元件的至少一个处理器。存储器元件可包括在程序代码的实际执行期间采用的本地存储器、大容量存储装置以及提供至少一些程序代码的临时存储以减少在执行期间必须从大容量存储装置取回代码的次数的缓存存储器。输入/输出或I/O设备（包括但不限于键盘、显示器、指点设备等等）可直接地或通过居间的I/O控制器耦合到系统。网络适配器也可耦合到系统以使得数据处理系统能够通过居间的私有或公共网络变得耦合到其他数据处理系统或远程打印机或存储设备。调制解调器、线缆调制解调器和以太网卡只是几种当前可得类型的网络适配器。

对所公开的主题的描述是为了说明和描述而给出的，而并不打算是穷尽的或者将本发明限制到所公开的形式。本领域普通技术人员将清楚许多修改和变化。选择和描述实施例是为了最好地说明本发明的原理、实际应用并且使得本领域普通技术人员能够针对具有适合于所设想的特定用途的各种修改的各种实施例来理解本发明。

非限制性地，本文描述的技术也可在各种服务器侧体系结构中实现或者结合各种服务器侧体系结构实现，这些服务器侧体系结构包括简单n层体系结构、web门户、联合系统，等等。

实现所公开的技术的访问控制机制可实现为服务，或者实现为独立的机器。

这些技术可应用到任何基于情境的安全策略，而不只是基于XACML的技术。基于情境的安全策略的其他示例包括可扩展权限标记语言（eXtensible rights Markup Language，XrML）和企业隐私授权语言（Enterprise Privacy Authorization Language，EPAL）。

可以利用任何请求-响应协议和除了以上说明的基于XACML的版本以外的其他API机制来实现策略评估。

虽然不是要求的，但结合本公开的主题使用的XACML请求-响应协议可包括包含xacml:Request对象的响应。这是因为语义是使得将输入请求与返回的响应结合创建将针对指定效果（例如许可）评估的请求。利用响应容器中的请求允许了保留可发生的任何布尔AND语义。此外，在权利实施例中，应用编程接口（API）可用于调用权利引擎以取得资源，并且作为响应，返回权利的集合。

在描述了本发明后，现在有如下的权利要求。

Claims (17)

1.一种用于评估基于情境的策略的方法，该策略具有属性集合，该方法被实现于在硬件元件上执行的软件逻辑中，该方法包括：

接收权利请求；

在接收到所述权利请求的情况下，至少基于所述策略，制定对外部数据仓库的搜索查询；

对所述外部数据仓库执行所述搜索查询，并且作为响应，接收一个或多个权利值的候选集合作为结果；

对照所述策略和所述搜索查询的结果评估所述权利请求以生成对所述权利请求的响应。

2.如权利要求1所述的方法，其中，情境策略是以XACML指定的。

3.如权利要求1所述的方法，其中，制定步骤包括：

识别能够适用于所述权利请求的至少一个规则；以及

对于识别出的每个规则，将该规则转化成所述搜索查询。

4.如权利要求3所述的方法，其中，转化步骤包括：

将所述规则中的逻辑映射到正规化格式；

将所述正规化格式映射成与所述外部数据仓库相关联的特定查询格式；以及

将策略属性的一个或多个已知值填充到所述特定查询格式中以生成所述搜索查询。

5.如权利要求4所述的方法，其中，所述特定查询格式是以下之一：SQL语句、LDAP过滤器和后端不可知格式。

6.如权利要求1所述的方法，还包括对照安全策略验证权利值。

7.如权利要求1所述的方法，其中，所述外部数据仓库是以下之一：关系数据库和目录。

8.如权利要求7所述的方法，其中，所述外部数据仓库被表示为一组条目，其中每个条目具有唯一标识符和多值属性的集合，所述多值属性适合于基于所述多值属性的属性值被搜索。

9.一种装置，包括：

处理器；以及

保存计算机指令的计算机存储器，所述计算机指令当被所述处理器执行时执行一种用于评估基于情境的策略的方法，该策略具有属性集合，该方法包括：

接收权利请求；

在接收到所述权利请求的情况下，至少基于所述策略，制定对外部数据仓库的搜索查询；

对所述外部数据仓库执行所述搜索查询，并且作为响应，接收一个或多个权利值的候选集合作为结果；

对照所述策略和所述搜索查询的结果评估所述权利请求以生成对所述权利请求的响应。

10.如权利要求9所述的装置，其中，情境策略是以XACML指定的。

11.如权利要求9所述的装置，其中，制定步骤包括：

识别能够适用于所述权利请求的至少一个规则；以及

对于识别出的每个规则，将该规则转化成所述搜索查询。

12.如权利要求11所述的装置，其中，转化步骤包括：

将所述规则中的逻辑映射到正规化格式；

将所述正规化格式映射成与所述外部数据仓库相关联的特定查询格式；以及

将策略属性的一个或多个已知值填充到所述特定查询格式中以生成所述搜索查询。

13.如权利要求12所述的装置，其中，所述特定查询格式是以下之一：SQL语句、LDAP过滤器和后端不可知格式。

14.如权利要求9所述的装置，其中，所述方法还包括对照安全策略验证权利值。

15.如权利要求9所述的装置，其中，所述外部数据仓库是以下之一：关系数据库和目录。

16.如权利要求15所述的装置，其中，所述外部数据仓库被表示为一组条目，其中每个条目具有唯一标识符和多值属性的集合，所述多值属性适合于基于所述多值属性的属性值被搜索。

17.一种访问控制系统，包括：

存储在计算机存储器中的基于情境的安全策略；

策略评估机构，包括存储在计算机存储器中并被处理器执行以执行以下操作的一组计算机指令：

接收权利请求；

在接收到所述权利请求的情况下，至少基于所述策略，制定对所述策略评估机构外部的数据仓库的搜索查询；

对所述数据仓库执行所述搜索查询，并且作为响应，接收一个或多个权利值的候选集合；

对照所述策略和所述候选集合中的权利值中的至少一个来评估所述权利请求以生成对所述权利请求的响应；以及

访问控制机构，所述访问控制机构使用对所述权利请求的所述响应来使得能够实现访问控制操作。