控制权限的委托

摘要

权限的委托可按照多种方式来控制。在一示例实现中，委托授权机构断言是用委托方主体、被委托方主体、动词短语、资源和委托指示动词来制定的。在另一示例实现中，涉及断言者、第一主体和第二主体的委托机制使委托能被具体控制。在又一示例实现中，连锁委托机制允许对许可的传递链接深度的显式控制。

说明书

背景

计算机和其他电子设备遍布人们的职业和个人生活。在职业设置中，人们在项目协作期间交换和共享机密信息。在个人设置中，人们参与电子商务以及个人信息的传输。在这些和其他众多情况中，电子安全措施被认为是重要的。

电子安全措施范例可令职业信息保持机密以及个人信息保持私密。电子安全措施范例可涉及某种水平的加密和/或针对诸如病毒、蠕虫和间谍软件等恶意软件的保护。信息的加密以及针对恶意软件的保护历来受到极大的关注，尤其是近几年来。

然而，控制对信息的访问是保护电子信息安全性同等重要的方面。对于其中受益于电子信息的共享和/或传送的情形尤其如此。在这样的情形中，某些人被准许访问，而其他人要被排除在外。

访问控制自早期的共享系统以来就是共享计算机和应用程序服务器的共同特征。存在用于控制对信息的访问的多种不同的方法。它们在组合对请求对某一资源的访问的实体的认证以及授权所允许的访问的机制方面享有共同的基础。认证机制包括口令、Kerberos、以及x.509证书。其目的在于允许进行资源控制的实体肯定地标识进行请求的实体或它所需的关于实体的信息。

授权示例包括访问控制列表(ACL)以及基于策略的机制，诸如可扩展访问控制标记语言(XACML)或特权和角色管理基础架构(PERMIS)。这些机制定义哪些实体可访问给定的资源，诸如文件系统中的文件、硬件设备、数据库信息等。它们通过提供关于请求者的认证信息以及所允许的对资源的访问之间的映射来执行这种授权。

随着计算机系统越来越普遍地连接到诸如因特网等大型网络上，这些机制被证实在处理日益发展的访问控制要求方面稍有限制和不灵活。地理上散布的用户和计算机资源的系统，包括横跨多个行政区域的那些系统尤其提出了当前部署的技术解决不好的多个挑战。

概述

权限的委托可按照多种方式来控制。在一示例实现中，委托授权机构断言是用委托方主体、被委托方主体、动词短语、资源和委托指示动词来制定的。在另一示例实现中，涉及断言者、第一主体和第二主体的委托机制使委托能被具体控制。在又一示例实现中，连锁委托机制允许对许可的传递连锁深度的显式控制。

提供本概述以便以简化的形式介绍将在以下详细描述中进一步描述的一些概念。该概述不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。而且，其它方法、系统、方案、装置、设备、介质、过程、API、安排、协议等的实现也在此得到描述。

附图简述

在各图中使用相同的数字来引用相同和/或对应的方面、特征和组件。

图1是示出其中可以实现示例安全方案的示例一般环境的框图。

图2是示出具有两个设备以及多个示例安全相关组件的示例安全环境的框图。

图3是示出其中在安全相关组件之间交换示例安全相关数据的图2的示例安全环境的框图。

图4是可用于本文所述的安全相关实现的示例设备的框图。

图5是示出用于一般安全方案的示例断言格式的框图。

图6是从功能观点示出示例委托机制以及示例委托情形并包括委托授权机构断言的框图。

图7是从逻辑观点示出示例委托机制以及示例委托类型的框图。

图8是示出委托机制的委托授权机构断言的示例断言格式的框图。

图9是从功能观点示出示例连锁委托机制以及示例连锁委托情形的框图。

图10是示出连锁委托机制的两个示例格式方法的框图。

图11是示出用于创建委托授权机构断言的方法的示例的流程图。

详细描述

示例安全环境

图1是示出其中可以实现示例安全方案100的示例一般环境的框图。安全方案100表示进行保护的集成方法。如图所示，安全方案100包括多个安全概念：安全令牌100(A)、安全策略100(B)、以及求值引擎100(C)。一般，安全令牌100(A)、安全策略100(B)共同提供对求值引擎100(C)的输入。求值引擎100(C)接受输入，并产生指示应许可还是拒绝对某一资源的访问的授权输出。

在所述实现中，安全方案100可由一个或多个设备102覆盖和/或与其集成，这些设备由硬件、软件、固件、其某种组合等组成。如图所示，“d”个设备在一个或多个网络104上互连，“d”是某一整数。更具体地，设备102(1)、设备102(2)、设备102(3)...设备102(d)能够经由网络104通信。

每一设备102可以是能够实现安全方案100的至少一部分的任何设备。这样的设备的示例包括但不限于：计算机(例如，客户机计算机、服务器计算机、个人计算机、工作站、台式机、膝上型计算机、掌上型计算机等)、游戏机(例如，控制台、便携式游戏设备等)、机顶盒、电视机、消费电子产品(例如，DVD播放器/记录器、摄录像一体机、数码录像机(DVR)等)、个人数字助理(PDA)、移动电话、便携式媒体播放器、其某种组合等。一个示例电子设备在以下具体参考图4描述。

网络104可由链接在一起和/或覆盖在彼此之上的任何一个或多个网络形成。网络104的示例包括但不限于：因特网、电话网络、以太网、局域网(LAN)、广域网(WAN)、有线电视网络、光纤网络、数字用户线(DSL)网络、蜂窝网络、网络、网络、虚拟专用网(VPN)、其某种组合等。网络104可包括多个域、一个或多个网格网络等。这些网络或网络组合中的每一个可根据任何联网标准操作。

如图所示，设备102(1)对应于正与之交互的用户106。设备102(2)对应于正在其上执行的服务108。设备102(3)与资源110相关联。资源110可以是设备102(3)的一部分，或与设备102(3)分开。

用户106、服务108以及诸如任何给定设备102等机器形成非穷举的示例实体列表。实体随时可能希望访问资源110。安全方案100确保被正确认证和授权的实体被许可访问资源110，而阻止其他实体访问资源110。

图2是示出具有两个设备102(A)和102(B)以及多个示例安全相关组件的示例安全环境200的框图。安全环境200还包括授权机构202，诸如安全令牌服务(STS)授权机构。设备102(A)对应于实体208。设备102(B)与资源110相关联。尽管安全方案100可在更复杂的环境中实现，但使用该相对简单的两个设备的安全环境200来描述示例安全相关组件。

如图所示，设备102(A)包括两个安全相关组件：安全令牌204和应用程序210。安全令牌204包括一个或多个断言206。设备102(B)包括五个安全相关组件：授权上下文212、资源保卫214、审计日志216、授权引擎218和安全策略220。安全策略220包括信任和授权策略222、授权查询表224和审计策略226。

每一设备102可被不同地配置，且仍能够实现安全方案100的全部或一部分。例如，设备102(A)可具有多个安全令牌204和/或应用程序210。作为另一示例，设备102(B)可不包括审计日志216或审计策略226。其它配置也是可能的。

在所述实现中，授权机构202向实体208发放具有断言206的安全令牌204。断言206在以下描述，包括在题为“安全策略断言语言示例特征”一节中。实体208从而与安全令牌204相关联。在操作中，实体208希望依靠安全令牌204使用应用程序210来访问资源110。

资源保卫214接收访问资源110的请求，并有效地管理与设备102(B)的其他安全相关组件的认证和授权过程。如其名所指示，信任和授权策略222包括针对在安全环境200内信任实体和授权动作的策略。信任和授权策略222可例如包括安全策略断言(未在图2明确示出)。授权查询表224将诸如访问请求等所请求的动作映射到适当的授权查询。审计策略226描绘与在安全环境200中实现安全方案100有关的审计责任和审计任务。

授权上下文212从安全令牌204收集断言206，它用于认证进行请求的实体，授权上下文212还从信任和授权策略222收集安全策略断言。这些收集的断言在授权上下文212中形成断言上下文。因此，授权上下文212可包括除各种断言以外的其他信息。

来自授权上下文212的断言上下文和来自授权查询表224的授权查询被提供给授权引擎218。使用断言上下文和授权查询，授权引擎218作出授权决策。资源保卫214基于授权决策而响应访问请求。审计日志216包含审计信息，诸如所请求的资源110的标识和/或由授权引擎218执行的算法求值逻辑。

图3是示出其中在安全相关组件之间交换示例安全相关数据的示例安全环境200的框图。交换安全相关数据以支持示例访问请求操作。在此示例访问请求操作中，实体208希望使用应用程序210访问资源110，并用安全令牌204指示其这样做的授权。因此，应用程序210向资源保卫214发送访问请求*。在图3的该描述中，星号(即“*”)指示所述安全相关数据在图3中明确示出。

在所述实现中，实体208用令牌*——安全令牌204向资源保卫214认证*它自己。资源保卫214将该令牌断言*转发到授权上下文212。这些令牌断言是安全令牌204的断言206(图2)。安全策略220向资源保卫214提供授权查询表*。授权查询表是从授权查询表模块224得到的。发送到资源保卫214的授权查询表可被限于与当前访问请求直接相关的一个或多个部分。

策略断言是由安全策略220从信任和授权策略222提取的。策略断言可包括信任相关断言和授权相关断言两者。安全策略220将策略断言*转发到授权上下文212。授权上下文212将令牌断言和策略断言组合成断言上下文。如由带圈的“A”所示，从授权上下文212向授权引擎218提供断言上下文*。

根据授权查询表查明授权查询。资源保卫214向授权引擎218提供授权查询(授权查询*)。授权引擎218在求值算法中使用授权查询和断言上下文来产生授权决策。授权决策(授权决策*)被返回给资源保卫214。实体208是否被资源保卫214准许访问*资源110取决于该授权决策。如果授权决策是肯定的，则访问被准许。另一方面，如果由授权引擎218发出的授权决策是否定的，则资源保卫214不准许实体208访问资源110。

授权过程还可使用补充授权过程的语义来审计。审计可能需要监视授权过程和/或存储如授权引擎218逻辑地执行的求值算法等任何中间和/或最终产品。为此，安全策略220向授权引擎218提供来自审计策略226的审计策略*。至少当请求审计时，可从授权引擎218向审计日志216转发含有审计信息的审计记录*。或者，审计信息可经由资源保卫214例如作为授权决策的一部分或单独地路由到审计日志216。

图4是可用于本文所述的安全相关实现的示例设备102的框图。多个设备102能够跨一个或多个网络104通信。如图所示，两个设备102(A/B)和102(d)能够经由网络104参与通信交换。尽管具体示出两个设备102，但是也可以取决于实现利用一个或多于两个设备102。

一般而言，设备102可标识任何计算机或能够进行处理的设备，诸如客户机或服务器设备；工作站或其他通用计算机设备；PDA；移动电话；游戏平台；娱乐设备；以上参考图1列出的设备之一；其某种组合等。如图所示，设备102包括一个或多个输入/输出(I/O)接口404、至少一个处理器406以及一个或多个介质408。介质408包含处理器可执行指令410。

在所述设备102的实现中，I/O接口404可包括(i)用于跨网络104通信的网络接口，(ii)用于在显示屏上显示信息的显示设备接口，(iii)一个或多个人机接口等。(i)网络接口的示例包括网卡、调制解调器、一个或多个端口等。(ii)显示设备接口的示例包括图形驱动器、显卡、屏幕或监视器的硬件或软件驱动器等。打印设备接口可类似地作为I/O接口404的一部分被包括。(iii)人机接口的示例包括那些以有线或无线方式与人机接口设备402(例如，键盘、遥控器、鼠标或其他图形定点设备等)通信的接口。

通常，处理器406能够执行、运行、和/或以其它方式实现诸如处理器可执行指令410等处理器可执行指令。介质408由一个或多个处理器可访问介质组成。换言之，介质408可包括可由处理器406执行以由设备102实现功能的执行的处理器可执行指令410。

因此，安全相关实现的实行可以在处理器可执行指令的通用上下文中描述。一般而言，处理器可执行指令包括例程、程序、应用程序、代码、模块、协议、对象、组件、元数据及其定义、数据结构、应用程序编程接口(API)、模式等，它们执行和/或完成特定的任务，和/或实现特定的抽象数据类型。处理器可执行指令可以位于单独的存储介质中，由不同的处理器执行，和/或通过各种传输介质传播或存在于各种传输介质上。

处理器406可以使用任何适用的能进行处理的技术来实现。介质408可以是作为设备102的一部分被包括的和/或能被设备102访问的任何可用介质。其包括易失性和非易失性介质、可移动和不可移动介质以及存储和传输介质(例如，无线或有线通信信道)。例如，介质408可以包括用于处理器可执行指令410的长期大容量存储的磁盘/闪存/光介质阵列，用于当前正在执行的指令的短期存储的随机存取存储器(RAM)，用于传输通信(例如，安全相关数据)的网络104上的链路等。

如具体示出的，介质408至少包括处理器可执行指令410。一般而言，处理器可执行指令410在由处理器406执行时使设备102能执行本文所述的各种功能，包括在各个流程图中所示的那些动作。仅作为示例，处理器可执行指令410可包括安全令牌204、其断言206的至少其中之一、授权上下文模块212、资源保卫214、审计日志216、授权引擎218、安全策略220(例如，信任和授权策略222、授权查询表224和/或审计策略226等)，其某种组合等。尽管未在图4中明确示出，但处理器可执行指令410还可包括应用程序210和/或资源110。

安全策略断言语言示例特征

本节描述了安全策略断言语言(SecPAL)的实现的示例特征。本节的SecPAL实现是以相对非正式的方式描述的，且仅作为示例。它具有解决创建端对端解决方案时所涉及的大量安全策略和安全令牌职责的能力。作为示例而非限制，这些安全策略和安全令牌职责包括：描述显式信任关系；表达安全令牌发放策略；提供包含身份、属性、能力和/或委托策略的安全令牌；表达资源授权和委托策略等。

在所述实现中，SecPAL是用于以灵活且易处理的方式表达安全措施的声明性的基于逻辑的语言。它可以是综合的，且它可提供用于表达信任关系、授权策略、委托策略、身份和属性断言、能力断言、撤销、审计要求等的统一机制。该统一性在使安全方案可理解且可分析方面提供切实的好处。该统一机制还通过允许避免、至少显著减少不同安全技术之间的语义转换和调停的需求而提高安全保证。

SecPAL实现可包括以下示例特征的任何一个：[1]SecPAL可相对容易地理解。它可使用允许其断言作为英语语句阅读的定义句法。而且，其语法可以是限制性的，使其仅要求用户理解少数具有清楚定义的语义的主语-动词-宾语(例如，主语-动词短语)构造。最后，用于基于断言的集合对可推断事实求值的算法可依赖于少数相对简单的规则。

[2]SecPAL可在其实现中利用行业标准基础架构以便于其在现有系统中的采用和集成。例如，可使用可扩展标记语言(XML)句法，这是来自形式模型的直接映射。这允许使用标准语法分析器和句法正确性确认工具。它也允许对完整性、来源证明和机密性使用W3C XML数字签名和加密标准。

[3]SecPAL可通过支持分布式策略授权和合成而允许分布式策略管理。这允许灵活地适应不同的操作模型管控，其中基于所分派的管理责任来创作策略或策略的部分。使用标准方法来数字地签署和加密策略对象使其能够安全分发。[4]SecPAL允许高效且安全的求值。对输入的简单的句法检查足以确保求值将会终止并产生正确的答案。

[5]SecPAL可提供用于支持所要求的策略、授权决策、审计和用于身份管理的公钥基础架构(PKI)的访问控制要求的完整解决方案。相反，大多数其他方法仅能关注和解决这些安全问题范围内的一个子集。[6]SecPAL出于多个目的可以具有充分的表达力，这些目的包括但不限于：处理网格环境和其他类型的分布式系统的安全问题。以维护语言语义和求值性质同时允许适应特定系统的需求的方式来启用可扩展性。

图5是示出用于一般安全方案的示例断言格式500的框图。在本文其他部分描述的实现中使用的安全方案断言可以不同于示例断言格式500。然而，断言格式500是安全方案断言的一个示例格式的基本图示，且它提供理解一般安全方案的各个方面的所述示例实现的基础。

如在断言格式500的最上行所示，概况层的示例断言包括：主体(principal)部分502、说(say)部分504以及主张(claim)部分506。文字上，概括层的断言格式500可被表示为：主体说主张。

在断言格式500的下一行，主张部分506被分成示例组成部分。因此，示例主张部分506包括：事实(fact)部分508，如果(if)部分510，“n”个条件事实_1...n部分508(1...n)以及c部分512。下标“n”表示某一整数值。如图例524所示，c部分512表示约束部分。尽管仅示出单个约束，但c部分512实际上可表示多个约束(例如，c₁，...，c_m)。如果部分510右侧的条件事实部分508(1...n)和约束512(1...m)的集合可被称为前提。

文字上，主张部分506可表示为：事实如果事实₁，...事实_n，c。因此，整个断言格式500在文字上可如下表示：主体说如果事实₁，...事实_n，c，则事实。然而，断言可被简化为：主体说事实。在断言的这一缩写的三部分形式中，略去了以如果部分510开始并延及c部分512的条件部分。

每一事实部分508还可被细分成其各个组成部分。示例组成部分有：e部分514和动词短语部分516。如图例524所示，e部分514表示表达式部分。文字上，事实部分508可表示为：e动词短语。

每一e即表达式部分514可采用两个示例选择之一。这两个示例表达式选择是：常量514(c)和变量514(v)。主体可归入常量514(c)和/或变量514(v)。

每一动词短语部分516也可采用三个示例选择之一。这三个示例动词短语选择是：谓词部分518继之以一个或多个e_1...n部分514(1...n)、能够断言(canassert)部分520继之以事实部分508、以及别名部分522继之以表达式部分514。文字上，这三个动词短语选择分别可被表示为：谓词e₁...e_n、能够断言事实、以及别名e。整数“n”可对事实508(1...n)和表达式514(1...n)取不同的值。

一般，SecPAL语句是安全主体作出的断言形式的。安全主体一般由密钥标识，以使其可跨系统边界认证。在其最简单的形式中，断言陈述，主体相信事实是有效的(例如，如由包括事实部分508的主张506所表示)。他们也陈述，如果一个或多个其他事实有效且满足某组条件，则一事实有效(例如，如由从事实部分508延及如果部分510以及条件事实部分508(1...n)到c部分512的主张506所表示)。也可能存在没有任何约束512的条件事实508(1...n)和/或没有任何条件事实508(1...n)的约束512。

在所述实现中，事实是关于主体的陈述。在本节中此处描述了四种示例类型的事实陈述。首先，事实可陈述，主体具有用“动作动词”对资源行使动作的权利。示例动作动词包括但不限于：调用、发送、读取、列表、执行、写入、修改、追加、删除、安装、拥有等。资源可由统一资源指示符(URI)或任何其他方法标识。

其次，事实可使用“拥有”动词来表达主体标识符与一个或多个属性之间的绑定。示例属性包括但不限于：电子邮件名、通用名、组名、角色头衔、帐户名、域名服务器/服务(DNS)名、网际协议(IP)地址、设备名、应用程序名、组织名、服务名、帐户标识/标识符(ID)等。第三种示例类型的事实是可使用“别名”动词定义两个主体标识符来表示同一主体。

“限定词”或事实限定词可作为以上三种事实类型的任一种的一部分而被包括。限定词使得断言者能指示如果认为事实有效则它相信应成立的环境参数(例如，时间、主体位置等)。这样的陈述可基于这些限定词的值在断言者和依赖方的有效性检查之间清楚地分开。

第四种示例类型的事实由“能够断言”动词定义。这种“能够断言”动词提供用于表达信任关系和委托的灵活且强大的机制。例如，它允许一个主体(A)陈述其相信第二主体(B)断言的某些类型的事实的意愿。例如，给定断言“A说B能够断言事实()”以及“B说事实()”，可得到A相信事实()有效的结论从而可推断“A说事实()”。

这样的信任和委托断言可以是(i)无边界的且是传递的以许可下游委托，或者(ii)有边界的以阻止下游委托。尽管可对“能够断言”类型事实应用限定词，但对这些“能够断言”类型事实省略对限定词的支持可显著地简化给定安全方案的语义和求值安全性质。

在所述实现中，可陈述具体的事实，或可使用变量写出策略表达式。变量是类型化的，且可以是无限制的(例如，允许匹配正确类型的任何具体值)或有限制的(例如，要求基于指定的模式匹配具体值的子集)。

安全授权决策基于针对来自适用的安全策略(例如，安全策略220)和安全令牌(例如，一个或多个安全令牌204)的断言集合(例如，断言上下文)的授权查询的求值算法(例如，可在授权引擎218处进行的那些算法)。授权查询是组合事实和/或条件的逻辑表达式，其可能会变得相当复杂。这些逻辑表达式例如包括对事实的与、或和/或非逻辑运算，带有或不带有伴随的条件和/或约束。

该对授权查询的方法提供用于定义在对给定动作授权之前什么是必须已知且有效的灵活机制。查询模板(例如来自授权查询表224)形成总的安全方案的一部分，且允许对不同类型的访问请求和其他操作/动作声明性地陈述适当的授权查询。

用于控制权限的委托的示例实现

现代系统，尤其是分布式系统，通常在实体之间可委托权限时能更有效地起作用。这在各种功能情形中表明。示例情形包括但不限于：

·用户将其资源访问权限的某一部分委托给代表他们执行的应用程序的能力；

·管理员将其资源访问权限的某一部分委托给下属或同级的能力；以及

·执行的应用程序将其资源访问权限委托给另一应用程序的能力。

这些类型的委托一般应按照众多不同方式中的一种或多种来控制。例如，它们可仅在受限时间段内被允许，且它们可能需要被限于被委托方执行期望功能所需要的特定资源。对允许权限的下游委托的能力的有效控制也是有利的。换言之，被委托方将其被授予的访问权限的某些或全部进一步委托给下游可能是有利的。

现有系统对支持受控的委托提供的能力有限。在大多数系统中，限于允许运行的程序扮演用户。扮演表示被委托方行使委托方的全部访问权限的能力。至多，对这种扮演存在某种时间限制，但这一般是以小时计量的默认系统值，且不能在每一交互的基础上控制。 Kerberos实现还支持服务在代表用户处理请求时具有委托权限的能力。这允许服务将扮演用户的权限传递给另一服务，但它没有提供用于约束对这种能力的使用的有效控制。结果，这些现有系统的用户必须完全信任被委托方不会滥用其扮演权限。

网格(Grid)社区开发了基于X.509代理证书的委托方法。这些对控制委托提供的能力也非常有限。尽管它们确实允许对特定委托设置时间限制，但它们仍允许被委托方在作出访问请求时使用委托方的身份和属性。定义代理证书的标准的开发者确实认识到受控委托的需求，且他们提供了其中可将受控委托策略插入到证书内的占位符。然而，他们没有定义表达或实施这一控制的任何机制。

图6是从功能观点示出示例委托机制600以及示例委托情形的框图。如图所示，示例委托情形包括断言者602、主体#1604和主体#2606。还存在权限授予能力608、权限610和两个转移612(1)和612(2)。示例委托机制600包括委托授权机构断言614，在某些实现中还包括委托准许断言616。

在图6的示例委托情形的所述实现中，断言者602对应于授权机构，主体#1604对应于委托方，主体#2606对应于被委托方。断言者602具有权限授予能力608。经由委托授权机构断言614的转移612(1)，权限授予能力608从断言者602委托给主体#1604。

因此，主体#1604作为委托授权机构断言614的结果获得权限授予能力608。主体#1604具有权限610。由于委托授权机构断言614，主体#1604可向一个或多个其它主体，诸如主体#2606授予权限610。被委托方主体、所授予的权限的本质和/或如何行使所授予的权限可由委托授权机构断言614控制。经由委托准许断言616的转移612(2)，权限610从主体#1604向主体#2606授予。应理解，转移612(1)可以是隐式的，且委托授权机构断言614可经由安全策略而为资源保卫214(图2)所知。基于权限610和委托准许断言616来实施资源访问的是资源保卫214。

因此，委托机制600至少包括委托授权机构断言614，且可包括委托准许断言616来完成完整的委托过程。本文中在以下进一步描述委托授权机构断言614和委托准许断言616的示例实现。

图7是从逻辑观点示出示例委托机制600以及示例委托类型714的框图。如图所示，示例委托机制600包括可用于控制权限的委托的多个示例因素702-712。作为示例而非限制，这些示例因素包括：主体702、动词短语704、资源706、事实限定词708、属性710、传递连锁712等。

委托机制600能够实现多种不同类型的委托控制。如图所示，这些示例委托控制类型包括但不限于：基于属性的委托714(1)、受约束的委托714(2)、深度界定的委托714(3)以及宽度界定的委托714(4)。这四种具体示例类型的受控委托以下在对概括受控委托概念和实现的附加描述之后更详细地描述。如由其它委托类型714(T)所表示地，委托机制600可能能够实现众多其它类型的受控委托。

在所述实现中，框702-710中的每一个在逻辑上表示委托机制600就所指示的因素控制委托的能力。从而，委托机制600可通过所标识的一个或多个主体702、某一动词短语704、特定资源706、一个或多个所指示的事实限定词708、至少一个给定属性710和/或所许可的传递连锁(深度)712，来控制委托。仅作为示例，委托机制600可被实现为可用于使用至少因素702-712来控制委托的应用程序编程接口(API)。

如本文中在以上所述，事实限定词包括诸如时间段/时间跨度、位置、网络连通机制、撤销检查频率等环境限制。属性指的是其中主体可拥有一个或多个属性的属性名-属性值对。

这些因素中的任何一个都可以与主体#1604和/或主体#2606相关。换言之，仅作为示例，委托机制600可控制主体#1604可向主体#2606委托对哪一资源706的何种访问(例如，通过动词短语704)。委托机制600可控制哪些主体取得作为主体#2606的资格。而且，委托机制600可要求想要成为主体#2606的主体拥有给定属性710。另外，可通过事实限定词708(例如，结合条件约束)实施对委托的限制环境控制。这些和其它可能性在本文中由以下描述进一步说明。

委托机制600还可控制是否启用传递连锁委托，且如果是，还控制传递连锁因素712许可到何种程度或深度的传递连锁委托。传递连锁指的是主体#1604是否被许可将权限授予能力608进一步传递或委托给主体#2606。如果这被许可，则主体#1604能够向主体#2606发出委托授权机构断言614。主体#2606又能向某一第三主体发出委托准许断言616。该传递连锁委托将在本文中在以下具体参考图9和10进一步描述。

图8是示出委托机制的委托授权机构断言的示例断言格式800的框图。委托授权机构断言614的概念在上文中(参考图6)作为委托机制600的一部分来介绍和描述。委托授权结构断言614通过将权限授予能力608从一方传递到另一方，诸如从断言者传递到第一主体而发起委托。

在图8中再现了图5的示例断言格式500的一部分。然而，主体部分502被断言者部分802替换，而明确示出了多个，即“m”个约束512的地位。应注意到，本文中利用命名“断言者”、“主体#1”和“主体#2”以便于区分委托情形中相应的各方。然而，每一方均可被认为基本上且实际上是所述安全语言的总方案中的一主体。

因此，在所述实现中，示例断言格式800包括断言者部分802、说部分504、事实部分508、如果部分510、“n”个条件事实_1...n部分508(1...n)、以及“m”个约束_1...m部分512(1...m)。事实508通过包括委托指示动词520而被实现为委托事实。作为示例而非限制，示例包括“能够断言”、“能够说”、“能够表示”、“可以声称”等。本文中以下所述的某些委托相关断言示例使用“能够断言”的具体示例而不损害一般性。

委托事实208包括主体#1部分502(1)、委托指示动词520以及被委托的事实部分508(D)。被委托的事实508(D)包括主体#2部分502(2)、动词短语部分516、资源部分804和事实限定词_1...f部分(1...f)。因此，示例断言格式800可遵循以下形式：

断言者说主体1委托指示动词“主体2动词短语资源事实限定词_1...f”，如果事实₁，事实₂，...，事实_n，约束_1...m。

因此，在所述实现中，程序可包括用于委托机制的应用程序编程接口(API)。委托机制由断言者发起，并允许第一主体将权限委托给第二主体，供第二主体作出至少一个断言。委托机制允许具体控制委托。例如，委托机制可允许委托使用因素702-712中的任何一个来控制。

例如，委托机制600可允许断言者指定第一主体能够委托作出断言的权限而要拥有的至少一个属性和/或指定第二主体被许可作出断言而要拥有的至少一个属性。例如，委托授权机构断言614可包括条件事实508(1)，诸如：主体1拥有(属性名，属性值)或主体2拥有(属性名，属性值)。

作为另一示例，委托机制600可允许断言者指定第一主体只有当第一主体对于特定资源具有某一能力时才能委托作出断言的权限和/或第二主体只有当第二主体对于特定资源具有某一能力时才被许可作出断言。例如，委托授权机构断言614可包括条件事实508(1)，诸如：主体1读资源_a或主体2动词Foo。

作为又一示例，委托机制600可允许断言者指定限制可行使委托或权限的方式的至少一个事实限定词。例如，委托授权机构断言614可包括被委托的事实508(D)，诸如：“主体2写资源_b[连通_机制]”，带有约束512，诸如：连通_机制＝LAN。

因此，在所述实现中，一般机制允许在被委托的访问权限上表达精细粒度的控制。作为示例而非限制，可关于以下各项表达对于被委托的访问权限的精细粒度的控制：

·正对其委托访问的资源；

·可在这些资源上行使的权限；

·这些权限正被委托给的主体；

·被委托方进一步委托这些访问权限或其子集(例如，经由传递连锁)的能力；以及

·对被委托的访问权限的行使的环境限制(例如，时间跨度、位置等)(例如，经由事实限定词)。

如本文所述的委托机制能够使用允许指定委托策略和委托权限两者的统一声明性表示来表达这些委托控制因素。如图5和8所示并如上所述，利用安全断言的一般形式来创建允许表达受控委托策略的委托授权机构断言614的示例形式。此处为便于参考重复该示例格式：

断言者说主体1委托指示动词“主体2动词短语资源事实限定词_1...f”，如果事实₁，事实₂，...，事实_n，约束_1...m。

在此形式中，断言者是授权作出委托的授权机构；主体1是可作出委托的潜在委托方；而主体2是被委托方。

某些示例委托策略包括：

(1)B将对文件Foo的8小时读访问权委托给任何主体的权限可被表达为：

A说B能够断言“x读Foo[t1，t2]”，如果(t2-t1)≤8小时。

通过控制变量‘x’可绑定到的值，可限制可作为被委托方的主体集。例如，可对变量‘x’施加等同性或不等同性约束。

(2)主体p将其对资源Foo持有的权限委托给其它主体的权限可被表达为：

A说p能够断言“x v Foo”，如果p v Foo。

如果B读|写Foo为真，则以上委托策略隐含A说B能够断言“x读|写Foo”。

诸如以上示例等委托策略可与被断言的能力组合以创建全委托。在图6的示例情形中，委托准许断言616是被断言的能力。给定以上策略(1)，如果B也断言“B说C读Foo[0800，1200]”，则A将相信C被允许在所指定的时间跨度期间读Foo。类似地，给定以上策略(2)以及两个断言“A说B读Foo”以及“B说C读Foo”，则A将相信C被允许读Foo。

就委托权限的传递连锁而言，也描述了用于控制被委托方进一步委托其被授予的访问权限的能力的机制。呈现以上示例断言集以就此概念进行详述：

(3)A说B能够断言“x读Foo”；

(4)B说C能够断言“x读Foo”；以及

(5)C说D读Foo。

问题是A是否相信基于断言(3)D被授权读Foo，断言(3)仅陈述B具有委托对Foo的读访问权的权限。但在此示例中，B又断言(4)C具有委托对Foo的读访问权的权限。

如果允许不受控的连锁，则通过基于这些陈述的逻辑推断，对该问题的回答为是。该肯定性的回答是因为可通过使用断言(4)和(5)推断得到“B说D读Foo”是有效的结论。基于该推断和断言(3)，可得到“A说D读Foo”是有效的结论。另一方面，如果不允许通过所推断的事实的逻辑连锁，则对该问题的回答为否。当不允许连锁时，仅可得到通过断言(3)与断言(4)或断言(5)两者之一的直接组合而得到的结论，而不可得到同时通过断言(4)和(5)两者的结论。

在所述实现中，示例连锁委托机制通过引入修饰委托指示动词(例如，能够断言)的“深度”指示符或参数而允许对这种类型的逻辑连锁的精确控制。如果希望不允许逻辑连锁，则深度指示符具有值0，且断言(3)被重写成：

(3.1)A说B能够断言₀“x读Foo”。

或者，如果想要显式地允许B将委托传递给正好一个其他主体，则断言(3)、(4)和(5)可用具有值1的深度指示符重写成：

(3.2)A说B能够断言₁“x读Foo”。

(4.2)B说C能够断言₀“x读Foo”；以及

(5.2)C说D读Foo。

在断言(4.2)中深度指示符被设为值0以实施C不被允许传递其被委托的访问权限。如果它被允许这样做，则建立对于断言(3.2)有效的断言所需的逻辑推断的连锁将超过所指示的允许深度1。采用这种方法，为了允许将被委托的访问权限传递给其他主体的无界能力，可使用深度指示符值无穷大。

因此，在一示例实现中，深度指示符可被设为0、无穷大或任何正整数。示例相应的句法分别是：能够断言₀、能够断言_∞和能够断言_n。这允许无界委托(例如，采用无穷大)或带有任何所需传递连锁深度(例如，0、1、2...)的精确设置的有界委托。

然而，在另一示例实现中，深度指示符仅可被设为0或无穷大。这允许(i)防止任何委托连锁(例如，采用值0)或(ii)无界委托。在该替换示例实现中，可对嵌套的委托指示动词启用有界但非零的连锁，这将在以下段落中描述。

更具体地，使用“能够断言”实现，可用使用遵循以下形式的断言的嵌套来实现连锁委托：A说B能够断言₀x能够断言₀y能够断言₀z拥有组名＝g。之前的示例是显式的三级委托。委托指示动词的数目或嵌套的级数确定连锁的深度。为了减少对深度指示符的使用，当没有显式指示时，可认为无连锁或无界连锁是默认传递连锁规则。也可对嵌套采用正整数值的深度指示符。可实现其他组合或派生。

图9是从功能观点示出示例连锁委托机制600C以及示例连锁委托情形的框图。如图所示，示例连锁委托情形包括断言者602、主体#1604(1)、主体#2604(2)...主体#d604(d)。变量“d”是对应于连锁深度的整数。委托情形还包括主体606、权限授予能力608、以及权限610。

在所描述的实现中，断言者602将权限授予能力608委托给主体#1604(1)。主体#1604(1)将权限授予能力608委托给主体#2604(2)。如由省略号所示，可能通过其他中间主体604，主体#2604(2)将权限授予能力608委托给主体#d604(d)。主体#d604(d)然后向主体606授予权限610。允许连锁委托机制600C的安全语言实现的示例一般方法在上文中描述(例如，以上的传递连锁描述和示例，以及一般委托授权机构断言格式800)。专用于连锁委托机制的示例格式方法以下参考图10来描述。

图10是示出连锁委托机制的两个示例格式方法1000的框图。格式1000(1)示出具有深度指示符的委托格式，而格式1000(2)示出利用嵌套的委托格式。仅作为示例，委托指示动词使用示例格式方法1000中的“能够断言”实现来实现。

更具体地，格式1000(1)包括主体#1部分502(1)、能够断言部分520以及被委托的事实部分508(D)。格式1000(1)也包括连锁深度指示符1002。连锁深度指示符1002与能够断言部分520相关联。连锁深度指示符1002可取任何值以设置所允许的传递连锁深度。以上的示例包括0、无穷大和正整数。

格式1000(2)包括主体#1部分502(1)、能够断言部分520、主体#2部分502(2)、能够断言部分520、主体#3部分502(3)、能够断言部分520以及被委托的事实部分508(D)。尽管未示出，但格式1000(2)中的每一能够断言部分520也可与连锁深度指示符1002相关联。例如，这样的连锁深度指示符1002可被设为0以指示格式1000(2)中的每一个别能够断言部分520不允许传递连锁(例如，除了嵌套所允许的以外)。

图11是示出用于创建委托授权机构断言的方法的示例的流程图1100。流程图1100包括七(7)个框1102-1114。尽管可在其他环境中以及采用各种硬件/软件/固件组合来执行流程图1100的动作，但使用图1-10的某些特征、组件和方面来示出该方法的示例。

在所述实现中，在框1102，指定委托方主体和被委托方主体。例如，可用委托机制的主体因素702来标识主体#1604和主体#2606。

在框1104，指定动词短语。例如，可用动词短语因素704指定某一动词短语。在框1106，指定资源。例如，可用资源因素706指定特定资源110。动词短语和资源可被组合以表示可从主体#1604向主体#2606授予的权限。

在框1108，指定连锁深度。例如，根据传递连锁因素712，可通过连锁深度指示符1002(遵循断言格式方法1000(1))和/或多个委托指示动词的嵌套表达式(遵循断言格式方法1000(2))指定连锁深度。

在框1110，指定事实限定词。例如，可指示至少一个环境限制或其他事实限定词因素708要应用于对于该资源的任何权限。尽管未在图11中示出，但还可指定关于一个主体或主体双方的给定属性(且并入框1112的委托授权机构断言内)。例如，可用属性因素710指定主体#1604和/或主体#2606必须拥有给定属性以便委托被许可。

在框1112，用委托指示动词制定带有所指定的因素的委托授权机构断言。例如，可使用任何所指定的因素702-712中来制定遵循断言格式800且包括委托指示动词部分520的委托授权机构断言614。例如，主体#1部分502(1)、主体#2部分502(2)、动词短语部分516、资源部分804以及事实限定词_1...f部分806(1...f)各自可作为委托授权机构断言614的一部分来包括。可使用一个或多个条件事实_1...n508(1...n)将给定属性指定为需要为所标识的主体所拥有。

在框1114，将委托授权机构断言添加到信任和授权策略。例如，委托授权机构断言614可被添加到信任和授权策略222。之后，委托准许断言616和/或任何其他相关断言可被组合成授权上下文212内的断言上下文。

在所述实现中，为了使委托正确实现，委托准许断言616还至少包括在委托准许断言616中的相应的被委托的事实608(D)中所指定的特定资源、某一动词短语以及被委托方主体。然后结合授权引擎218中的断言上下文对来自授权查询表224的授权查询求值以确定关于特定资源110的授权决策。

以下呈现四种示例委托相关策略习惯用法。其每一个都对应于一示例委托类型714(图7)。具体地，呈现了基于属性的委托714(1)、受约束的委托714(2)、深度界定的委托714(3)以及宽度界定的委托714(4)示例。

基于属性的委托类型714(1)：基于属性(与基于身份相对)的授权允许其身份一开始彼此未知的各方之间的协作。断言一对象持有一属性(诸如是学生)的授权然后可被委托给其他方，这些其他方也可由属性而非身份来表征。

在以下示例中，学生享有折扣。学生属性的有效期可用约束来检查。对学生属性的授权可被委托给大学属性的持有者，而对大学属性的授权可被委托给已知主体，即教育部。

管理员说x享有折扣，如果

     x是学生直到日期，

     currentTime(当前时间)()≤日期

管理员说univ能够断言_∞x是学生直到日期，如果

       Univ是大学

管理员说教育部能够断言_∞univ是大学

受约束的委托类型714(2)：委托方可能希望限制被委托的事实的参数。这可通过使用约束来完成。在以下示例中，向STS给予发放用于在不长于8个小时的指定有效性时段内访问某一资源的权证的权限。

管理员说STS能够断言_∞x具有访问权从t1直到t2，如果t2-t1≤8小时

在以上断言中指定的委托深度是无限的，因此STS又可将同一权限委托给某一STS2。采用以下STS的断言，管理员接受STS2发放的、有效性时段至多8小时的权证，其中起始日期不早于01/01/2007。

STS说STS2能够断言₀x具有访问权从t1直到t2，如果t1≥01/01/2007

深度界定的委托类型714(3)：在所述实现中，能够断言关键词的委托深度下标仅能为0(没有再委托)或∞(无限再委托)。然而，这样的示例安全语言可通过嵌套能够断言来表达任何固定整数的委托深度。在以下示例中，Alice将对是朋友事实的授权委托给Bob，并允许Bob进一步地再委托一级。

Alice说Bob能够断言₀x是朋友

Alice说Bob能够断言₀x能够断言₀y是朋友

假定Bob用断言“Bob说Charlie能够断言_∞x是朋友”再委托给Charlie。现在，根据“Charlie说Eve是朋友”而“Alice说Eve是朋友”。由于Alice不接受任何更长的委托连锁，Alice(而不是Bob)不允许Chaile用以下断言来再委托

Charlie说Doris能够断言₀x是朋友

而且，Charlie也不能用以下技巧而绕开委托深度限制，因为该限制也适用于条件事实。

Charlie说x是朋友，如果x是Doris的朋友

Charlie说Doris能够断言₀x是Doris的朋友

从而，如果假定Alice和Bob作出的提及动词短语x是朋友的仅有的断言是以上列出的那些，则可示出查询Alice说x是朋友的结果仅依赖于Charlie的断言——而不是例如Doris的那些。

宽度界定的委托类型714(4)：假定Alice想要将对是朋友的事实的授权委托给Bob。她不关心委托连锁的长度，但她要求连锁中的每个委托方都满足某一性质，例如拥有来自fabrikam.com的电子邮件地址。以下断言通过使用带有下标0的能够断言关键词来编码受控传递委托而实现该策略。具有是委托方属性的主体由Alice授权断言是朋友事实、并传递再委托该属性，但仅限于具有匹配的电子邮件地址的主体。

Alice说x能够断言₀y是朋友，如果

　　　x是委托方

Alice说Bob是委托方

Alice说x能够断言₀y是委托方，如果

　　　x是委托方，

　　　y拥有电子邮件电子邮件，

　　　 电子邮件匹配^＊@fabrikam.com

图1-11中的设备、动作、方面、特征、功能、过程、模块、数据结构、协议、组件等都在分为多个框的示意图中得到阐明。然而，描述和/或示出图1-11的次序、互连、相互关系、布局等不旨在被解释为限制，任何数目的这些框可按照任何方式被修改、组合、重新排列、增加、省略等，以实现用于控制权限的委托的一个或多个系统、方法、设备、过程、介质、装置、API、协议、安排等。

尽管系统、介质、设备、方法、过程、装置、机制、方案、途径、进程、安排、以及其它实现都用专用于结构、逻辑、算法、以及功能特征和/或示意图的语言加以描述，但是应该理解在所附权利要求中定义的本发明不必限于以上描述的具体特征或动作。相反，上述具体特征和动作是作为实现权利要求的示例形式公开的。