对web服务资源的访问的授权 背景
web服务近年来作为越来越多地连接人、信息和过程的方式发展。web服务的好处之一是web服务跨多个平台操作的能力并且易于对web服务作出修改。web服务如此成功的原因之一是将XML用作用于表示和传送独立于编程语言、软件平台和硬件的结构化数据的标准且通用的语言。
存在许多其中期望保护web服务资源以使得这些资源只可由适当的人或系统来访问或使用的情形。用于保护web服务资源的常规方法聚焦于认证，并且尤其聚焦于定义信任关系。常规系统通常允许从可信位置访问web服务的任何人或设备访问该web服务及相关联的资源。这些常规系统不提供供第三方提供对访问或使用web服务的特定请求的授权的方式。相反，web服务通常被配置成信任从可信位置进行通信的任何人。这些和其他问题由根据本发明的各实施例来解决。
概述
本发明的各实施例一般涉及关于web服务的授权。在一个非限制性示例中，web服务包括受保护资源。请求者向web服务发送对受保护资源的请求。web服务操作以禁止对受保护资源的访问直到该web服务接收到来自授权者的授权。
如此处所讨论的，某些实施例的一方面涉及用于控制对受保护web服务资源的访问的计算系统。该计算系统包括通信设备、处理器和存储器。该通信设备跨通信网络进行通信。该处理器通信地连接到该通信设备。该存储器存储程序指令，该程序指令在由该处理器执行时使得该计算系统执行以下操作，包括：接收从通信网络访问受保护web服务资源的请求；确定该访问受保护web服务资源的请求是否已被授权；如果该请求未被授权，则拒绝对该受保护web服务资源的访问；以及如果该请求已被授权，则准许对该受保护web服务资源的访问。
某些实施例的另一方面涉及一种授权对web服务资源的访问的方法。该方法包括从请求者接收标识web服务资源的请求；确定访问该web服务资源需要授权；从授权者接收授权请求者访问该web服务资源的授权；以及将该授权传递给该请求者。
某些实施例的又一方面涉及一种包含计算机可执行指令的计算机可读介质，该指令在由计算机执行时执行授权对受保护资源的访问的方法。该方法包括接收标识受保护web服务资源的请求；接收授权对该受保护web服务资源的使用的授权；确定该请求是否已被授权；以及将该授权传递给该请求者。
提供本概述是为了以简化的形式介绍将在以下详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护的主题的关键特征或必要特征，也决不旨在用于限制所要求保护的主题的范围。
附图简述
图1是示例授权系统的框图。
图2是用于实现图1所示的授权系统的各方面的示例性计算系统。
图3是示出授权对web服务资源的访问的示例方法的流程图。
图4是示出授权对web服务资源的访问的另一示例方法的流程图。
图5是进一步示出图4所示的授权对web服务资源的访问的方法的示例的流程图。
详细描述
本发明现将参考其中示出了各具体实施例的附图来更完整地描述各示例性实施例。然而，其它方面能以许多不同的形式来实现，并且在本发明中包括具体实施例不应被解释为将这些方面限于在此所述的各实施例。相反，包括附图中描绘的各实施例是为了提供全面和完整且将预期的范围完全地传达给本领域技术人员的公开。在参考附图时，使用相同的附图标记来指示所有附图所示的相同的结构和元素。
本发明的各实施例一般涉及关于web服务的授权。在一个非限制性示例中，web服务包括受保护资源。请求者向web服务发送对受保护资源的请求。web服务操作以禁止对受保护资源的访问直到该web服务接收到来自授权者的授权。
图1是示例授权系统100的框图。授权系统100包括请求者102、web服务104、受保护资源106和授权者108。请求者102、web服务104和授权者108全都通信地连接到网络110。
在一个实施例中，请求者102是跨网络110与web服务104进行数据通信的计算系统，诸如图2所示的计算系统200。在某些实施例中，请求者102从用户接收输入，该用户通过用户接口来向计算系统提供输入并为该计算系统作出决定。该用户通过诸如显示器、鼠标、键盘等一个或多个用户接口来与计算系统交互。在某些实施例中，请求者102操作诸如INTERNET
![]()
因特网浏览器等浏览器软件应用程序，该应用程序使用诸如超文本传输协议(HTTP)等网络协议来跨网络110与web服务104进行通信。在其他实施例中，除了因特网浏览器之外的一个或多个软件应用程序在请求者102上操作。在所示实施例中，请求者102寻求访问web服务104的受保护资源106。
在一个实施例中，web服务104是诸如web服务器等操作web服务的计算系统。一般而言，web服务104提供涉及受保护资源106的有用功能。该web服务可使用网络协议通过网络110来访问。web服务可用于提供无数种有用功能。一个示例是日历服务。客户机向服务器提供诸如向日历添加约会等请求。该web服务存储对应于该客户机的约会。稍后，该客户机可请求查看由该web服务提供的所存储的约会。可能的web服务的另一示例是维护电子邮件分发列表的服务。客户机标识将存储在邮件列表中的用户。服务器存储对应于该客户机的列表。稍后，该客户机可请求该服务器向该分发列表中的所有成员发送消息。该web服务执行所请求的功能。可能的web服务的其他示例包括：向诸如系统管理员组等安全组添加用户名；修改给定动作的授权要求；如在人力资源职员或紧急工作人员请求时提供对用户的个人信息的访问；以及诸如通过此处所描述的过程来将对记录的访问限于特定用户组和/或被特别授权访问这些记录的用户。
web服务104的一个示例是图2所示的计算系统200。web服务104跨网络110与请求者102和授权者108进行数据通信。web服务的一个示例是被配置成根据有时也被称为面向服务的体系结构协议的简单对象访问协议(“SOAP”)来跨网络110进行通信的计算系统。SOAP是当前由万维网联盟，即万维网的国际标准组织的XML协议工作组来维护的协议。SOAP将可扩展标记语言(“XML”)用作标准消息格式。在一个实施例中，SOAP消息使用诸如HTTP 1.1等超文本传输协议(“HTTP”)来交换。
HTTP是定义以请求开始并以响应结束的通信模式的协议。请求消息是从客户机发送到服务器(诸如从请求者102发送到web服务104)的消息，该消息一般包括请求、首部、空行和消息正文。该请求包括对该消息所涉及的资源的标识。HTTP定义指示将对所标识的资源执行的所需动作的多个请求方法。HTTP请求方法的一个示例是Get(获取)方法。该Get方法请求所标识的资源的表示或副本。HTTP请求方法的另一个示例是Put(放置)方法。该Put方法上传所标识的资源的表示。包含Get命令的请求消息被称为Get消息或Get请求。包含Put命令的请求消息被称为Put消息或Put请求。在web服务器接收到该请求之后，该web服务器向客户机提供响应。该响应包括状态行、首部、空行和消息正文。该状态行包括状态码和文本原因短语(诸如“Not Found(未找到)”等)。响应内容取决于请求内容。例如，对Get消息的响应如所请求地将包括所标识的资源的表示。
SOAP还定义被称为SOAP故障的消息格式。SOAP故障一般用于携带SOAP消息格式的错误信息。SOAP故障还可由web服务器用来向客户机传递遵循请求的响应。在一个示例中，使用SOAP 1.2以使得该SOAP故障包含上下文首部和正文。该上下文首部包括标识原始请求的标识符以及已被发现与该请求相关联的任何授权过程。正文包括此处所描述的详细元素的内容。详细元素的内容表示所请求的资源在web服务能够继续之前需要授权。
在另一实施例中，与web服务104的通信涉及遵照web服务资源传输(WS‑RT)协议的SOAP通信。WS‑RT定义用于访问基于web服务的资源的表示的通信协议。WS‑RT包括Create(创建)、Get和Put消息。Create消息用于生成对象的表示，如XML表示。所需表示被包括在Create消息的正文中。Get消息可用于取得资源表示的片段的表示。表示的片段是表示的一部分，以使其不必取得整个表示。Get消息在该消息的首部中包括所需对象的唯一标识符。由此，该Get消息用于请求已经知道其唯一标识符的单个对象。Put消息可用于上传对资源的表示的片段的表示。WS‑RT还定义向客户机传递响应的故障操作。如此处所使用的，Get、Put和Fault(故障)消息指的是包含各种协议(包括HTTP、SOAP以及各种web服务协议)的一般类型的消息，除非特别标识特定协议。
另一实施例利用也由万维网联盟维护的WS‑枚举协议。WS‑枚举定义Enumerate(枚举)消息。该Enumerate消息连同查询的表达式一起发送。在一个实施例中，该查询用XPath语言来编写。作为一个示例，该查询请求匹配特定准则集的所有资源的表示。web服务用枚举上下文的标识符来响应该Enumerate消息。客户机然后发送包括枚举上下文标识符的Pull(拉)消息以指定应取得匹配查询的对象中的多少。该web服务然后用指定数量的匹配该查询的资源来响应。然后可向服务器发送后续Pull消息以取得匹配该查询的另一批资源。该过程此处有时一般被称为发送Enumerate消息并接收响应。Enumerate消息的好处之一是该Enumerate消息使得客户机能够查询任何数量的匹配特定准则的资源。
另一个实施例利用web服务传输(WS‑Tx)协议。除了其他有用功能之外，WS‑Tx定义用于删除受保护资源的删除消息。
在所示实施例中，web服务104包括受保护资源106。受保护资源包括例如，由web服务104执行的功能以及只可由授权客户机来访问、使用或修改的由web服务104存储的数据。例如，如果web服务104提供维护组分发列表的服务，则该组分发列表是只可由授权客户机访问、使用或修改的受保护资源。作为另一示例，受保护资源106是目录中的条目。在另一实施例中，受保护资源106是数据库中的记录。在另一实施例中，受保护资源106是存储在存储器存储设备上的文件或文件的一部分。其他实施例使用其他形式的受保护资源106。
术语“访问”在此处有时用来指对受保护资源106的任何改变、修改、添加、删除或使用。在某些实施例中，对受保护资源106的使用包括获取存储在该受保护资源106中的数据。在某些实施例中，非授权客户机可获取对受保护资源106的访问权。例如，网络管理员在某些实施例中可具有访问权，即使并非由授权者特别授权。
在可能的实施例中，授权者108是与web服务104进行数据通信的计算系统。在某些实施例中，授权者108操作能够将跨网络110向web服务104传递消息的软件。例如，授权者108操作
![]()
消息收发和协作客户端。该消息收发和协作客户端能够跨网络110向web服务104发送电子消息。在所示实施例中，web服务104依赖授权者108来确定用户是否应被授权使用受保护资源106。在某些实施例中，授权者108和web服务104在同一计算系统上操作。
网络110是请求者102、web服务104和授权者108之间的数据通信路径。在一个实施例中，网络110是因特网。在其他实施例中，网络110是局域网、内联网、无线网络或者能够将数据从一个处理设备传递到另一个处理设备的任何其他通信路径。
在某些实施例中，跨网络110的数据通信根据网络通信协议来执行。在一个可能的示例中，使用HTTP来在请求者102、web服务104和授权者108之间传递数据。在另一实施例中，遵循SOAP。在另一实施例中，遵循WS‑RT协议。其他实施例使用其他数据通信协议。
在某些实施例中，认证用户以确保用户是他们所声称的人。认证的一个示例在由Craig V.McMurtry、Alexander T.Weinert、Vadim Meleshuk和Mark E.Gabarra在2008年2月1日提交的题为“REQUEST‑SPECIFICAUTHENTICATION FOR ACCESSING WEB SERVICE RESOURCES(对访问web服务资源的请求专用认证)”的美国专利申请第12/024,901号中描述，该申请的全部公开内容通过引用结合于此。
图2是用于实现本发明的各方面的示例性计算系统200。在一个实施例中，计算系统200是web服务104。在另一个实施例中，计算系统200是请求者102。在另一个实施例中，计算系统200是授权者108。
在其最基本的配置中，计算系统200通常包括至少一个处理单元202和存储器204。取决于计算系统系统的确切配置和类型，存储器204可以是易失性的(诸如RAM)、非易失性的(诸如ROM、闪存等)或是两者的某种组合。该最基本配置在图2中由虚线206来例示。另外，计算系统200还可具有附加特征/功能。例如，计算机系统200还可包含附加存储(可移动和/或不可移动)，包括但不限于磁盘、光盘或磁带。这些其他存储在图2中由可移动存储208和不可移动存储210示出。
计算系统200通常具有至少某种形式的计算机可读介质。计算机可读介质可以是可由计算系统200访问的任何可用介质。作为示例而非限制，计算机可读介质可包括计算机存储介质和通信介质。计算机存储介质包括以用于储存诸如计算机可读指令、数据结构、程序模块或其它数据等信息的任一方法或技术实现的易失性和非易失性，可移动和不可移动介质。计算机存储介质包括，但不限于，RAM、ROM、EEPROM、闪存或其它存储器技术、CD‑ROM、数字多功能盘(DVD)或其它光盘存储、磁带盒、磁带、磁盘存储或其它磁性存储设备、或能用于存储所需信息且可以由计算系统200访问的任何其它介质。通信介质通常以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并包括任意信息传送介质。术语“已调制数据信号”指的是其一个或多个特征以在信号中编码信息的方式被设定或更改的信号。作为示例而非限制，通信介质包括有线介质，诸如有线网络或直接线连接，以及无线介质，诸如声学、RF、红外线和其它无线介质。以上的任何组合也应包括在计算机可读介质的范围内。任何这样的计算机存储介质都可以是计算系统200的一部分。
计算系统200还可包含允许该计算系统与其它设备进行通信的通信连接212。通信连接212是通信介质的一个示例。通信介质通常以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并包括任意信息传送介质。术语“已调制数据信号”指的是其一个或多个特征以在信号中编码信息的方式被设定或更改的信号。作为示例而非限制，通信介质包括有线介质，诸如有线网络或直接线连接，以及无线介质，诸如声学、RF、红外线和其它无线介质。如此处所使用的术语计算机可读介质包括存储介质和通信介质两者。
计算系统200还可具有诸如键盘、鼠标、笔、语音输入设备、触摸输入设备等输入设备214。还可包括诸如显示器、扬声器、打印机等输出设备216。所有这些装置在本领域中都是众所周知的，因此不必在此详细讨论。
在某些实施例中，存储器204包括操作系统220、应用程序222、其他程序模块224和程序数据226中的一个或多个。应用程序222的示例包括web服务软件应用程序、因特网浏览器软件应用程序、消息收发和协作客户机软件应用程序或各种其他软件应用程序。在可能的实施例中，程序模块224和程序数据226中的任一个包括受保护数据。
图3是示出授权对web服务资源的访问的示例方法300的流程图。方法300包括操作302和操作304。方法300开始于操作302，在其问作出对资源的请求。在一个实施例中，操作302涉及请求者利用由受保护资源提供的功能的尝试。因为该资源是受保护的，所以该请求者并非被自动允许利用该受保护资源。相反，该请求者必需首先被授权。因此，接着执行在其间授权该请求的操作302。在一个实施例中，操作302涉及从授权者接收授权。一旦接收到该授权，该请求者就被允许利用该受保护资源。在其他可能的实施例中，操作302涉及访问受保护资源的请求。
图4是示出授权对web服务资源的使用的示例方法400的流程图。方法400包括操作402、404、406和408。方法400开始于操作402，在其间作出资源请求。在一个可能的实施例中，操作402涉及将请求从请求者102发送到web服务104。web服务104接收该资源请求并确定该请求涉及受保护资源。web服务104然后评估请求者102是否已被授权访问该受保护资源。在所示示例中，请求者102尚未被授权，并因此禁止对该资源的访问直到发生授权。
在一可能的实施例中，然后执行操作404以检查该资源请求的状态。在某些实施例中，不执行操作404。在操作404的一个示例中，请求者102周期性地轮询web服务104以确定请求的状态。web服务104用该状态来响应请求者102。在所示示例中，web服务104通知请求者102该请求尚未被授权。在某些实施例中，轮询在请求者102的用户选择因特网浏览器软件应用程序的刷新选项时执行。在另一实施例中，轮询由在请求者102上运行的软件应用程序周期性地执行。
在操作402中已经请求了资源后执行操作406以授权该请求。在一个实施例中，操作406涉及将消息从授权者108发送到web服务104以授权该请求。在已授权该请求后，执行操作408以传达该请求已被授权，诸如通知请求者现在能够利用受保护资源。在另一实施例中，作为对传达请求已被授权的替换(或补充)，操作408继续如所请求地提供对受保护资源106的访问。
图5是示出授权对web服务资源的使用的示例方法500的流程图。在该示例中，方法500涉及请求者102、授权者108和web服务104的交互。另外，方法500包括参考图4示出并描述的操作402、404、406和408的更具体的示例。在图5中，发自系统的通信由源自从相应系统向下延伸的虚线的箭头来表示。另外，系统所接收到的通信由终止于从相应系统向下延伸的虚线的箭头来表示。
在所示情形中，请求者102期望获取对在web服务104上操作并由其保护的受保护资源106的访问权。然后，在授予访问权之前，web服务104要求从授权者108接收到授权。
在该实施例中，方法500包括操作402、404、406和408。方法500开始于操作402，在其间请求者102向web服务104作出利用受保护资源106的请求。操作404可任选地在操作402之后执行，在操作404期间请求者102检查该请求的状态。操作406在操作402之后执行。操作406涉及将授权从授权者108发送到web服务104以授权该请求。一旦已授权该请求，就执行操作408，在其间将通信从web服务104发送到请求者102以通知请求者102该请求已被授权。
为了完整地描述一个示例方法500，操作402、404、406和408各自都被示为包含各种操作。这些操作仅仅作为授权对web服务资源的使用的方法的一个示例来示出。在该实施例中，方法402包括操作520、522和524。首先执行操作520，在其问将请求使用或访问受保护资源106的请求从请求者102发送到web服务104。在一个实施例中，操作520涉及将Create消息从请求者102发送到web服务104。web服务104接收该请求，并且评估受保护资源106是否需要授权，并且如果是，则评估请求者102是否先前已被授权。如果否，则web服务104确定在请求者102可访问或使用受保护资源106之前需要授权。
一旦web服务104确定需要授权，就执行操作522，在其间web服务104生成请求资源502。请求资源502由web服务104用来跟踪在操作520中接收到的请求的状态。例如，请求资源502包含标识在操作520中作出的请求是否已被授权的数据。当首次生成时，请求资源502标识该请求尚未被授权。如果稍后接收到授权，则更新请求资源502以标识该请求已被授权(诸如此处所描述的操作550中所执行的)。在一个实施例中，请求资源502由可扩展标记语言(XML)来定义。示例请求资源架构的一个实施例如下。
示例请求资源架构
<？xml version＝′1.0′encoding＝′utf‑8′？>
<xsd:schema
xmlns:xsd＝‘http://www.w3.org/2001/XMLSchema’
xmlns:idm＝‘http://schema.microsoft.com/2006/11/IdentityManagement’
targetNamespace＝‘http://schema.microsoft.com/2006/11/IdentityManagement’>
<xsd:simpleType name＝‘RequestStatusType’>
<xsd:restriction
base＝‘idm:String’>
<xsd:enumeration value＝‘Cancelled’/>
<xsd:enumeration value＝‘NotFound’/>
<xsd:enumeration value＝‘Denied’/>
<xsd:enumeration value＝‘Authenticating’/>
<xsd:enumeration value＝‘Authenticated’/>
<xsd:enumeration value＝‘Authorizing’/>
<xsd:enumeration value＝‘Authorized’/>
<xsd:enumeration value＝‘Processing’/>
<xsd:enumeration value＝‘ProcessingEffects’/>
<xsd:enumeration value＝‘Completed’/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType
name＝‘RequestDetailsType’>
<xsd:extension
base＝‘IdentityObject’>
<xsd:sequence>
<xsd:element
name＝‘ReferenceProperty’
type＝‘idm:XmlTextType’
minOccurs＝‘0’
maxOccurs＝‘1’/>
<xsd:element
name＝‘Action’
type＝‘idm:String’
minOccurs＝‘1’
maxOccurs＝‘1’/>
<xsd:element
name＝‘Body’
type＝‘idm:XmlTextType’
minOccurs＝‘1’
maxOccurs＝‘1’/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType
name＝‘ApprovalActionType’>
<xsd:extension
base＝‘IdentityObject’>
<xsd:sequence>
<xsd:element
name＝‘RequiredApproval’
type＝‘idm:Reference’
minOccurs＝‘1’
maxOccurs＝‘1’/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType
name＝‘ProcessType’>
<xsd:extension
base＝‘IdentityObject’>
<xsd:sequence>
<xsd:element
name＝‘Actions’
type＝‘idm:ReferenceCollection’
minOccurs＝‘0’
maxOccurs＝‘1’/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType
name＝‘RequestType’>
<xsd:complexContent>
<xsd:extension
base＝‘IdentityObject’>
<xsd:sequence>
<xsd:element
name＝‘Status’
type＝‘idm:RequestStatusType’
minOccurs＝‘1’
maxOccurs＝‘1’/>
<xsd:element
name＝‘Details’
type＝‘idm:Reference’
minOccurs＝‘1’
maxOccurs＝‘1’/>
<xsd:element
name＝‘ApprovalProcesses’
type＝‘idm:ReferenceCollection’
minOccurs＝‘0’
maxOccurs＝‘1’/>
<xsd:element
name＝‘ApprovalResponses’
type＝‘idm:ReferenceCollection’
minOccurs＝‘0’
maxOccurs＝‘1’/>
<xsd:element
name＝‘Data’
type＝‘idm:XmlTextType’
minOccurs＝‘0’
maxOccurs＝‘1’/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
Name＝’Request’
type＝’idm:RequestType’/>
</xsd:schema>
在以上所提供的示例请求资源架构中，定义了多个元素，包括Status(状态)、Details(细节)、ApprovalProcesses(批准过程)、ApprovalResponses(批准响应)、Data(数据)、ReferenceProperty(引用特性)、Action(动作)、Body(正文)、RequiredApproval(所需批准)、Actions(动作)以及Request(请求)。在该示例中，Status元素包含请求的状态，如已授权或未授权。Details元素包括对原始请求的描述。ApprovalProcesses元素存储与请求相关联的批准过程的唯一标识符。ApprovalResponses元素包含批准响应的唯一标识符。Data元素包含将由原始请求取得的任何数据。ReferenceProperty元素包含标识原始请求的目标的web服务定址(“WS‑定址”)引用特性。Action元素包含原始请求的动作首部。RequiredApproval元素存储批准对象的唯一标识符，如授权者108的标识符。以此方式，每一个受保护资源都可包括被允许提供对该资源的授权的不同授权者。在某些实施例中，这对于使得涉及一种话题或类型的资源的授权能够由一个授权者来处理，并使得涉及另一种话题或类型的资源的授权能够由另一个授权者来处理是有用的。Actions元素包含用于授权请求的批准动作类型的唯一标识符。Request元素是包含例如Status、Details、ApprovalProcesses和Data元素的副本的包装器。
请求资源架构的另一示例如下。
第二示例请求资源架构
<？xml version＝′1.0′encoding＝′utf‑8′？>
<xs:schema
elementFormDefault＝′qualified′
targetNamespace＝′http://schemas.microsoft.com/2006/11/IdentityManagement′
xmlns:xs＝′http://www.w3.org/2001/XMLSchema′
xmlns:idm＝′http://schemas.microsoft.com/2006/11/IdentityManagement′>
<xs:include
schemaLocation＝′http://sharepoint/sites/IdMT/Raven/Shared％20Documents/Featur
e％20Team％20Documents/Schema/Schema/Raven.Schema.IdentityManagementO
bject.Schema.M1.xsd′/>
<xs:complexType
name＝′RequestType′>
<xs:complexContent
mixed＝′false′>
<xs:extension
base＝′idm:ResourceType′>
<xs:sequence>
<xs:element
name＝′Parameter′
minOccurs＝′0′
maxOccurs＝′unbounded′
nillable＝′true′
type＝′idm:String′/>
<xs:element
name＝′Operation′
minOccurs＝′1′
maxOccurs＝′1′
nillable＝′true′
type＝′idm:RequestOperationType′/>
<xs:element
name＝′Target′
minOccurs＝′0′
maxOccurs＝′1′
nillable＝′true′
type＝′idm:Reference′/>
<xs:element
name＝′BusinessJustification′
minOccurs＝′0′
maxOccurs＝′1′
nillable＝′true′
type＝′idm:String′/>
<xs:element
name＝′RequestStatus′
minOccurs＝′1′
maxOccurs＝′1′
nillable＝′true′
type＝′idm:RequestStatusType′/>
<xs:element
name＝′RequestStatusDetails′
minOccurs＝′0′
maxOccurs＝′unbounded′
nillable＝′true′
type＝′idm:String′/>
<xs:element
name＝′AuthenticationWorkflowInstance′
minOccurs＝′0′
maxOccurs＝′unbounded′
nillable＝′true′
type＝′idm:Reference′/>
<xs:element
name＝′AuthorizationWorkflowInstance′
minOccurs＝′0′
maxOccurs＝′unbounded′
nillable＝′true′
type＝′idm:Reference′/>
<xs:element
name＝′ActionWorkflowInstance′
minOccurs＝′0′
maxOccurs＝′unbounded′
nillable＝′true′
type＝′idm:Reference′/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name＝′OperationType′>
<xs:restriction base＝′xs:string′>
<xs:enumeration value＝′Create′/>
<xs:enumeration value＝′Read′/>
<xs:enumeration value＝′Update′/>
<xs:enumeration value＝′Delete′/>
<xs:enumeration value＝′Enumerate′/>
<xs:enumeration value＝′SystemEvent′/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name＝′RequestStatusType′>
<xs:restriction base＝′xs:string′>
<xs:enumeration value＝′NotFound′/>
<xs:enumeration value＝′Validating′/>
<xs:enumeration value＝′Validated′/>
<xs:enumeration value＝′Authenticating′/>
<xs:enumeration value＝′Authenticated′/>
<xs:enumeration value＝′Authorizing′/>
<xs:enumeration value＝′Authorized′/>
<xs:enumeration value＝′Denied′/>
<xs:enumeration value＝′Processing′/>
<xs:enumeration value＝′ProcessingEffects′/>
<xs:enumeration value＝′Completed′/>
<xs:enumeration value＝′Canceled′/>
</xs:restriction>
</xs:simpleType>
<xs:element
name＝′ApprovalResponse′
nillable＝′true′
type＝′idm:ApprovalResponseType′/>
</xs:schema>
在以上所提供的第二示例请求资源架构中，定义了多个元素，包括Parameter(参数)、Operation(操作)、Target(目标)、BusinessJustification(商业论证)、RequestStatus(请求状态)、RequestStatusDetails(请求状态细节)、AuthenticationWorkflowInstance(认证工作流实例)、AuthorizationWorkflowInstance(授权工作流实例)以及ActionWorkflowInstance(动作工作流实例)。在该示例中，Parameter元素由web服务104的请求分派者来编写。该Parameter元素包含在操作524中发送的消息的正文的规范化表示。
Operation元素包含对在操作520中作出的请求所请求的操作的标识。在某些实施例中，该Operation元素包含选自“Create(创建)”、“Read(读取)”、“Update(更新)”、“Delete(删除)”、“Enumerate(枚举)”和“SystemEvent(系统事件)”的值。Target元素包含对操作所涉及的目标对象的引用。
BusinessJustification元素包含由请求者102输入的、为授权者108提供关于为什么需要访问受保护资源106的附加信息的基于文本的消息。
RequestStatus元素包含请求的当前状态。在某些实施例中，RequestStatus包含选自“Not Found(未找到)”、“Validating(正在确认)”、“Validated(已确认)”、“Authenticating(正在认证)”、“Authenticated(已认证)”、“Authorizing(正在授权)”、“Authorized(已授权)”、“Denied(已拒绝)”、“Processing(正在处理)”、“ProcessingEffects(处理见效)”、“Completed(完成)”和“Cancelled(已取消)”的值。
RequestStatusDetails元素包含用于向请求者102提供反馈的属性。反馈的示例包括将被发送到请求者102的错误消息或信息。
AuthenticationWorkflowInstance包含对已经启动的所有认证工作流实例的引用。
AuthorizationWorkflowInstance包含对已经启动的所有授权工作流实例的引用。
ActionWorkflowInstance包含对已经启动的所有动作工作流实例的引用。
存储请求资源502以使其可由web服务104访问。在一个可能的示例中，请求资源502是目录中的条目。在另一实施例中，请求资源502是数据库中的记录。在另一实施例中，请求资源502是存储在存储器存储设备上的文件或文件的一部分。
在生成请求资源502后，然后执行操作524以通知请求者102在web服务104能够处理请求之前需要授权。在一个实施例中，操作524涉及发送SOAP故障形式的响应。该SOAP故障包括Detail元素的内容。在某些实施例中，该Detail元素还包括WS‑定址端点引用，该引用包含web服务端点(如WS‑RT端点)的地址。在某些实施例中，该端点引用包含涉及资源的引用特性。在某些实施例中，操作524在操作522之前执行。
在操作402后，执行可任选的操作404。操作404一般是其中请求者102能够检查请求的状态，诸如以便确定该请求是否已被授权的过程。操作404包括操作530、532、534和536。操作404开始于操作530，在其间请求者102向web服务104发送询问请求状态的查询。在一个实施例中，操作530涉及将Get消息从请求者102发送到web服务104。该Get消息包含诸如由操作524的SOAP故障提供的请求资源的地址。在另一实施例中，操作530涉及将Enumerate消息从请求者102发送到web服务104。
在另一实施例中，操作530涉及重新提交在操作520中作出的请求，诸如包括与在操作520中作出的请求相关联的WS‑安全对话上下文。该请求被发送到由操作524中的响应提供的地址。
一旦web服务104接收到状态查询，然后就执行操作532。在操作532期间，web服务104查询请求资源502以确定请求的状态。在一个示例实施例中，请求资源502被存储在数据库中。在该实施例中，操作532涉及例如，web服务104执行结构化查询语言(“SQL”)Select语句以请求请求资源502的表示。在另一示例实施例中，请求资源502是目录中的条目。在该实施例中，操作532涉及web服务104执行LDAP查询。
然后执行操作534，在其间将请求资源502返回给web服务104。web服务104读取请求资源502并确定请求的状态。例如，web服务104读取请求资源502的“Status”元素以确定该请求是否已被授权。一旦已确定状态，就执行操作536，在其间将该状态传回到请求者102。在所示实施例中，请求尚未被授权，并且因此web服务104发送陈述该请求尚未被授权的消息。在某些实施例中，操作536涉及发送对Get或Enumerate消息的响应。
在请求者102作出操作402的请求之后的某一时刻，授权者108授权或拒绝该请求。在所示实施例中，授权者108在操作406中授权该请求。操作406开始于操作540，在其间将授权从授权者108发送到web服务104。在一个实施例中，通过Put消息来将授权从授权者108传递到web服务104。如果授权者108确定该请求不应被授权，则授权者108发送拒绝消息以通知web服务104该请求将不被授权。在一个实施例中，该拒绝也使用Put消息来传递。该Put消息用于用由示例请求资源架构定义的格式来更新资源的Data元素。在另一可能的实施例中，诸如通过利用
![]()
.NET框架3.5和持久服务(Durable Service)来提供WS‑安全对话令牌。
然而，在另一可能的实施例中，授权者108通过创建单独的资源来响应授权请求。作为一个示例，授权者108通过发送WS‑传输Create消息来执行操作540。该Create消息用于创建包含描述对授权请求的响应的信息的单独的资源(批准响应(ApprovalResponse)资源)。批准响应资源的示例架构如下。
示例批准响应资源架构
<？xml version＝′1.0′encoding＝′utf‑8′？>
<xs:schema
elementFormDefault＝′qualified′
targetNamespace＝′http://schemas.microsoft.com/2006/11/IdentityManagement′
xmlns:xs＝′http://www.w3.org/2001/XMLSchema′
xmlns:idm＝′http://schemas.microsoft.com/2006/11/IdentityManagement′>
<xs:include
schemaLocation＝′http://sharepoint/sites/IdMT/Raven/Shared％20Documents/Featur
e％20Team％20Documents/Schema/Schema/Raven.Schema.IdentityManagementO
bject.Schema.M1.xsd′/>
<xs:complexType
name＝′ApprovalResponseType′>
<xs:complexContent
mixed＝′false′>
<xs:extension
base＝′idm:ResourceType′>
<xs:sequence>
<xs:element
name＝′Approver′
minOccurs＝′1′
maxOccurs＝′1′
nillable＝′true′
type＝′idm:Reference′/>
<xs:element
name＝′Decision′
minOccurs＝′1′
maxOccurs＝′1′
nillable＝′true′
type＝′idm:ApprovalResponseDecisionType′/>
<xs:element
name＝′Reason′
minOccurs＝′0′
maxOccurs＝′1′
nillable＝′true′
type＝′idm:String′/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name＝′ApprovalResponseDecisionType′>
<xs:restriction base＝′xs:string′>
<xs:enumeration value＝′Approved′/>
<xs:enumeration value＝′Rejected′/>
</xs:restriction>
</xs:simpleType>
<xs:element
name＝′ApprovalResponse′
nillable＝′true′
type＝′idm:ApprovalResponseType′/>
</xs:schema>
在以上所提供的示例批准响应资源架构中，定义了多个元素，包括Approver(批准者)、Decision(决定)和Reason(原因)。Approver元素包含对授权者108的引用。Decision元素包含指示来自授权者108的对在操作520中作出的请求的响应的串。在一个示例中，该Decision元素具有值“Approved(批准)”或“Rejected(拒绝)”。Reason元素包含来自授权者108的、提供关于为什么批准或拒绝该请求的附加信息的文本消息。其他实施例包括其他资源和资源模式。
在一个实施例中，授权者108确定需要授权，诸如以便通过访问显示等待授权的请求的网站来发起操作406。例如，web服务104担当web服务器，并将该网站传送到在授权者108上操作的浏览器。在另一实施例中，授权者108运行周期性地轮询web服务104以检查等待授权的请求的软件应用程序。例如，软件应用程序在授权者108上操作以便周期性地检查等待授权的请求。在另一实施例中，web服务104与授权者108进行通信以通知授权者108请求等待授权。其一个示例在2007年11月15日提交的题为“MODELINGUSER‑INITIATED REQUESTS AND STATUS UPDATES WITHIN AN E‑MAILMESSAGE(对电子邮件消息中的用户发起的请求和状态更新建模)”的美国专利申请第11/931,004号中描述，该申请的全部公开内容通过引用结合于此。
然后执行操作542和546，在其间web服务104取得请求资源502的副本。在一个示例实施例中，请求资源502被存储在数据库中。在该实施例中，操作542涉及web服务104执行SQL Select语句以请求请求资源502的表示。在另一示例实施例中，请求资源502是目录中的条目。在该实施例中，操作542涉及web服务104执行LDAP查询。然后在操作546中将所请求的资源返回给web服务104。
一旦接收到授权，然后就执行操作548，在其间执行涉及受保护资源106的最初请求的操作。例如，将用户名添加到组分发列表。如此处所描述的，web服务104可执行许多其他操作。
在接收到授权后，执行操作550。在操作550中，web服务104更新请求资源502的状态。在一个实施例中，这涉及改变请求资源502的Status元素以指示已接收到对该请求的授权。在另一实施例中，用操作548的结果来更新请求资源502以记录在执行所请求的操作时发生了什么。例如，在Status元素中更新请求资源502以指示该请求已被授权。作为另一示例，更新请求资源502以示出用户名已被添加到组分发列表。这对于例如不仅提供在请求被授权时执行了什么操作，而且提供该操作的结果是有用的。
在接收到授权后执行操作552。在操作552期间，web服务104与授权者108进行通信以确认接收到批准。在一个实施例中，操作552涉及将Put响应消息从web服务104发送到授权者108。在替换实施例中，操作548、550和552能够以任何次序执行。例如，web服务104可在在操作548中执行所请求的操作之前更新请求资源502的状态。另外，操作552可在操作540后的任何时刻执行以便向授权者108传达已成功地接收到授权。
一旦已经接收到授权，就执行操作408以将授权事实传达给请求者102。除了在操作404中通知请求者尚未接收到授权，但在操作408中通知请求者已接收到授权之外，操作408与操作404相同。在可能的实施例中，周期性地执行操作404直到执行操作406以指示已接收到授权。
在所示实施例中，操作408开始于操作560，在其间请求者102向web服务104发送询问请求状态的查询。在一个实施例中，操作560涉及将Get消息从请求者102发送到web服务104。该Get消息包含诸如由操作524的SOAP故障提供的请求资源的地址。在另一实施例中，操作560涉及将Enumerate消息从请求者102发送到web服务104。在另一实施例中，操作560涉及通过在请求者102上操作的浏览器来刷新网页。
然后执行操作562和564，在其间web服务104请求请求资源502的副本并接收请求资源502的副本。在一个实施例中，操作562涉及web服务104查询请求资源502以确定请求的状态。然后执行操作564，在其间将请求资源502返回给web服务104。一旦web服务104已取得请求资源502，它就审阅请求资源502以确定请求的状态。在所示示例中，已在操作540中授权该请求。因此，执行操作566以通知请求者102该请求已被授权。在一个实施例中，操作566涉及发送对Get或Enumerate消息的响应。在某些实施例中，该响应包括原始请求所请求的来自受保护资源106的信息(诸如来自Data元素的数据)。
以上参考附图描述了本发明的各实施例，可以理解，可以对所公开的各实施例做出本领域技术人员易于想到且被包含在本发明的精神和范围内的众多修改。实际上，尽管出于公开的目的描述了目前优选的实施例，但可以做出落入本发明的范围的各种改变和修改。
同样地，虽然本发明使用了对结构特征、方法动作和含有这些动作的计算机可读介质专用的语言，但是应该理解，在所附权利要求书中定义的本发明不必限于此处描述的具体结构、动作、特征或介质。相反，上述具体特征和动作是作为实现权利要求的示例形式公开的。本领域技术人员将认识到本发明精神和范围中的其它实施例或改进。因此，这些具体结构、动作、或介质是作为示例性实施例而公开的。