CN104462982A - 跨应用共享的授权策略对象、目标定义和决策合并算法 - Google Patents

Abstract

本公开涉及跨应用共享的授权策略对象、目标定义和决策合并算法。可以跨系统中的所有应用维护全局策略。全局策略模型可以利用消息应用编程接口（MAPI）来管理。定义全局策略，其包括由多个应用共享的规则。定义多个应用特定策略，其包括用于个体应用的规则。基于所述全局策略和第一应用特定策略判定第一应用是否被允许访问特定资源。基于所述全局策略和第二应用特定策略判定第二应用是否被允许访问所述特定资源。

Description

跨应用共享的授权策略对象、目标定义和决策合并算法

技术领域

本发明的实施例总体上涉及计算机安全领域，更特别地，涉及能跨系统中的多个应用共享的全局安全策略模型。 

背景技术

在许多情况下，企业具有一些在所有应用中强制的公共安全策略。如果这些策略定义于每个应用范围内，则策略将会是冗余的且难以维护。 

在计算机安全领域，一般访问控制包括授权（authorization）、认证（authentication）、访问批准（access approval）、以及审计（audit）。访问控制涉及访问批准，藉此计算机基于已经认证了的主体被授权访问什么来判定同意还是拒绝来自主体的访问请求。认证和访问控制通常组合成单个操作，从而基于成功认证或者基于匿名访问令牌（token）来批准访问。认证方法和令牌可包括密码、生物测定扫描、物理密钥、电子密钥和器件、隐藏路径、社群壁垒（social barrier）、以及通过人和自动化系统来监控。 

在访问控制模型中，可执行系统中的动作的实体通常称为主体（subject），代表对其的访问可能需要被控制的资源的实体通常称为对象（object）。主体和对象可以是软件实体，而非人类用户。在一些模型（诸如对象-权能模型）中，软件实体有可能可以用作主体和对象二者。对象可包括计算系统资源（这里简称为“资源”），诸如可执行应用程序（这里简称为“应用”）、文件系统结构诸如文件和目录、通信端口、易失性存储片段等。 

当前系统使用的访问控制模型可以基于权能（capability）或基于 访问控制列表（ACL）。在基于权能的模型中，保持不会忘记的对于对象的引用或权能提供了对于对象的访问权（大致上类似于拥有房屋钥匙如何准许一个人进入其房屋）；访问权通过在安全通道上传输这样的权能而转移到另一方。在基于ACL的模型中，主体对于对象的访问权可以取决于其身份是否在与对象相关联的列表上（大致上类似于私密方的保镖检查一个人的ID以查看其名字是否在宾客列表中）；访问权可通过编辑该列表而被转移。基于权能的模型和基于ACL的模型二者都可包括允许访问权被授予给一组主体中的所有成员的机制。这样的组本身可以模型化为一个主体。 

访问控制系统可提供授权、识别和认证、访问批准以及追责（accountability）等服务。授权包括规定主体允许执行的动作。识别和认证防止非法主体访问系统。访问批准包括通过基于授权策略将用户与他们允许访问的资源相关联而在操作期间准许访问。追责识别主体执行的动作。 

授权可包括定义主体的访问权。授权策略可规定主体允许在系统内执行的操作。一些操作系统将授权策略实施为权限（permission）的形式集合，其是三种基本访问类型的变型或拓展。利用读访问，主体可以读取文件内容和列出目录内容。利用写访问，主体可以通过增加数据到已有文件结构、创建新文件结构、删除已有文件结构或重命名已有文件结构来改变文件或目录的内容。利用执行访问，主体可以使系统执行（运行）程序。这些权利和权限可以在具有不同访问控制模型的系统中不同地实施。访问控制模型有时分类为自主性或非自主性。一些广泛认可的模型包括自主访问控制（DAC）、强制访问控制（MAC）、基于角色的访问控制（RBAC）以及基于属性的访问控制（ABAC）。 

在基于属性的访问控制（ABAC）中，不一定基于与认证后的用户关联的主体的权利来授予访问权，而是基于用户本身的属性。可以要求用户满足（对于访问控制引擎而言）关于其属性的要求。基于属性的访问控制策略规定哪些要求需要被满足以授予对于对象的访问 权。例如，要求可以是“大于18岁”。在这样的情境下，可证实该要求的用户将被授予访问权。在该模型中，用户可以是匿名的，因为不严格要求认证和识别。用于匿名地证实要求的装置可以利用匿名证书实现。可扩展访问控制标记语言（XACML）是基于属性的访问控制的标准。 

自主访问控制（DAC）包括由对象的拥有者所确定的策略。该拥有者决定哪些用户被允许访问该对象以及那些用户关于该对象具有什么特权。在基于DAC的系统中，系统中的每个对象可具有拥有者。在一些基于DAC的系统中，每个对象的初始拥有者可以是使该对象被创建的主体。对象的访问策略可以由该对象的拥有者确定。在基于DAC的系统中，拥有者可以向诸如其他主体分配特定资源的访问权和权限。 

强制访问控制（MAC）包括如果存在允许用户访问资源的规则，则允许该用户访问该资源。基于MAC的系统的管理在对象利用分级访问控制和/或通过敏感度标签的实施来得到保护时可被简化。在使用敏感度标签的系统中，单独的敏感度标签可被分配给每个主体和对象。主体的敏感度标签可规定其信任等级。对象的敏感度标签可规定访问该对象所需的信任等级。如果主体的敏感度等级等于或大于该对象所要求的信任等级，则该主体被允许访问该对象。基于MAC的系统可以使用基于规则的访问控制。基于规则的控制可包括通过比较对象的敏感度标签和主体的敏感度标签来判定主体是应被授予还是应被拒绝对于该对象的访问。 

基于角色的访问控制（RBAC）可包括由对象位于其中的系统确定的访问策略。RBAC系统可以是非自主性的，因为可以在系统级别对访问进行控制（通过系统管理员，而不是通过对象的拥有者）。RBAC系统可以控制权限的集合。RBAC系统中的角色可以视为一组权限。在RBAC系统中，如果主体已经被分配被允许访问资源的角色，则该主体可以访问该资源。角色可以在层级中组合，在层级中，较高等级的角色包含低角色所拥有的权限。 

难题可能出现在包括异构授权（或访问控制）环境的企业中。这种异构授权环境可采用全异访问控制模型。例如，企业可能包括采用Java Platform Security（JPS）作为授权环境的一些组件以及采用Oracle Access Manager（OAM）作为授权环境的另一些组件。JPS提供的访问控制可以是应用特定的；这种访问控制可以由应用的设计者实施在那些应用内，应用设计者通常对特定类型企业中的部署（通常是预期在企业范围使用RBAC模型的部署）了熟于心。因此，应用设计者并入到其应用中的JPS访问控制可以是基于角色的。相反，OAM提供的访问控制可以是企业范围的（通用的，而非对于任何特殊应用特定的），其在应用部署时被规定而非在应用设计时被规定。OAM提供的访问控制能以基于DAC的模型为基础，这允许委托策略管理。以单独且隔离的方式实施两种类型的系统可能是对系统资源的浪费和重复劳动。 

发明内容

这里公开了跨越所有应用维护全局策略的技术。这里公开一种全局策略模型。公开了使用消息应用编程接口（MAPI）来管理全局策略模型的技术。在一实施例中，包括被多个应用共享的规则的全局策略被定义。包括用于单独应用的规则的多个应用特定的策略被定义。基于全局策略和第一应用特定策略来判定第一应用是否被允许访问特定资源。基于全局策略和第二应用特定策略来判定第二应用是否被允许访问该特定资源。在一实施例中，一种设备包括用于定义包括被多个应用共享的规则的全局策略的装置。该设备包括用于定义包括用于单独应用的规则的多个应用特定策略的装置。该设备包括用于基于该全局策略和第一应用特定策略来判定第一应用是否被允许访问特定资源的装置。该设备包括用于基于该全局策略和第二应用特定策略来判定第二应用是否被允许访问该特定资源的装置。 

附图说明

图1是框图，示出根据本发明一实施例的包括全局策略的目录信息树（DIT）的示例。 

图2是流程图，示出根据本发明一实施例的在多个应用之间共享全局策略的示例性技术。 

图3是框图，示出根据本发明一实施例的可通过各种授权系统得到保护的各种真实世界资源的示例。 

图4是框图，示出根据本发明一实施例的公共授权框架的示例。 

图5是框图，示出根据本发明一实施例的公共策略管理框架的示例。 

图6是框图，示出根据本发明一实施例的公共决策引擎和运行时（runtime）框架的示例。 

图7是简化框图，示出可根据本发明一实施例使用的系统环境的组件。 

图8是可根据本发明的实施例使用的计算机系统的简化框图。 

具体实施方式

一种系统可包括多个应用。这些应用中的每个可被应用特定的安全策略（在系统中由策略对象表示）所掌控。在本发明一实施例中，至少一些安全策略对象可以跨多个应用被共享。这些对象在所有应用中都是有效的。这种共享简化了多应用环境中的策略定义。在本发明一实施例中，使用了应用级决策合并算法技术。该技术可用作可扩展访问控制标记语言（XACML）3.0标准的扩展。 

图3是框图，示出根据本发明一实施例可通过各种授权系统保护的各种真实世界资源的示例。企业300可包括受保护资源306-312。企业300可包括网络302，用户可通过网络302请求对资源306-312的访问。企业300可包括授权单元304，其存储多个不同的授权策略（在图3中由不同的几何形状表示）。如图3所示，资源306-312中的不同资源可以通过认证单元304所维护的不同授权策略或授权策略的组合来得到保护。授权单元304可提供对关于去也300中的所有数 据资源诸如资源306-312的用户请求的集中统一管理。这种用户请求可包括例如读取、写入、拷贝、删除、或其他数据检索或操纵请求。响应于访问资源306-312中的任何资源的用户请求，授权单元304可以接收该请求并且确定授权单元304所存储的潜在若干授权策略中的哪些应用到该资源。在图3所示的示例中，多个授权策略可应用于资源306和312。不论单个还是多个授权策略应用到所请求的资源，授权单元304都可以从其统一企业范围策略存储中选择应用到该资源的所有授权策略。然后，授权单元304可以基于所选择的应用到该资源的一个或多个策略来判定用户是否被授权在请求所指定的资源上执行请求所指定的一个或多个动作。授权单元304可以基于该判决允许或拒绝用户的请求。 

图4是框图，示出根据本发明一实施例的公共认证框架400的示例。与图4所示的那些组件相比，本发明的替选实施例可包括附加的、更少的、或者不同的组件。公共授权框架400可包括管理工具诸如X2（Oracle Identity Manager）管理工具402、FGA（Fine-Grained Authorization）管理工具404、以及JPS管理工具406。管理工具402、404和406中的每个都可以接口连接到相同的策略API422。策略API422是上述统一策略API的示例。FGA可以视为某种OAM授权环境。 

框架400还可包括身份（ID）管理模块408。在一实施例中，ID管理模块408可用于创建和管理贯穿企业系统的身份。这种身份例如可以是用户身份。ID管理模块408可以与身份（ID）储存器412接口连接。ID储存器412可用作利用ID管理模块408创建的身份的储存库。ID储存器412也可以与策略API422接口连接。 

框架400还可包括角色储存器424。在一实施例中，角色储存器424可用作企业系统内已经创建的角色的储存库。身份可以被分配给角色，角色可以被分配给权限。以此方式，应当具有同种权限的多个用户可以被分配给相同角色，其又可被分配为具有那些权限。例如，“管理员”角色可与一组指定的权限相关联，应具有那些权限的所有用户的身份可以与“管理员”角色相关联。身份、角色和权限之间的 关联可以在角色储存器424内维护。角色储存器424也可以与策略API422接口连接。 

框架400还可包括用于各种不同种类的安全环境的策略实施点（PEP）。例如，框架400可包括FGA PEP410和XACML PEP420。这些PEP集合中的每个可以与访问赋权服务器（access entitlement server）426接口连接。访问赋权服务器426可包括用于多个不同类型的PEP的多个类型的接口。访问赋权服务器426可包括决策引擎428。决策引擎428是上述统一策略决策引擎的示例。通过访问赋权服务器426，FGA PEP 410和XACML PEP 420可以访问决策引擎428以判定所指定的访问请求是否满足所指定的策略。决策引擎428可以进行这种判定并且将判定结果返回到FGA PEP410和XACML PEP 420。然后，FGA PEP 410和XACML PEP 420可以通过准许或拒绝对所请求的资源的访问来执行决策引擎428所做出的判定。在一实施例中，决策引擎428能够评估上述规范策略格式中指定的策略。结果，决策引擎428能够评估包括来自不同类型授权环境（例如JPS、OAM等）的特征的策略，甚至能评估包括来自多种不同类型的授权环境的组合的特征的策略。在一实施例中，访问赋权服务器426还可以与ID储存器412接口连接以获得身份信息，其可以用于判定具有指定身份的用户是否应当被准许访问指定资源。 

框架400还可包括JPS应用客户端412。JPS应用客户端412例如可以利用JAVA编程语言实现。JPS应用客户端412可以使用JPS作为授权环境。这可以不同于FGA PEP 410和XACML PEP 420使用的授权环境种类。因此，框架400内使用的授权环境可以在本质上是异构的。JPS应用客户端可以与JAVA认证和授权服务（JAAS）的扩展版本（在框架400中示为JAAS扩展模块414）接口连接。JAAS扩展模块414可以包括FGA提供者416和决策引擎418。类似于决策引擎428，决策引擎418是上述统一策略决策引擎的示例。实际上，在一实施例中，决策引擎418和决策引擎428可以是同一决策引擎的单独实例（即，具有相同的代码基础（code base））。FGA提供者 416可以按与FGA PEP 410与访问赋权服务器426接口连接的方式类似的方式与访问赋权服务器426接口连接。在一实施例中，JAAS扩展模块414也可以与ID储存器412接口连接。 

根据一实施例，JAAS扩展模块414可以定义具有可选的输入主体、资源、动作和环境属性的用于完全细粒决策的基础权限类；以及包括访问决策（例如，允许、拒绝、不确定、不适用）的输出结果；状态信息；和可选的指定义务。JAAS扩展模块可以是标准JAAS的扩展版本，其为用户认证方法提供登录支持，并且扩展JAVA权限机制以包括通过认证了的用户身份来授权。 

框架400还可包括企业角色管理器430。在一实施例中，企业角色管理器430包括用户接口，企业管理员可通过其来创建和管理企业系统内使用的角色。这样的角色可以储存在角色储存器424内，角色储存器424可以用作企业系统内定义的所有角色的储存库。值得注意的是，利用企业角色管理器430定义的角色可以在上述组件中的任何组件使用的策略中被引用，而与那些组件被设计来与之一起操作的特定种类的授权环境无关。 

框架400还可包括策略储存器432。策略储存器432是统一策略储存器的示例。策略储存器432可以经由API422访问，从而管理员可以利用管理工具402、404和406创建和管理策略。策略储存器432还可被决策引擎418和428访问，从而决策引擎418和428可以判定储存于其中的策略是否被通过FGA PEP 410、XACML PEP 420和JPS应用客户端412进来的访问请求所满足。注意，储存于策略储存器432中的策略可以以满足统一策略方案的规范格式储存。该统一策略方案可以被设计为容许多种不同授权环境以及它们的下层访问控制模型所处理的策略特征。例如，在一实施例中，策略储存器432可以储存具有见于MAC模型和DAC模型二者中的特征的策略。还例如，在一实施例中，策略储存器432可以储存具有见于ABAC模型和RBAX模型二者中的特征的策略。因为储存于策略储存器432中的策略可以指定不同种类的授权环境中使用的特征，所以本发明的某些实施例可以 允许设计为在各种授权环境内使用的PEP和应用使用同一框架400。 

此外，由于储存于策略储存器432中的策略可以指定见于各种不同种类的访问控制模型中的特征，所以储存于策略储存器432中的策略可以本质上是“混合型”的，从而单个策略可以指定见于多个不同访问控制模型中的特征。例如，满足规范策略格式的单个策略可以指定见于MAC、DAC、ABAC和RBAC模型中的每个中的特征。单个策略可包括基于角色的特征以及可委托特征（delegation-capable feature）。单个策略可包括见于JPS授权环境（但不一定见于OAM授权环境）的特征以及见于OAM授权环境（但不一定见于JPS授权环境）的特征。 

根据本发明一实施例，全局策略可以与应用特定策略（application-specific policy）共存于授权系统中。与全局策略不同，应用特定策略有可能仅应用到系统中的某些指定应用而非全部应用。在本发明一实施例中，全局策略在运行时存储在高速缓存中作为特殊应用。对于系统接收到的每个授权请求，系统可以搜索全局应用以寻找授予的角色。系统可以评估全局策略以用于授权决策。系统可以将基于全局策略做出的授权决策与基于应用策略评估做出的其他决策合并。这种合并可以利用否定优先（deny-override）算法技术实现。使用这种技术，“拒绝”决策推翻所有其他决策，不论该拒绝决策由全局策略还是应用策略产生。在一实施例中，共享的全局项（artifact）诸如全局资源类型可被所有应用访问。 

图5是框图，示出根据本发明一实施例的公共策略管理框架500的示例。与图5所示的那些组件相比，本发明的替选实施例可包括附加的、更少的、或者不同的组件。框架500可包括策略储存器590和ID储存器595。策略储存器590可以功能上相当于图3的策略储存器332。ID储存器595可以功能上相当于图3的ID储存器312。适应于各种不同类型授权环境的组件可以都与策略储存器590和ID储存器595接口连接并访问它们。例如，这样的组件可包括JPS应用管理接口502、FGA管理接口504、XACML导入/导出模块506、JPS应用 运行时530以及FGA运行时560。JPS应用管理接口502可以功能上相当于图3的JPS管理工具306。FGA管理接口504可以功能上相当于图3的FGA管理工具304。FGA运行时560可以包括图3的FGAPEP 310。JPS应用运行时530可以功能上相当于图3的JPS应用客户端312中的一个或多个。组件502、504、506、530和560中的每个可以适应于具有相关联的不同访问控制模型的不同授权环境。例如，FGA运行时560可以适应于OAM类型的授权环境，其具有见于OAM类型的授权环境中的访问控制模型所提供的特征，而JPS应用运行时530可以适应于JPS类型的授权环境，其具有见于JPS类型的授权环境中的访问控制模型所提供的特征。根据一实施例，即使这些组件可以遵守且适应异构授权环境，框架500也将允许这些组件中的全部利用同一策略储存器590和ID储存器595。 

在一实施例中，可以至少部分地归因于每个组件的可用于与储存器590和595接口连接的非公共API的实施而产生使用同一策略储存器590和ID储存器595的该能力。更特别地，每个组件可实施策略API以使得该组件与策略储存器590接口连接，且每个组件可实施用户/角色API以使得该组件与ID储存器595接口连接。如图5所示，JPS应用管理接口502可包括策略API 512；FGA管理接口504可包括策略API 514；XACML导入/导出模块506可包括策略API 516；JPS应用运行时可包括决策引擎532的实例，其可包括策略API 542；FGA运行时560可包括决策引擎562的实例，其可包括策略API 572。每个策略API 512、514、516、542和562可以是同一策略接口的单独实施，具有相同的方法签名、形式参数、以及返回类型。此外，如图5所示，JPS应用管理接口502可包括用户/角色API 522；FGA管理接口504可包括用户/角色API 524；XACML导入/导出模块506可包括用户/角色API 526；JPS应用运行时可包括决策引擎532的实例，其可包括用户/角色API 552；FGA运行时560可包括决策引擎562的实例，其可包括用户/角色API 582。每个用户/角色API 522、524、526、552和582可以是同一用户/角色接口的单独实施，具有相同的方法签 名、形式参数和返回类型。 

图6是框图，示出根据本发明一实施例的公共决策引擎和运行时框架600的示例。与图6所示的那些组件相比，本发明的替选实施例可以包括附加的、更少的、或不同的组件。框架600可包括XACML PEP 602、FGA PEP 604、JPS应用客户端606、JPS应用客户端608、FGA访问服务器630、远程JPS提供者628、本地/嵌入式扩展JAAS提供者632、以及策略储存器646。策略储存器646可以功能上相当于图3的策略储存器332。FGA访问服务器630可包括XACML监听器610、JAAS扩展远程方法调用（RMI）监听器612、JAAS扩展模块614、以及决策引擎624。决策引擎624可以功能上相当于图3的决策引擎328。远程JPS提供者628可包括JAAS扩展模块624和JAAS扩展远程方法调用（RMI）提供者626。JAAS扩展RMI提供者628可与JAAS扩展RMI监听器612接口连接。本地/嵌入式扩展JAAS提供者632可包括JAAS扩展模块634和决策引擎636。决策引擎636可以功能上相当于图3的决策引擎328。 

决策引擎624和636每个可包括情境管理器（context manager）：情境管理器616和638。决策引擎624和636每个可包括与决策引擎的情境管理器接口连接的决策内核：决策内核618和640。决策引擎624和636每个可包括与该决策引擎的决策内核接口连接的高速缓存管理器：高速缓存管理器620和642。决策引擎624和636每个可包括与该决策引擎的高速缓存管理器接口连接的策略API：策略API 622和644。策略API 632和644可以功能上相当于图3的策略API 322。策略API 632和644每个可以与策略储存器646接口连接。 

XACML PEP可与XACML监听器610接口连接。FGA PEP 604可与JAAS扩展RMI监听器612接口连接。JPS应用客户端606可以与JAAS扩展模块624接口连接。JPS应用客户端608可以与JAAS扩展模块634接口连接。于是，即使组件602、604、606和608能适应于具有不同访问控制模型的特征的不同授权环境，组件602、604、606和608中的每个也能基于储存于策略储存器646中的规范格式的 策略来执行授权功能。决策引擎624和636可以是能够评估这种规范格式策略的同一统一策略决策引擎的单独实例。 

根据本发明一实施例，全局策略是特殊种类的应用策略。全局策略可以用保留名称“GlobalPolicy”来标识。在一实施例中，全局策略的角色、资源类型、内建属性和内建函数是所有应用可见的，但是其他项不是。 

根据本发明一实施例，全局策略在任何其他应用的分发之前分发，因为应用中的策略改变可涉及全局改变。在特定模式（所谓的受控模式）中，应用被约束到安全模块。与这些安全模块相反，全局策略可以是用于所有应用的永久共享特殊应用。全局策略不需要被明确约束到安全模块。在一实施例中，策略分发机制（policy distribution mechanism）首先检测是否存在任何全局策略改变。如果存在全局策略改变，则该机制向全部应用分发全局策略改变。在另一模式（所谓的不受控模式）中，全局策略被扫描，然后策略改变被加载到运行时高速缓存中。 

这里公开了用于管理应用中使用的全局策略和全局策略项的技术。在一实施例中，MAPI可以被定制以实现该管理。该技术的实施方式可包括迁移（migration）。该技术的实施方式可包括对数据库方案的改变。 

根据本发明一实施例，一些新颖的条目类型可以被增加到应用策略以支持XACML 3.0。这样的条目类型可包括例如策略集合和策略建议（policy advice）。 

根据本发明一实施例，全局策略被高速缓存在运行时高速缓存中。这些全局策略可以在运行时事件到来时被更新。 

在本发明一实施例中，该系统防止了经由PolicyStore.createApplicationPolicy方法来创建全局策略。在某些实施例中，全局策略是内建条带（built-in stripe），其在安装或更新系统时创建。在这种条件下，如果保留名称“GlobalPolicy”在PolicyStore.createApplicationPolicy方法中传递，则 InvalidArgumentException将被抛出。 

在本发明一实施例中，系统防止了通过PolicyStore.deleteApplicationPolicy方法来删除全局策略。在该实施例中，如果保留名称“GlobalPolicy”在PolicyStore.deleteApplicationPolicy中传递，则InvalidArgumentException将被抛出。 

在本发明一实施例中，从策略储存器获得全局策略，策略储存器实施为PolicyStore对象。在一实施例中，PolicyStore对象的接口包括命名为getGlobalPolicy的方法，其可以被调用以获得PolicyStore对象中储存的全局策略。 

在本发明一实施例中，一种系统包括三个单独的策略储存器：可扩展标记语言（XML）策略储存器、轻量目录访问协议（LDAP）策略储存器、以及数据库策略储存器。根据一实施例，全局策略储存在所有三个这样的策略储存器中，并且可以从他们中的任何一个访问。 

在本发明一实施例中，全局策略角色可以用作用于所有应用的首要策略。利用XACML 3.0，全局角色可以用于规则（rule）和策略集合（policy set）中。应用可以重定义相同名称的角色，因为每个角色条目具有应用标识符以标识其范围。在一实施例中，系统防止了全局角色参与到应用范围内的角色层级（role hierarchy）中。在一实施例中，系统防止了GrantManager对象的授权方法使全局角色在应用范围中成为承授者。在一实施例中，系统防止全局角色成为应用角色映射策略的一部分。在一实施例中，如果全局角色正被用于所有应用中，则系统防止全局角色的级联删除（例如，使操作失败）。这样使得用户不会关于哪个应用已经被隐式改变感到困惑。在一实施例中，系统不会自动对改变了的应用执行分发，因为有可能用户正在改变应用而未准备对该应用执行分发。 

在本发明一实施例中，全局策略中定义的资源类型可以用于实例化所有应用中的资源或资源名称表达对象。全局资源类型可以与新创建的资源或资源名称表达（expression）一起用于权限集合、策略和角 色策略中。在一实施例中，系统防止应用重新定义相同名称的资源类型。如上所述，在一实施例中，如果任何应用中正在使用全局资源类型，则系统使级联删除该全局资源类型的尝试失败。在一实施例中，系统不会自动对改变了的应用进行分发，因为有可能用户正在改变应用而未准备对该应用执行分发。 

在本发明一实施例中，内建属性仅定义在全局策略中。应用本身不定义内建属性，而是替代地使用全局策略的属性。 

在本发明一实施例中，未内建的且定义在全局策略中的其他属性可以被所有应用使用。例如，如果应用基于具有资源属性的全局资源类型定义资源，那么当定义关于该资源的策略时可以使用全局属性。在一实施例中，如果任何应用具有相同名称的属性，则系统使创建全局属性的尝试失败。类似地，在一实施例中，如果全局策略具有相同名称的属性，则系统将使在应用中创建属性的尝试失败。在一实施例中，如果任何应用中正在使用全局属性，则系统使删除该属性的尝试失败。 

在本发明一实施例中，内建函数仅定义在全局策略中，而不在应用特定的策略中。应用本身不定义内建函数，而是代替地使用全局策略定义的内建函数。在一实施例中，系统防止不是内建函数但是定义于全局策略中的其他函数被所有应用访问。每个应用可具有其自己的应用特定的属性，其不是内建的。 

在本发明一实施例中，全局项诸如全局资源类型可以被删除。特定全局资源类型可以用在两个或更多应用中。在本发明一实施例中，关于一应用的全局资源类型的删除不导致关于任何其他应用的全局资源类型被删除。资源类型很少被删除。当资源类型被删除时，改变可能是破坏性的。在某些情况下，多个应用可以重复使用相同资源类型。这种情况下资源类型的删除将有效抹除所有应用中的所有策略和授权。在一实施例中，全局角色删除可通过创建“拒绝”全局角色策略来被仿真，同时等候对被删除的角色的引用的去除。 

在某些情况下，全局策略的方法可以被弃用。在本发明一实施例 中，对于弃用的全局策略方法，不抛出异常（exception）。这最小化了常规应用策略和全局应用策略之间的差异。全局策略可以被相同的常规应用策略实现（implementation）所管理。弃用的方法可以被隐藏以防止使用它们。 

在本发明一实施例中，全局项诸如全局资源类型可仅由具有足够查看权限的实体来访问。在一实施例中，系统管理员能够授予系统用户针对全局资源类型特定的查看权限。该特征可有助于防止未授权用户访问全局角色和其他全局项。在一实施例中，策略储存器管理员能够查看全局策略项。该能力可以通过权限方法内的逻辑来实施。例如，这样的逻辑可以是如下形式： 

if((perm.app.equals("GLOBAL")&&(perm.action.equals("VIEW"))return true。 

在一实施例中，全局策略也被管理策略保护，类似于管理策略保护普通的应用特定策略的方式。 

在一实施例中，全局策略可以按与普通的应用特定策略可以被审计的方式相同的方式被审计。 

在一实施例中，在新安装期间，针对安装创建全局策略。内建属性和函数可以在全局策略中创建。在升级安装期间，也针对安装创建全局策略。内建属性和函数可以创建在全局策略中。内建属性和函数被从所有应用去除，因为它们仅定义在全局策略中。用于数据库策略储存器和LDAP策略储存器的升级工具可以将策略储存器版本升级到表明全局策略得到支持的新值。在一实施例中，XML策略储存器没有策略储存器版本属性。 

一般地，XML策略储存器不用于大型策略数据或许多应用。因为XML数据管理器可经由“for循环”执行查询，所以当处理大数据时会出现性能问题。例如，如果有许多应用，删除资源类型会是耗时的操作，因为所有应用的资源（包括应用级和所有策略域级的）可能被搜索以寻找资源类型引用。 

在一实施例中，目录信息树（DIT）被修改以支持三种PolicyStore （XML、LDAP和数据库）中的每个中的GlobalPolicy对象。图1是框图，示出根据本发明一实施例的包括全局策略的DIT的示例。如图1所示，全局策略具有与普通应用“应用1”相同的DIT。全局策略由恒定名称“GlobalPolicy”标识。终端用户不需要知晓该文字，因为全局策略通过特殊方法getGlobalPolicy返回，这将在下面进一步详细地论述。 

在一实施例中，全局策略的策略项可以与所有应用共享。然而，这可能使MAPI维护引用关系变得复杂。在一替选实施例中，全局策略的角色、资源类型、内建属性和内建函数对于应用可见。在这样的替选实施例中，全局策略的其他方面对于应用不可见。 

在一实施例中，全局策略角色可以作为策略中的首要策略用于所有应用。在一实施例中，利用XACML 3.0，全局角色也可以用在规则和策略集合中。在一实施例中，系统防止全局角色参与到应用范围内的角色层级（role hierarchy）中。在一实施例中，系统防止GrantManager使全局角色成为应用范围中的承授者。在一实施例中，系统防止全局角色成为应用角色映射策略的一部分。每个PrincipalEntry对象可具有应用标识符，使得可以识别角色是否是全局的。因此，在一实施例中，全局角色和应用级角色二者可具有相同的名称。在一实施例中，如果任何应用中正在使用全局角色，则系统使级联删除全局角色的尝试失败。在一实施例中，系统不会自动对改变了的应用执行分发，因为有可能用户正在改变应用而未准备对该应用执行分发。 

在一实施例中，全局资源类型可在系统中的应用之间共享。全局资源类型可以由所有应用使用以在应用级定义资源和资源名称表达。全局资源类型可以与新创建的资源或资源名称表达一起用在权限集合、策略和角色策略中。由于资源类型不在任何其他地方单独使用，所以根据一实施例，当删除全局资源类型时，系统检查是否有全局资源类型定义的任何资源或资源名称表达。类似于权限集合和策略，另一些应用项无需被搜索。如果全局资源类型正被用于应用中，则系统 使删除尝试失败。 

在一实施例中，全局资源类型不具有与应用的资源类型相同的名称。因此，如果在任何应用中有相同名称的资源类型，则系统将防止创建全局资源类型。如果全局策略中已经定义了相同名称的资源类型，则系统将防止在应用中创建资源类型。 

在一实施例中，如果资源类型处于使用中，则系统防止其名称、动作、动作定界符以及isHierarchical属性被修改。该逻辑确保已有的修改方法对于全局策略有效。如果当前应用是GlobalPolicy，那么所有应用被搜索以检查是否有任何引用资源或资源名称表达。如果发现了引用资源或资源名称表达，那么可抛出带有资源或资源名称表达以及相关应用名称的异常。 

在一实施例中，当创建资源或资源名称表达时，系统可以检查该资源类型是否存在。为了支持全局资源类型，系统逻辑可以被增强以搜索当前应用策略和全局策略二者。因为全局资源类型可以用在所有应用中，所以该新方法不需要请求任何权限检查。如果一实体具有查询应用中的资源类型的权限，那么该实体被允许查询全局策略中的资源类型。当创建权限或策略或者类似的项时，方法ResourceTypeManagerImpl.getResourceTypeInTransaction可以被调用。因此，类似的逻辑可以被实施。资源类型可能存在的所有地方都被检查。 

在一些系统中，可以在创建ApplicationPolicy时创建内建属性。结果，每个应用具有其内建属性的拷贝。这可在策略储存器中导致冗余数据。在一实施例中，对于全局策略，所有内建属性可以创建在该全局策略中。普通应用将不需要储存其本身中的内建属性的拷贝。 

在一实施例中，为了获得内建属性，普通应用可使用ExtensionManager来在全局策略中找到它。在这些情况下不要求查看全局属性的权限。从用户的角度来看，内建属性完全从应用范围取得。在一实施例中，系统防止内建属性被ExtensionManager创建或删除。该行为对于全局内建属性有效。 

在一实施例中，在应用中创建属性导致系统检查在全局策略中是否有相同名称的属性；在全局策略中创建属性导致系统检查在任何应用中是否存在相同名称的属性。在一实施例中，删除全局属性导致系统检查该属性是否正被用于任何应用中。如果是，则系统导致删除操纵失败，并且抛出异常以表明哪里正在使用它。应用特定的属性可以被删除。 

在一实施例中，当策略被创建时，系统可以使属性生效。由于全局属性可以用在应用策略中，所以系统检查属性是否存在于全局策略和当前应用的策略二者中。 

在一些系统中，当ApplicationPolicy被创建时，创建内建函数。结果，每个应用具有内建函数的单独拷贝。这使得策略储存器中的数据是冗余的。在一实施例中，所有内建函数都被创建在全局策略中。普通应用不需要在其本身中储存内建函数的拷贝。 

在一实施例中，普通应用在获取内建函数时可以使用ExtensionManager以在全局策略中寻找该函数。在一实施例中，不需要查看全局函数的权限以执行该操作。从用户的角度看，内建函数完全从应用范围取得。 

在一些系统中，内建函数不能被ExtensionManager创建和删除。在一实施例中，ExtensionManager可以创建和删除全局内建函数。 

在一实施例中，PolicyStore对象包括新方法。接口示于下面。 

下面是该方法的使用的示例。 

JpsContextFactory ctxFact=JpsContextFactory.getContextFactory(); 

JpsContext ctx=ctxFact.getContext(); 

Policy Store ps=ctx.getService Instance(Policy Store.class); 

//Gets the global policy store 

ApplicationPolicy globalPolicy=ps.getGlobalPolicy(); 

//Gets entity managers from the global policy 

AppRole Manager globalRole Manager=globalPolicy.getAppRoleManager(); 

PolicyManager globalPolicy Manager=globalPolicy.getPolicyManager(); 

…… 

在一实施例中，一些已有方法可能被向系统添加全局策略所影响。在Map<String,ApplicationPolicy>中，方法getApplicationPolicies()不返回全局策略。在List<ApplicationPolicy>中，方法getApplicationPolicies(ApplicationPolicySearchQuery query)不返回针对任何查询的全局策略。在List<String>中，方法getConfiguredApplications()不返回全局策略名称。在ApplicationPolicy中，如果appId是“GlobalPolicy”的话，那么方法getApplicationPolicy(String appId)抛出InvalidArgumentException。在ApplicationPolicy中，如果appId是“GlobalPolicy”的话，那么方法createApplicationPolicy(String appId)抛出InvalidArgumentException。在ApplicationPolicy中，如果appId是“GlobalPolicy”的话，那么方法createApplicationPolicy(String appId,String displayName,String description)抛出InvalidArgumentException。如果appId是“GlobalPolicy”的话，那么方法deleteApplicationPolicy(String appId)抛出InvalidArgumentException。 

在一实施例中，从XML策略储存器到LDAP策略储存器或数据库策略储存器的迁移包括某些操作。全局策略在其他应用之前迁移，因为其他应用可能引用全局策略。全局策略不作为普通应用被创建或删除。全局策略项以特殊方式迁移。在一实施例中，全局策略在应用被迁移之前被创建在目的地策略储存器中。每个应用的内建属性和内 建函数在一实施例中不迁移，因为它们仅定义在全局策略中。 

在一实施例中，抛出PolicyStoreException的方法deleteAppRole(String name,boolean cascade)被改变。如果该方法运行在全局策略中且该角色正用于应用中，则该方法抛出新异常GlobalRoleInUseException，其扩展ApplicationRoleInUseException。 

在一实施例中，抛出PolicyStoreException的方法createRolePolicy(String name,String displayName,String description,List<AppRoleEntry>appRoleEntries,List<PrincipalEntry>principalEntries,PolicyRuleEntry rule,List<ResourceEntry>resourceNames,List<ResourceNameExpression>resourceNameExpressions)被改变。该方法检查appRoleEntry是否在相同应用中。如果否，那么该方法抛出InvalidArgumentException，其包含信息“全局角色XXX不能用在应用的RolePolicy中”。 

在一实施例中，抛出PolicyObjectAlreadyExistsException、PolicyStoreException的方法grant(Set<PrincipalEntry>principalEntries,CodeSourceEntry csEntry,String permissionSetName)被改变。如果PrincipalEntries之一是AppRoleEntry，那么该方法检查其是否在相应应用中。如果否，则该方法抛出InvalidArgumentException。 

在一实施例中，抛出InvalidArgumentException、PolicyObjectNotFoundException、PolicyStoreException的方法getAttribute(String attrName)的方法被改变。如果attrName为内建属性名称，则该方法在全局策略中找到它并将其返回。 

在一实施例中，抛出PolicyStoreException的方法getAttributes(AttributeSearchQuery query)被改变。该方法在当前应用和全局策略中执行查询两次，从来自全局策略的结果中滤除非内建属性，并且计算查询结果的并集（union）。 

在一实施例中，抛出InvalidArgumentException、PolicyObjectionNotFoundException、PolicyStoreException的方法 getFunction(String funcName)被改变。如果funcName是内建函数名称，那么该方法在全局策略中找到它并将其返回。 

在一实施例中，抛出InvalidArgumentException、PolicyStoreException的方法getFunction(FunctionSearchQuery query)被改变。该方法在当前应用中执行查询，并且然后计算在全局策略上运行的滤除了非内建函数之后的另一查询的结果的并集。 

在一实施例中，方法getResourceAttributes(EntryWithAttributes validationEntry,ExtensionManagerImpl extensionManager,JpsDataManager dataManager)被改变。该方法检查validationEntry中包含的属性是存在于全局策略中还是当前应用中。 

在一实施例中，抛出PolicyStoreException的方法createApplication(String name,String displayName,String description)被改变。该方法不创建内建属性和函数。这样的属性和函数替代地在安装或升级期间在策略储存器中增殖。 

在一实施例中，抛出InvalidArgumentException、PolicyObjectionAlreadyExistsException、PolicyObjectNotFoundException、PolicyStoreException的方法createResourceType(ResourceTypeEntry resourceTypeEntry)被改变。该方法被弃用，并且如果当前应用是全局策略则抛出PolicyStoreOperationNotAllowedException。 

在一实施例中，抛出InvalidArgumentException、PolicyStoreException的方法createResourceType(String name,String displayName,String description,List<String>actions,List<AttributeEntry<?extends DataType>>attrs,String delimiter)被改变。如果当前应用是全局策略，那么该方法搜索所有应用以确保不存在相同名称的资源类型。如果当前应用不是全局策略，那么该方法搜索全局策略以确保没有这样的相同名称全局资源类型。 

在一实施例中，抛出InvalidArgumentException、PolicyStoreException的方法createResourceType(String name,String  displayName,String description,List<String>actions,List<AttributeEntry<?extends DataType>>attrs,String delimiter,String resourceMatcherClass)被改变。如果当前应用是全局策略，那么该方法搜索全部应用以确保没有相同名称的资源类型存在。如果当前应用不是全局策略，那么该方法搜索全局策略以确保没有这样的相同名称全局资源类型。 

在一实施例中，抛出PolicyObjectNotFoundException、PolicyStoreOperationNotAllowedException、PolicyStoreException的方法deleteResourceType(EntryReference rtref,boolean cascadeDelete)被改变。由于该方法被弃用，所以如果当前应用是全局策略，则该方法抛出PolicyStoreOperationNotAllowedException。 

在一实施例中，抛出PolicyObjectNotFoundException、PolicyStoreOperationNotAllowedException、InvalidArgumentException、PolicyStoreException的方法deleteResourceType(String name,boolean cascade)被改变。如果当前应用是全局策略且如果有引用被应用中的资源或ResourceAction所使用，那么该方法抛出PolicyStoreOperationNotAllowedException。 

在一实施例中，抛出PolicyStoreException的方法ResourcePresent(String resourceType,JpsDataManager dataMgr)被改变。查询性能通过跨越所有应用和全局策略的特殊查询而得到改善。XML策略储存器可以通过迭代而被搜索。 

在一实施例中，抛出InvalidArgumentException、PolicyStoreOperationNotAllowedException、PolicyStoreException的方法modifyResourceType(ResourceTypeEntry resourceTypeEntry)被改变。该方法防止使用中的资源类型被修改。 

在一实施例中，MAPI被更新以禁止创建ATZ策略和授予全局策略中的权限。针对授权请求评估GlobalPolicy对象中定义的策略，包括isAccessAllowed和checkPermission。GlobalPolicy对象中定义的应用角色可以被检索，如果被授予给当前用户的话。GlobalPolicy对 象中定义的资源类型可以被应用从运行时高速缓存检索。GlobalPolicy对象中定义的属性可以被应用在运行时高速缓存中检索。在GlobalPolicy对象中定义的内建属性和内建函数定义于全部应用中。 

在一实施例中，GlobalPolicy对象在应用之前针对checkPermission和isAccessAllowed被评估。在AuthorizationServer对象的“queryAccess”、“queryPermissions”和“queryRoles”方法中，全局策略可以作为变量“appPolicy”获得。RuntimePolicy可以从全局策略获得。全局策略的“authEvalWorker”方法可以被调用。当前应用可以被查询。相同过程可以重复进行。所有结果可以被合并。 

在一实施例中，当评估用户具有的角色时，系统考虑全局策略中授予/拒绝的动态角色和授予的静态角色。全局角色不在应用角色的层级中。系统可以在评估应用角色之前或之后评估全局角色。 

在一实施例中，当评估isAccessAllowed时，系统可以在评估授权策略之前抓取全局角色以及应用角色。 

在一实施例中，对于checkPermission方法，决策被用权限评估。运行时引擎负责经由AuthorizationServer对象的方法queryPermissions找到所有权限。全局策略可被如上所述地评估。在该情况下没有决策合并。 

在一实施例中，对于isAccessAllowed方法，从全局策略和当前应用评估的两个决策经由否定优先被合并。也就是说，如果它们之一为TV_FALSE，那么结果是DENY；另外如果二者都是TV_TRUE，那么结果为PERMIT；另外如果二者都是TV_UNKNOWN，那么结果是DENY；否则，一个必为TV_UNKNOWN且另一个必为TV_TRUE，结果为PERMIT。以上逻辑可以实施在单独方法中。合并算法可以被插入到策略合并算法中。 

在一实施例中，在策略评估期间，资源属性可以被从策略来自的应用检索。例如，当评估全局策略中定义的角色策略时，资源属性可以从全局策略检索。 

在一实施例中，全局策略被高速缓存为PDPService对象的实例变 量。接口PDPServiceInternal具有命名为getGlobalPolicy的方法以返回全局策略实例。该实例在初始化PDPService时被加载。 

在一实施例中，运行时ResourceTypeManager对象当处于非全局应用的情境中时将全局资源类型纳入考虑。运行时ExtensionsManager对象当处于非全局应用的情境中时将全局策略中的全局属性以及内建属性和函数纳入考虑。运行时ApplicationRoleManager对象在处于非全局应用的情境中时将全局角色和全局角色策略纳入考虑。 

在一实施例中，抛出PolicyStoreException的方法getAllGrantedAppRoles(Collection<Principal>principals,Collection<JpsApplicationRole>AppRoles)被改变。如果角色不在全局策略中，那么该方法合并全局策略和应用策略的结果，否则返回全局策略的结果。 

在一实施例中，抛出PolicyStoreException的方法getGrantedStaticAppRoles(Collection<Principal>enterprisePrincipals,Collection<JpsApplicationRole>AppRoles)被改变。如果角色不在全局策略中，那么该方法合并全局策略和应用策略的结果，否则返回全局策略的结果。 

在一实施例中，抛出PolicyStoreException的方法getAllGrantedAppRolesFromEntUsersGroups Anonymous AuthenticatedRoles(List<Principal>entUsersAndGroups,List<JpsApplicationRole>anonymousAndAuthenticatedRoles)被改变。如果角色不在全局策略中，那么该方法合并全局策略和应用策略的结果，否则返回全局策略的结果。 

在一实施例中，抛出PolicyStoreException的方法getPolicies(Set<Principal>enterprisePrincipals,ResourceEntry resourceEntry)被改变。如果角色不在全局策略中，那么该方法合并全局策略和应用策略的结果，否则返回全局策略的结果。 

在一实施例中，方法rolePoliciesPresent()被改变。如果角色策略 不在全局策略中，或者如果全局策略和应用策略的结果中的任何一个都为真（true），那么该方法返回真，否则返回全局策略的结果。 

在一实施例中，抛出PolicyStoreException的方法getResourceType(String type)被改变。如果资源类型未见于当前应用中，那么该方法尝试在全局策略中找到它。 

在一实施例中，方法getFunction(String name)被改变。如果函数未见于当前应用中，那么该方法尝试在全局策略中找到它。如果见于全局策略中且其是内建函数，那么该方法返回所找到的函数，否则返回空（null）。 

在一实施例中，方法getSymbolTable()被改变。该方法返回新的SymbolTable对象，其包含当前应用中的所有声明（declaration）以及全局策略中的内建函数声明和所有属性声明。 

在一实施例中，方法ApplicationPolicyImpl(AbstractPDPService service,AppPolicyEntry appPolicyEntry)被改变。如果全局策略被支持且应用是非全局应用，那么AppRoleManagerImplWrapper代替AppRoleManagerImpl被使用，ResourceTypeManagerImplWrapper代替ResourceTypeManagerImpl被使用，且ExtensionManagerImplWrapper代替ExtensionsManagerImpl被使用。 

在一实施例中，方法getAppID()被改变。该方法返回策略属于的应用的appID。 

在一实施例中，方法queryRoles(String strSession,String strObjectName,AttributeSet inputAttributes,ArrayList<JpsApplicationRole>rolesArrayList,LongHolder timeout,ExtendedContext context)被改变。运行时实体管理器被改变以考虑全局项。对该方法进行改变以返回来自全局策略和应用二者的角色。当评估角色策略时，该方法可以根据角色策略属于全局策略还是应用策略而使用不同的EvalSession。EvalSession包含runtimeResource。runtimeResource包含可用于评估角色策略的条件的资源属性。资源 属性可以从定义角色策略的应用获得。 

在一实施例中，方法getGlobalPolicy()被增加。该方法返回来自运行时高速缓存的全局策略实例。 

图2是流程图，示出根据本发明一实施例在多个应用之间共享全局策略的示例性技术。在框202，全局策略被定义且储存在运行时高速缓存中。全局策略包括可用于执行授权的安全策略对象，诸如允许或拒绝一实体访问资源。在框204，针对多个单独的应用定义多个单独的应用策略。每个应用策略包括应用特定的安全策略对象，其可用于执行授权，诸如允许或拒绝一实体访问资源。 

在框206，从第一应用接收到访问特定资源的请求。在框208，判定储存在全局策略中的规则是否允许具有第一应用的属性的应用访问该特定资源。如果允许，则控制进行到框210。否则，控制进行到框214。 

在框210，判定储存在该第一应用特定的应用级策略中的规则是否允许该第一应用访问该特定资源。如果允许，那么控制进行到框212。否则，控制进行到框214。 

在框212，第一应用被允许访问该特定资源。控制进行到框226。 

替选地，在框214，第一应用被拒绝访问该特定资源。控制进行到框226。 

在框226，从第二应用接收到访问该特定资源的请求。在框228，判定储存在全局策略中的规则是否允许具有该第二应用的属性的应用访问该特定资源。如果允许，那么控制进行到框230。否则，控制进行到框234。 

在框232，第二应用被允许访问该特定资源。控制回到框206。 

替选地，在框234，第二应用被拒绝访问该特定资源。控制进行到框206。 

图7是简化框图，示出可根据本发明一实施例使用的系统环境700的组件。如图所示，系统环境700包括一个或更多客户端计算设备702、704、706、708，其配置为运行客户端应用，包括本地客户端应用以及 可能诸如网络浏览器等的其他应用。在各种实施例中，客户端计算设备702、704、706和708可以与服务器712交互。 

客户端计算设备702、704、706、708可以是通用个人计算机（作为示例，包括运行各种版本的Microsoft Windows和/或Apple Macintosh操作系统的个人计算机和/或膝上型计算机）、蜂窝电话或PAD（运行诸如Microsoft Windows Mobile的软件，并且启用了因特网、电子邮件、SMS、Blackberry、或其他通信协议）、和/或运行各种商业可得的UNIX或类UNIX操作系统（包括但不限于各种GNU/Linux操作系统）中的任何操作系统的工作站计算机。替选地，客户端计算设备702、704、706和708可以是任何其他电子设备，诸如瘦客户端计算机、启用因特网的游戏系统、和/或能够经由网络（例如，下面描述的网络710）通信的个人消息设备。尽管示例性系统环境700示为具有四个客户端计算设备，但是任何数量的客户端计算设备都可得到支持。其他设备诸如具有传感器等的设备可以与服务器712交互。 

系统环境700可包括网络710。网络710可以是本领域技术人员熟知的可以支持使用各种商业可得的协议中的任何协议的数据通信的任何类型的网络，所述协议包括但不限于TCP/IP、SNA、IPX、AppleTalk等。仅作为示例，网络710可以是局域网（LAN）诸如以太网、令牌环网络等；广域网；虚拟网络，包括但不限于虚拟个人网络；因特网；内联网；外联网；公共开关电话网络（PSTN）；红外网络；无线网络（例如，在本领域已知的IEEE 802.11协议套件、蓝牙协议和/或任何其他无线协议中的任何一种下运行的网络）；和/或这些和/或其他网络的任意组合。 

系统环境700还包括一个或更多服务器计算机712，其可以是通用计算机、专用服务器计算机（作为示例，包括PC服务器、UNIX服务器、中端（mid-range）服务器、主框架（mainframe）计算机、机架安装服务器等）、服务器群组、服务器集群、或者任何其他适当的布置和/或组合。在各种实施例中，服务器712可适用于运行一个或更 多服务或软件应用。 

服务器712可以运行操作系统，包括上述那些以及任何商业可得的服务器操作系统中的任何操作系统。服务器712还可以运行各种附加服务器应用和/或中间层（mid-tier）应用中的任何应用，包括HTTP服务器、FTP服务器、CGI服务器、JAVA服务器、数据库服务器等。示例性数据库服务器包括但不限于可以从Oracle、Microsoft、Sybase、IBM等商业购买的那些。 

系统环境700还可包括一个或更多数据库714、716。数据库714、716可局域各种位置。作为示例，数据库714、716中的一个或更多可以居于服务器712本地（或位于其中）的非暂时性储存介质上。替选地，数据库714、716可以远离服务器712，通过基于网络的连接或专用连接与服务器712通信。在一些实施例中，数据库714、716可以位于本领域技术人员熟知的储存区域网络（SAN）中。类似地，根据需要，用于执行服务器712的功能的任何必要文件可以本地储存在服务器712上和/或远程储存。在一些实施例中，数据库714、716可包括关系数据库，诸如Oracle提供的数据库，其适用于响应于SQL格式的命令而储存、更新和检索数据。 

图8是可以根据本发明的实施例使用的计算机系统800的简化框图。例如，服务器712或者客户端702、704、706或708可以利用诸如系统800的系统实现。计算机系统800示为包括可经由总线824电耦合的硬件元件。硬件元件可包括一个或更多中央处理单元（CPU）802、一个或更多输入设备804（例如鼠标、键盘等）、以及一个或更多输出设备806（例如显示设备、打印机等）。计算机系统800还可包括一个或更多储存设备808。作为示例，储存设备808可包括诸如盘驱动器、光学储存设备、以及固态储存设备（诸如随机存取存储器（RAM）和/或只读存储器（ROM），其可以是可编程的、闪速可更新的）等之类的设备。 

计算机系统800还可包括计算机可读储存介质读取器812、通信子系统814（例如调制解调器、网络卡（无线或有线的）、红外通信设 备等）、以及工作存储器818，其可包括上述RAM和ROM设备。在一些实施例中，计算机系统800还可包括处理加速单元816，其可包括数字信号处理器（DSP）、特殊目的处理器等。 

计算机可读储存介质读取器812可进一步连接到计算机可读储存介质810，一起（并且，可选地，结合储存设备808）全面地代表远程、本地、固定和/或可移动储存设备加储存介质，以用于暂时和/或更长久地容纳计算机可读信息。通信系统814可允许与网络710和/或上面关于系统环境700描述的任何其他计算机进行数据交换。 

计算机系统800还可包括软件元件，示为当前位于工作存储器818内，包括操作系统820和/其他代码822，诸如应用程序（其可以是客户端应用、网络浏览器、中间层应用、RDBMS等）。在一示范性实施例中，工作存储器818可包括用于上述授权处理的可执行代码和相关数据结构。应理解，计算机系统800的替选实施例可具有上述内容的许多变型。例如，亦可使用定制硬件和/或特定元件可以实现在硬件、软件（包括便携式软件，诸如小应用）、或者二者中。此外，可以采用到其他计算设备诸如网络输入/输出设备的连接。 

用于容纳代码或部分代码的储存介质和计算机可读介质可包括本领域已知或使用的任何适当介质，包括储存介质和通信介质，例如但不限于在用于储存和/或信息（诸如计算机可读指令、数据结构、程序模块、或其他数据）的传输的任何方法或技术中实现的易失性和非易失性（非暂时性）、移动或非移动介质介质，包括RAM、ROM、EEPROM、闪存或其他存储技术、CD-ROM、数字万用盘（DVD）或其他光学储存器、磁带卡、磁带、磁盘储存器或其他磁储存设备、数据信号、数据传输、或能用于储存或传输期望信息且能被计算机访问的任何其他介质。 

尽管已经描述了本发明的特定实施例，但是各种修改、替换、替选构造、以及等价物也包含在本发明的范围内。本发明的实施例不限于特定的具体数据处理环境中的操作，而是自由操作于多种数据处理环境中。此外，尽管已经利用一系列特定的处理和步骤描述了本发明 的实施例，但是对于本领域技术人员而言显然的是，本发明的范围不限于所描述的一系列处理和步骤。 

此外，虽然已经利用硬件和软件的特定组合描述了本发明的实施例，但是应理解，硬件和软件的其他组合也在本发明的范围内。本发明的实施例可以仅以硬件实现，仅以软件实现，或者利用其组合实现。 

因此，说明书和附图应视为仅是示范性的，而不是限制性的。然而将显然的是，可以对其进行增加、削减、删除以及其他修改和变化而不偏离较宽的思想和范围。 

Claims (10)

1.一种计算机实施的方法，包括：

定义全局策略，其包括由多个应用共享的规则；

定义多个应用特定策略，其包括用于个体应用的规则；

基于所述全局策略和第一应用特定策略判定第一应用是否被允许访问特定资源；以及

基于所述全局策略和第二应用特定策略判定第二应用是否被允许访问所述特定资源。

2.如权利要求1所述的计算机实施的方法，还包括：

响应于判定所述全局策略或所述第一应用特定策略不允许所述第一应用访问所述特定资源，拒绝所述第一应用访问所述特定资源。

3.如权利要求1或2所述的计算机实施的方法，还包括：

响应于判定所述全局策略或所述第二应用特定策略不允许所述第二应用访问所述特定资源，拒绝所述第二应用访问所述特定资源。

4.如权利要求1所述的计算机实施的方法，还包括：

响应于判定所述全局策略和所述第一应用特定策略二者都允许所述第一应用访问所述特定资源，允许所述第一应用访问所述特定资源。

5.如权利要求1或4所述的计算机实施的方法，还包括：

响应于判定所述全局策略和所述第二应用特定策略二者都允许所述第二应用访问所述特定资源，允许所述第二应用访问所述特定资源。

6.一种设备，包括：

用于定义全局策略的装置，该全局策略包括由多个应用共享的规则；

用于定义多个应用特定策略的装置，该应用特定策略包括用于个体应用的规则；

用于基于所述全局策略和第一应用特定策略判定第一应用是否被允许访问特定资源的装置；以及

用于基于所述全局策略和第二应用特定策略判定第二应用是否被允许访问所述特定资源的装置。

7.如权利要求6所述的设备，还包括：

用于响应于判定所述全局策略或所述第一应用特定策略不允许所述第一应用访问所述特定资源，拒绝所述第一应用访问所述特定资源的装置。

8.如权利要求6或7所述的设备，还包括：

用于响应于判定所述全局策略或所述第二应用特定策略不允许所述第二应用访问所述特定资源，拒绝所述第二应用访问所述特定资源的装置。

9.如权利要求6所述的设备，还包括：

用于响应于判定所述全局策略和所述第一应用特定策略二者都允许所述第一应用访问所述特定资源，允许所述第一应用访问所述特定资源的装置。

10.如权利要求6或9所述的设备，还包括：

用于响应于判定所述全局策略和所述第二应用特定策略二者都允许所述第二应用访问所述特定资源，允许所述第二应用访问所述特定资源的装置。