第三方批处理授权重复访问资源的请求的方法及系统转让专利

申请号 : CN201580002703.0

文献号 : CN105765944B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : S·都伽纳A·朱朱瓦拉S·米斯拉

申请人 : 甲骨文国际公司

摘要 :

本公开内容的方面促进了第三方/服务器系统执行需要资源拥有者对资源的重复访问进行授权的请求的批处理。在一种实施例中,服务器系统/第三方从一批请求中选择下一个请求,其中下一个请求需要由拥有者/用户(第一方)拥有的(在第二方托管的)受保护资源。服务器系统检查授权由服务器系统代表拥有者访问受保护资源的访问令牌是否存在。如果访问令牌不存在,则服务器系统在离线模式下与拥有者通信以接受访问令牌。服务器系统然后通过利用存在的/接收到的访问令牌访问受保护资源来处理下一个请求。

权利要求 :

1.一种在服务器系统中处理请求的方法,所述方法包括:

在一段持续时间上分布的不同时间实例从一个或多个用户接收多个请求;

缓冲所述多个请求用于稍后成批处理;

其中,所述成批处理包括:

从缓冲用于处理的所述多个请求中选择下一个请求,所述下一个请求需要由第一拥有者拥有的第一受保护资源;

检查授权由所述服务器系统代表所述第一拥有者访问所述第一受保护资源的访问令牌是否存在;

如果所述访问令牌不存在,则在离线模式下与所述第一拥有者通信以接收所述访问令牌,其中所述通信包括在第一时间实例发送讯息并且在第二时间实例接收所述访问令牌,其中在所述离线模式中的操作使得对所述多个请求中的其他请求的处理在所述第一时间实例和所述第二时间实例之间进行;及通过利用所述访问令牌访问所述第一受保护资源来处理所述下一个请求。

2.如权利要求1所述的方法,其中

所述讯息在第一时间实例被发送给所述第一拥有者,用于异步授权对所述第一受保护资源的访问,在所述离线模式中的所述通信还包括:接收用于所述第一受保护资源的授权许可;及

通过将所述授权许可发送给授权服务器来获得所述访问令牌,其中所述异步授权意味着不需要所述第一拥有者在所述第一时间实例在线。

3.如权利要求2所述的方法,其中所述讯息是电子邮件消息或短消息服务(SMS)消息。

4.如权利要求2或3所述的方法,其中所述讯息包括统一资源定位符URL,该URL在被所述第一拥有者异步选择时,使得所述授权许可被转发给所述服务器系统,其中所述接收响应于所述第一拥有者选择所述URL并且授权对所述第一受保护资源的访问而接收所述授权许可。

5.如权利要求1-3中任何一项所述的方法,还包括维护指示为包括所述第一拥有者在内的拥有者生成的访问令牌的凭证数据,其中所述检查包括检查所述凭证数据,以确定用于所述第一拥有者的所述访问令牌是否存在。

6.如权利要求1-3中任何一项所述的方法,其中所述第一受保护资源被托管在资源服务器上,其中所述服务器系统、所述授权服务器和所述资源服务器被实现为支持用于受保护资源的授权的OAuth协议。

7.如权利要求1-3中任何一项所述的方法,其中所述服务器系统是面向服务的体系架构SOA服务器,其中所述多个请求对应于多个订单,使得所述下一个请求是下一个订单,其中所述受保护资源是个人网站中的账户,其中所述第一拥有者是授权对所述账户访问的管理员,其中所述下一个订单的所述处理包括利用所述下一个订单的处理的当前状态更新所述账户。

8.一种存储用于使服务器系统能够处理请求的一个或多个指令序列的非临时性机器可读介质,其中通过包含在所述服务器系统中的一个或多个处理器执行所述一个或多个指令使所述服务器系统能够执行以下动作:在一段持续时间上分布的不同时间实例从一个或多个用户接收多个请求;

缓冲所述多个请求用于稍后成批处理;

其中,所述成批处理包括:

从缓冲用于处理的所述多个请求中选择下一个请求,所述下一个请求需要由第一拥有者拥有的第一受保护资源;

检查授权由所述服务器系统代表所述第一拥有者访问所述第一受保护资源的访问令牌是否存在;

如果所述访问令牌不存在,则在离线模式下与所述第一拥有者通信以接收所述访问令牌,其中所述通信包括在第一时间实例发送讯息并且在第二时间实例接收所述访问令牌,其中在所述离线模式中的操作使得对所述多个请求中的其他请求的处理在所述第一时间实例和所述第二时间实例之间进行;及通过利用所述访问令牌访问所述第一受保护资源来处理所述下一个请求。

9.如权利要求8所述的机器可读介质,其中所述讯息在第一时间实例被发送给所述第一拥有者,用于异步授权对所述第一受保护资源的访问,在所述离线模式中的所述通信还包括用于以下动作的一个或多个指令:接收用于所述第一受保护资源的授权许可;及

通过将所述授权许可发送给授权服务器来获得所述访问令牌,其中所述异步授权意味着不需要所述第一拥有者在所述第一时间实例在线。

10.如权利要求9所述的机器可读介质,其中所述讯息是电子邮件消息或短消息服务(SMS)消息。

11.如权利要求9或权利要求10所述的机器可读介质,其中所述讯息包括统一资源定位符URL,该URL在被所述第一拥有者异步选择时,使得所述授权许可被转发给所述服务器系统,其中所述接收响应于所述第一拥有者选择所述URL并且授权对所述第一受保护资源的访问而接收所述授权许可。

12.如权利要求9至10中任何一项所述的机器可读介质,还包括用于维护指示为包括所述第一拥有者在内的拥有者生成的访问令牌的凭证数据的一个或多个指令,其中所述检查包括检查所述凭证数据,以确定用于所述第一拥有者的所述访问令牌是否存在的一个或多个指令。

13.如权利要求9至10中任何一项所述的机器可读介质,其中所述第一受保护资源被托管在资源服务器上,其中所述服务器系统、所述授权服务器和所述资源服务器被实现为支持用于受保护资源的授权的OAuth协议。

14.一种数字处理系统,包括:

处理器;

随机存取存储器RAM;

存储一个或多个指令的机器可读介质,其中,当指令被取回到所述RAM中并且被所述处理器执行时,使得所述数字处理系统处理请求,所述数字处理系统执行以下动作:在一段持续时间上分布的不同时间实例从一个或多个用户接收多个请求;

缓冲所述多个请求用于稍后成批处理;

其中,所述成批处理包括:

从缓冲用于处理的所述多个请求中选择下一个请求,所述下一个请求需要由第一拥有者拥有的第一受保护资源;

检查授权由所述服务器系统代表所述第一拥有者访问所述第一受保护资源的访问令牌是否存在;

如果所述访问令牌不存在,则在离线模式下与所述第一拥有者通信以接收所述访问令牌,其中所述通信包括在第一时间实例发送讯息并且在第二时间实例接收所述访问令牌,其中在所述离线模式中的操作使得对所述多个请求中的其他请求的处理在所述第一时间实例和所述第二时间实例之间进行;及通过利用所述访问令牌访问所述第一受保护资源来处理所述下一个请求。

15.如权利要求14所述的数字处理系统,其中对于在所述离线模式下的所述通信,所述数字处理系统在所述第一时间实例发送所述讯息给所述第一拥有者,用于异步授权对所述第一受保护资源的访问,所述数字处理系统还执行以下动作:接收用于所述第一受保护资源的授权许可;及

通过将所述授权许可发送给授权服务器来获得所述访问令牌,其中所述异步授权意味着不需要所述第一拥有者在所述第一时间实例在线。

16.如权利要求15所述的数字处理系统,其中所述讯息是电子邮件消息或短消息服务(SMS)消息。

17.如权利要求15或权利要求16所述的数字处理系统,其中所述讯息包括统一资源定位符URL,该URL在被所述第一拥有者异步选择时,使得所述授权许可被转发给所述服务器系统,其中所述数字处理系统响应于所述第一拥有者选择所述URL并且授权对所述第一受保护资源的访问而接收所述授权许可。

18.如权利要求14至16中任何一项所述的数字处理系统,还执行维护指示为包括所述第一拥有者在内的拥有者生成的访问令牌的凭证数据的动作,其中对于所述检查,所述数字处理系统执行检查所述凭证数据,以确定用于所述第一拥有者的所述访问令牌是否存在的动作。

19.如权利要求14至16中任何一项所述的数字处理系统,其中所述第一受保护资源被托管在资源服务器上,其中所述服务器系统、所述授权服务器和所述资源服务器被实现为支持用于受保护资源的授权的OAuth协议。

20.如权利要求14至16中任何一项所述的数字处理系统,其中所述数字处理系统是面向服务的体系架构(SOA)服务器,其中所述多个请求对应于多个订单,使得所述下一个请求是下一个订单,其中所述受保护资源是个人网站中的账户,其中所述第一拥有者是授权对所述账户访问的管理员,其中所述下一个订单的所述处理包括利用所述下一个订单的处理的当前状态更新所述账户。

21.一种用于在服务器系统中处理请求的系统,所述系统包括:第一接收单元,配置为:

在一段持续时间上分布的不同时间实例从一个或多个用户接收多个请求;及缓冲所述多个请求用于稍后成批处理;

选择单元,配置为从缓冲用于处理的所述多个请求中选择下一个请求,所述下一个请求需要由第一拥有者拥有的第一受保护资源;

检查单元,配置为检查授权由所述服务器系统代表所述第一拥有者访问所述第一受保护资源的访问令牌是否存在;

通信单元,配置为如果所述访问令牌不存在,则在离线模式下与所述第一拥有者通信以接收所述访问令牌,其中所述通信单元包括在第一时间实例发送讯息并且在第二时间实例接收所述访问令牌,其中在所述离线模式中的操作使得对所述多个请求中的其他请求的处理在所述第一时间实例和所述第二时间实例之间进行;及处理单元,配置为通过利用所述访问令牌访问所述第一受保护资源来处理所述下一个请求。

22.如权利要求21所述的系统,其中所述通信单元包括:发送单元,配置为在所述第一时间实例发送所述讯息给所述第一拥有者,用于异步授权对所述第一受保护资源的访问;

第二接收单元,配置为接收用于所述第一受保护资源的授权许可;及获取单元,配置为通过将所述授权许可发送给授权服务器来获得所述访问令牌,其中所述异步授权意味着不需要所述第一拥有者在所述第一时间实例在线。

23.如权利要求22所述的系统,其中所述讯息是电子邮件消息或短消息服务(SMS)消息。

24.如权利要求23所述的系统,其中所述讯息包括统一资源定位符URL,该URL在被所述第一拥有者异步选择时,使得所述授权许可被转发给所述服务器系统,其中所述第二接收单元被配置为响应于所述第一拥有者选择所述URL并且授权对所述第一受保护资源的访问而接收所述授权许可。

25.如权利要求24所述的系统,还包括维护单元,其配置为维护指示为包括所述第一拥有者在内的拥有者生成的访问令牌的凭证数据,其中所述检查包括检查所述凭证数据,以确定用于所述第一拥有者的所述访问令牌是否存在。

26.如权利要求25所述的系统,其中所述第一受保护资源被托管在资源服务器上,其中所述服务器系统、所述授权服务器和所述资源服务器被实现为支持用于受保护资源的授权的OAuth协议。

27.如权利要求25所述的系统,其中所述服务器系统是面向服务的体系架构(SOA)服务器,其中所述多个请求对应于多个订单,使得所述下一个请求是下一个订单,其中所述受保护资源是个人网站中的账户,其中所述第一拥有者是授权对所述账户访问的管理员,其中所述处理单元包括更新单元,其配置为利用所述下一个订单的处理的当前状态更新所述账户。

说明书 :

第三方批处理授权重复访问资源的请求的方法及系统

[0001] 优先权要求
[0002] 本专利申请涉及并且要求以下共同未决申请的优先权,这些申请被整体地结合于此:
[0003] A.于2014年2月18日提交的、序列号为758/CHE/2014、以与本专利申请相同的申请人命名的、标题为“Facilitating Third Parties To Perform Batch Processing Of Requests Requiring Authorization From Resource Owners For Repeat Access To Resources”的印度专利申请;及
[0004] B.于2014年6月10日提交的、序列号为14300251、以与本专利申请相同的申请人命名的、标题为“Facilitating Third Parties To Perform Batch Processing Of Requests Requiring Authorization From Resource Owners For Repeat Access To Resources”的美国非临时专利申请。

技术领域

[0005] 本公开内容涉及企业系统,并且更具体地,涉及促进第三方执行需要资源拥有者对资源的重复访问进行授权的请求的批处理。

背景技术

[0006] 相关技术
[0007] 资源是指诸如文件、照片、用户信息等任何数据项。资源通常被拥有者“拥有”,但是被其它方/第二方存储和管理。资源的拥有权意味着对应的用户(通常人类)可以控制谁被允许或拒绝对由第二方管理的资源的访问。这些资源被称为“受保护资源”。
[0008] 拥有者可以通过授予适当的授权允许第三方对资源的访问。通常有必要允许对资源的“重复”访问,这意味着单次授权可以是用于随着时间进行多次访问的基础。OAuth协议是开放的标准,该协议允许代表拥有者对资源的重复访问进行这种授权,如在相关领域中众所周知的。
[0009] 存在期望批处理请求的情况。批处理意味着若干个请求被积累 (通过适当的缓冲),并且在以后方便的时间被成批处理(即,继续处理累积的请求,直到完成所有请求的处理)。批处理通常在大规模环境中是有帮助的。
[0010] 本公开内容的各方面促进第三方执行需要资源拥有者对资源的重复访问进行授权的请求的批处理。

附图说明

[0011] 本公开内容的示例实施例将参考以下简要描述的附图进行描述。
[0012] 图1是示出其中可以实现本公开内容的若干个方面的示例环境的框图。
[0013] 图2是示出其中在一种实施例中实现受保护资源的授权的方式的序列图。
[0014] 图3是示出其中根据本公开内容的方面、促进第三方执行需要资源拥有者对资源的重复访问进行授权的请求的批处理的方式的流程图。
[0015] 图4A示出了在一种实施例中执行需要资源拥有者对资源的重复访问进行授权的请求的批处理的服务器的示例实现。
[0016] 图4B和4C绘出了在一种实施例中在不同时间实例维护的凭证数据的相应部分。
[0017] 图5是示出其中本公开内容的各方面可通过执行适当的执行模块可操作的数字处理系统的详细信息的框图。
[0018] 图6是示出在本公开内容的另一种实施例中用于执行请求的批处理的数字处理系统的框图。
[0019] 在附图中,相同的标号通常指示相同的、功能上相似的和/或结构上相似的元件。其中元件第一次出现的附图由对应标号中最左边的 (一个或多个)数字指示。

具体实施方式

[0020] 1.概述
[0021] 根据本公开内容的方面,服务器系统/第三方接收要被成批处理的多个请求。服务器系统然后从接收到的请求中选择下一个请求,其中下一个请求需要由拥有者/用户(第一方)拥有的(在第二方托管的)受保护资源。服务器系统检查是否存在授权由服务器系统代表拥有者访问受保护资源的访问令牌。如果不存在访问令牌,则服务器系统在离线模式下与拥有者通信来接收访问令牌。然后,服务器系统通过利用存在的/接收到的访问令牌访问受保护资源来处理下一个请求。
[0022] 因此,促进了第三方/服务器系统执行需要资源拥有者对资源的重复访问进行授权的请求的批处理。
[0023] 根据本公开内容的另一个方面,在离线模式下从拥有者接收访问令牌是通过首先发送讯息给拥有者用于异步授权对所述第一受保护资源的访问来实现的。在一种实施例中,发送给拥有者的讯息包括统一资源定位符URL,该URL在被拥有者选择时,使得所述授权许可被转发给服务器系统。在从拥有者接收到对第一受保护资源的授权许可之后(响应于拥有者选择URL),通过将接收到的授权许可发送给授权服务器来获得访问令牌。
[0024] 在一种实施例中,受保护资源被托管在资源服务器上,其中服务器系统、授权服务器和资源服务器被实现为支持用于受保护资源的授权的OAuth协议。
[0025] 以下为了说明起见参考例子描述了本公开内容的若干个方面。但是,相关领域的技术人员将认识到,本公开内容可以在没有一个或多个具体细节的情况下或者利用其它方法、部件、材料等来实践。在其它实例中,没有详细示出众所周知的结构、材料或操作,以避免模糊本公开内容的特征。此外,所描述的特征/方面可以以各种组合来实践,但是为了简洁起见,本文只描述了其中的一些组合。
[0026] 2.示例环境
[0027] 图1是示出其中可以实现本公开内容的若干个方面的示例环境的框图。框图被示为包含终端用户系统110A-110Z、互联网120、内联网130、服务器系统140A-140C、SOA(面向服务的体系架构)服务器150、授权服务器170和数据存储库180。
[0028] 仅仅为说明起见,在图中只示出代表性数量/类型的系统。取决于环境被设计用于的目的,许多环境通常包含在数量上和类型上都更多的系统。此外,假定企业的系统按照OAuth标准协议(如在标题为“The OAuth 2.0Authorization Framework”的RFC 6749中详细描述的)来实现,但是其它类似的协议也可以在替代的实施例中被使用。图1的每个系统/设备在以下进行更详细地描述。
[0029] 内联网130表示提供服务器系统140A-140C、SOA服务器150、授权服务器170和数据存储库180之间的连接性的网络,所有这些服务器和数据存储库都在企业内(用虚线边界示出)被提供。互联网 120延伸了这些(以及企业的其它系统)与诸如终端用户系统110A- 110Z的外部系统的连接性。内联网140和互联网120中的每一个可以利用在相关领域中众所周知的、诸如传输控制协议(TCP)和/或互联网协议(IP)的协议来实现。一般而言,在TCP/IP环境中, IP报文被用作传输的基本单位,其中源地址被设置为分配给报文从其发起的源系统的IP地址,并且目的地地址被设置为报文将被最终交付到的目的地系统的IP地址。
[0030] 当报文的目的地IP地址被设置为目的地系统的(IP)地址时, (IP)报文被称为定向到目的地系统,使得报文最终通过网络110被交付到目的地系统。当报文包含诸如指定目的地应用的端口号的内容时,报文也可以被称为被定向到这种应用。可能需要目的地系统保持对应的端口号可用/打开,并且利用对应的目的地端口处理报文。互联网120和内联网130中的每一个可以利用基于导线或无线的介质的任意组合来实现。
[0031] 数据存储库180表示通过在诸如服务器系统140A-140C、SOA 服务器150和授权服务器170的企业其它系统中执行的应用来促进一组数据的存储和取回的非易失性(永久)储存器。数据存储库180可以利用关系数据库技术实现为数据库服务器,并且相应地利用诸如 SQL(结构化查询语言)的结构化查询提供数据的存储和取回。可替代地,数据存储库180可以被实现为以组织为一个或多个目录的文件的形式提供数据的存储和取回的文件服务器,如在相关领域中众所周知的。
[0032] 终端用户系统110A-110Z中的每一个表示诸如个人计算机、工作站、移动站、移动电话、计算平板电脑等由用户使用来生成和发送定向到(directed to)企业的特定系统的用户请求的系统。用户请求可以利用适当的用户界面(例如,由在企业中执行的应用提供的网页) 来生成。例如,用户可以将用于执行各种任务的用户请求发送给在服务器系统140A-140C中执行的应用。可替代地,用户/拥有者可以通过将用户请求经由互联网120发送给企业的系统来管理(创建、删除、授权/拒绝访问)感兴趣的各种资源。
[0033] 每个服务器系统140A-140C都表示诸如web/应用服务器的、能够保护和提供对企业中的资源的访问的服务器(并因此表示第二方)。一些受保护资源(诸如应用、由应用提供的网页等)可以托管在服务器系统上。可替代地,受保护资源(例如,个人数据、诸如图像或视频的媒体等)可以托管在后端存储系统(未示出)中,其中这些资源的访问由服务器系统来控制。为了说明起见,受保护资源被示为托管在企业内(虚线边界)。但是,本公开内容的特征可以在其中受保护资源可能在企业外部的系统(未示出)中托管的可替代实施例中实现 (其中资源经由互联网120来访问),如通过阅读本文的公开内容对相关领域技术人员将显而易见的。
[0034] 应用服务器160表示诸如web/应用服务器的、能够执行可能希望访问一些受保护资源(在企业内托管)的第三方应用的服务器。第三方应用可能需要访问受保护资源用于处理(例如,从终端用户系统 110A-110Z接收到的)用户请求。在一种实施例中,第三方应用被设计为与授权服务器170一起操作,用于执行受保护资源的授权。当成功授权时,第三方应用可以重复地访问授权的受保护资源并且处理用户请求。
[0035] 授权服务器170表示诸如服务器的、促进受保护资源的授权(由拥有者/用户)并且从而使第三方/应用能够处理需要对资源重复访问的请求的系统。如上所述,授权服务器170和企业的其它系统(诸如服务器系统140A-140C、应用服务器160和数据存储库180)被实现为根据OAuth协议执行资源的授权。其中可以执行受保护资源的这种授权的方式在以下利用例子进行描述。
[0036] 3.受保护资源的授权
[0037] 图2是示出其中在一种实施例中在图1的环境中根据OAuth协议实现受保护资源的授权的方式的序列图。该描述通过假定在应用服务器160中执行的第三方应用210需要访问在服务器系统140B中托管的受保护资源而继续,该受保护资源被使用终端用户系统110A的拥有者/用户所拥有。虽然为了说明起见,该描述根据OAuth协议来提供,但是应该理解,特征可以与如在相应的环境中适合的其它类似的授权协议一起来实现。
[0038] 第三方应用210被示为将授权请求发送给由拥有者所使用的终端用户系统110A(事件220)。授权请求可以指示受保护资源的详细信息、请求资源的第三方应用、所需要的访问数量/持续时间等。作为响应,用户/拥有者可以指定第三方应用对所请求的受保护资源的访问权限(查看、修改、用于访问的过期期限等)(一般而言,授权),并且随后发送指示授权许可的响应(事件230)。授权许可可以指示由用户/拥有者指定的权限。
[0039] 虽然没有示出,但是可以理解,在提供授权之前,可能需要用户 /拥有者向第二方(诸如保护资源的服务器系统140B)认证他/她自己。用户的认证(即,建立用户的身份)可以利用适当的认证技术来执行,诸如利用用户ID和密码的组合,如现有技术中众所周知的。在成功认证之后,用户可以指定期望的访问权限作为授权许可的一部分。认证和授权可以利用由第二方提供的适当的用户界面来执行。
[0040] 第三方应用210然后将授权许可发送给授权服务器170(事件 240),该授权服务器170继而生成与授权许可对应的访问令牌并且发送生成的访问令牌作为对授权许可的响应(事件250)。访问令牌可以指示(通常,以加密形式)请求访问的第三方应用的详细信息、受保护资源、以及由资源的拥有者指定的特定访问权限(包括任何过期期限)。
[0041] 第三方应用210随后将访问令牌发送给服务器系统140B即托管资源的资源服务器(事件260),并且相应地被提供对受保护资源的访问(事件270)。可以理解,在生成访问令牌之后,访问令牌随后可以用于对受保护资源的重复访问(假定访问令牌没有过期)。第三方应用210可以将从授权服务器接收到的访问令牌存储在数据存储库 180中,以便促进对受保护资源的重复访问。
[0042] 因此,促进了第三方软件(210)基于由拥有者提供的授权代表拥有者对受保护资源的重复访问。至少在这种基于OAuth协议的方法中,可以理解,访问令牌的生成需要拥有者的主动参与,即需要拥有者“在现场/在线”,以便提供必要的授权。
[0043] 因此,当执行多个请求的批处理时,存在一些挑战。如在相关领域中众所周知的,(在不同的先前时间实例接收到的)多个请求一起 (在以后的时间实例)成批处理通常在后台执行,而无需任何用户交互(与“在现场/线上”执行相比)。这种方法在包含大量(数千的级别)的用户/拥有者的大规模环境(诸如图1的企业)中,以及其中用户/拥有者通常在第三方软件的执行期间被动态添加的情况下也是不可行的。此外,访问令牌的撤销/过期会需要访问令牌的重新生成。
[0044] 根据本公开内容的若干个方面提供的SOA服务器150执行需要资源拥有者对资源的重复访问进行授权的请求的批处理,同时克服了以上所述的一些缺点。如众所周知的,SOA服务器表示通过执行适当的业务流程处理请求的服务器系统。执行的业务流程的一些活动被实现为对由服务器系统140A-140C暴露的一个或多个web服务(受保护资源)的调用,其中暴露的web服务属于不同的拥有者。其中 SOA服务器150执行需要对这种受保护资源/web服务访问的请求的批处理的方式在以下利用例子进行描述。
[0045] 4.请求的批处理
[0046] 图3是示出其中根据本公开内容的方面促进第三方执行需要资源拥有者对资源的重复访问进行授权的请求的批处理的方式的流程图。该流程图相对于图1的系统(尤其是,SOA服务器150)进行描述,这仅仅为了说明起见。但是,在不脱离本公开内容的各方面的范围和精神的情况下,这些特征也可以在其它系统和环境中实现,如通过阅读本文所提供的公开内容对相关领域技术人员将显而易见的。
[0047] 此外,一些步骤可以以与以下所绘出的不同的顺序执行,如适于特定环境的那样,这对相关领域技术人员将显而易见。可以设想许多由本公开内容的若干个方面所覆盖的此类实现。流程图开始于步骤 301,其中控制立即传递到步骤310。
[0048] 在步骤310中,SOA服务器150接收用于成批处理的多个请求。这些请求可以在相当长持续时间上(例如,一天)分布的不同先前时间实例从终端用户系统110A-110Z接收,其中被缓冲用于处理的请求在稍后的时间实例开始。
[0049] 在步骤320中,SOA服务器150选择要被处理的下一个请求,所选择的请求需要由拥有者拥有的受保护资源(例如,web服务)。下一个请求的选择可以基于预定的选择标准以任何方便的方式来执行。选择标准包括例如接收到的时间实例、请求的优先级等。受保护资源可以被服务器系统140B-140C托管和/或保护。
[0050] 在步骤330中,SOA服务器150检查授权代表拥有者访问受保护资源的访问令牌是否存在。检查可通过检查指示之前生成的(并且还未过期/撤销)的访问令牌的凭证数据来执行。因为访问令牌内容由OAuth协议来定义,因此检查操作按照该协议的规范。如果用于所需受保护资源的访问令牌存在,则控制传递到步骤380,否则传递到步骤350。
[0051] 在步骤350中,SOA服务器150发送讯息到拥有者,用于异步授权对受保护资源的访问。如上所述的任何必要的认证等可以作为这种异步授权的一部分来执行。
[0052] 词语“异步”意味着不需要拥有者基本上立即地对讯息做出响应 (如在同步/在线响应模式下将需要的),而是可以在以后方便的时间(例如,在几个小时/天内等)做出响应。虽然讯息在以下描述的实施例中被描述为是URL,但是替代的方法可以采用代码片段(例如,小应用程序),如通过阅读本文所提供的公开内容对熟练的技术人员将显而易见的。
[0053] 在步骤360中,在拥有者提供异步授权时,SOA服务器150接收对受保护资源的授权许可。在步骤370中,类似于图2的事件240 和250,通过将授权许可发送给授权服务器170SOA服务器150获得访问令牌。应当理解,步骤350、360和370在离线模式下执行,即,无需拥有者在现场/在线。
[0054] 在步骤380中,SOA服务器150通过利用之前存在的/获得的访问令牌访问受保护资源来处理下一个请求(类似于图2的事件260和 270)。在步骤390中,SOA服务器150确定是否需要更多的请求在该批次中进行处理。如果存在更多的请求(并且相应地下一个请求被处理),则控制传递到步骤320,否则传递到步骤399。流程图在步骤399中结束。
[0055] 因此,SOA服务器150执行需要资源拥有者对资源的重复访问进行授权的请求的批处理。其中SOA服务器150可以执行根据图3 的请求的批处理的方式在以下利用例子进行说明。
[0056] 5.说明性例子
[0057] 图4A-图4C一起示出了其中在一种实施例中促进了第三方执行需要资源拥有者对资源的重复访问进行授权的请求的批处理的方式。在以下详细描述每个图。
[0058] 图4A示出了在一种实施例中执行需要资源拥有者对资源的重复访问进行授权的请求的批处理的服务器(SOA服务器150)的示例实现。概括地说,前端订单应用(未示出)生成对产品的订单并且将生成的订单存储在非易失性存储中(例如数据存储库180中的订单数据410)。然后由在SOA服务器150中执行的业务流程(订单处理器 420)成批处理这些订单。
[0059] 作为处理订单的一部分被执行的活动之一代表(下订单的)客户组织利用订单的当前状态(例如,“订单已接收”、“订单处理已开始”、“发票已生成”,等等)定期地更新个人网站(例如Twitter[ TM])。假定个人网站允许用户创建各种账户并且张贴信息到这些账户上。其他用户(追随者)可以追随期望的账户,从而追随者自动地接收这些期望账户的消息。
[0060] 因此,为了使SOA服务器150能够张贴订单状态(并因此对客户组织的账户的追随者提供所需的定期更新),需要向SOA服务器 150提供客户组织的账户的授权。换句话说,账户被视为要代表客户组织来访问的受保护资源。如可以理解的,以上描述的OAuth被一般地设计为向第三方提供这种访问。但是,当请求被成批处理时,存在若干个挑战,其中的一些在以上指出。
[0061] SOA服务器150解决这些挑战中的至少一些,如以下相对于图 4A和4B详细描述的。
[0062] (在一种实施例中,在数据存储库180中维护的)订单数据410 指定要求要被成批处理的(由前端订单应用生成和存储的)请求/订单的详细信息。订单处理器420表示在SOA服务器150中执行的业务流程,并且订单处理器420被启用来执行订单的批处理。作为业务流程的一部分,订单处理器420被设计为调用由服务器系统140C暴露的目标(web)服务480来利用处理订单的当前状态更新个人网站上的客户账户。
[0063] 相应地,订单处理器420响应于从接收到的(在订单数据410中维护的)订单中选择订单/请求,首先与凭证检查器430接口,以确定用于目标服务器480的访问令牌是否已经存在。凭证检查器430检查凭证数据460来确定(用于使订单处理器420能够访问个人网站上的客户账户的)访问令牌是否存在。其中凭证数据可以被维护并且用于在离线模式下获得访问令牌的方式将在以下利用例子进行描述。
[0064] 6.凭证数据
[0065] 图4B和图4C绘出了在一种实施例中在不同的时间实例维护的凭证数据(460)的相应部分。为了说明起见,假定凭证数据也(连同订单数据410一起)存储在实现为数据库服务器的数据存储库180 中。相应地,凭证数据460被示为以表的形式维护在数据库服务器中的数据库中。但是,在可替代实施例中,凭证数据可以利用其它数据结构(诸如树、关联数组等)和/或以诸如XML(可扩展标记语言) 的任何其它格式来维护,如通过阅读本文的公开内容对相关领域技术人员将显而易见的。
[0066] 参考图4B,凭证数据/表460被示为包含五列,其中“用户ID”列指定用户/拥有者的唯一标识符、“访问令牌”列指定已为用户/拥有者生成的访问令牌、“过期日期”列指示直到其访问令牌有效的日期、“请求日期”列指示用于在离线模式下获得访问令牌的讯息被 (SOA服务器150)发送(到拥有者/用户)的日期,并且“状态”列指示访问令牌的当前状态(“有效”、“过期”、“撤销”、“待定”等)。
[0067] 表460的每行指定从对应的用户/拥有者接收到的访问令牌的详细信息。如上所述,访问令牌(以加密的形式)指定请求访问的第三方应用的详细信息、受保护资源、以及由资源的拥有者指定的特定访问权限(包括任何过期期限)。当状态是“有效”并且在“访问令牌”列中的对应值不为空时,访问令牌被认为是存在的。
[0068] 因此,用于受保护资源的不同用户/拥有者的凭证数据(460)由 SOA服务器150来维护。在请求的处理期间,凭证检查器430检查客户的访问令牌是否在表460中存在。
[0069] 在授权订单处理器420代表拥有者访问目标服务480的访问令牌存在的情况下,凭证检查器430将访问令牌转发给订单处理器420。订单处理器420然后利用所提供的访问令牌访问目标服务480,从而利用当前状态更新个人网站上的客户账户。
[0070] 在访问令牌不存在的情况下,凭证检查器430首先将订单的详细信息存储在表460中,详细信息诸如从其获得授权的拥有者/用户、用于授权的请求被发送的时间、状态为“待定”等(如在行490中所示)。凭证检查器430然后将指示(连同诸如用户ID的其它数据一起)发送给目标服务480的拥有者在离线模式下与其通信以获得访问令牌的URL生成器440。响应于该指示,URL生成器440生成URL 并且将其发送给(基于接收到的用户ID确定的)拥有者,其中当该 URL被拥有者异步选择时,使得对受保护资源的授权许可被转发给回调服务450。这种URL可以以任何方便的方式生成。
[0071] 使得用于目标服务480的授权许可被转发给回调服务450的示例 URL格式在以下示出:
[0072] https://domain-name/authrequest?callbackuri=
[0073] 其中,
[0074] “domain-name”是托管第三方应用的企业的域;
[0075] “authrequest”是用来生成授权许可并且在用户/拥有者选择该 URL时被调用的(例如,由服务器系统140或授权服务器170提供的)服务的名称;
[0076] “callbackuri”是指示授权许可要被转发给指定为关键字的值  (“HTTP://domain-name/CredentialCallbackService”)的URI (通用资源标识符)的关键字;
[0077] “CredentialCallbackService”是回调服务(450)的身份;及
[0078] “user-id”是指示为其生成访问令牌的用户/拥有者ID(例如 578578)的关键字。
[0079] URL然后可以以已知的方式交付给拥有者,例如作为发送给拥有者的收件箱的电子邮件消息的一部分、以发送给拥有者的移动设备 (例如,110A)的短消息服务(SMS)消息的形式等。URL随后可以由拥有者在以后的时间实例(异步地)选择,例如(有可能在几天之后),当利用终端用户系统110A从收件箱访问电子邮件时、当在移动设备中查看SMS消息时等。拥有者然后选择该URL、向(托管受保护资源的)服务器系统140执行任何必要的认证、并且然后创建 (指示由拥有者指定的特定授权的)用于目标服务480的授权许可。由于URL的格式,新创建的授权许可被转发给回调服务450。
[0080] 可以理解,在将讯息发送给拥有者之后,订单处理器420不等待对讯息的应答(如在同步通信中将需要的),而是继续处理该批中的选择的订单和/或其它订单。
[0081] 回调服务450接收授权许可,并且然后通过将授权许可发送给授权服务器170获得访问令牌,类似于图2的事件240和250。回调服务450然后将新获得的访问令牌存储为凭证数据460的一部分(图 4C的行495),并且然后通知订单处理器420访问令牌存在。订单处理420随后可以与凭证检查器430接口,以从凭证数据460取回新获得的访问令牌并且处理需要对目标服务480访问的订单。
[0082] 因此,促进了第三方订单处理器420执行需要资源拥有者(第一方)对(由诸如服务器系统140A-140C的第二方托管/保护的)的资源/网络服务的重复访问进行授权的订单/请求的批处理。
[0083] 应当理解,以上描述的特征可以作为硬件、可执行模块和固件的一个或多个的期望组合在各种实施例中实现。继续相对于其中当可执行模块被执行时各种特征可操作的实施例来描述。
[0084] 7.数字处理系统
[0085] 图5是示出其中本公开内容的各个方面通过执行适当的可执行模块可操作的数字处理系统500的详细信息的框图。数字处理系统500 可以对应于SOA服务器150。
[0086] 数字处理系统500可以包含诸如中央处理单元(CPU)510的一个或多个处理器、随机存取存储器(RAM)520、二级存储器530、图形控制器560、显示单元570、网络接口580和输入接口590。除显示单元570之外的所有部件可以通过通信路径550相互通信,其中通信路径550可以包含如在相关领域中众所周知的若干条总线。图5 的部件在以下进一步详细描述。
[0087] CPU 510可以执行存储在RAM 520中的指令,以提供本公开内容的若干个特征。CPU 510可以包含多个处理单元,其中每个处理单元潜在地被设计为用于特定的任务。可替代地,CPU 510可以只包含单个通用处理单元。
[0088] RAM 520可以利用通信路径550接收来自二级存储器530的指令。RAM 520被示为当前包含构成操作环境525和/或其它用户程序 526(诸如数据库软件等)的软件指令。除了操作环境525之外, RAM 520可以包含其它软件程序,诸如设备驱动程序、虚拟机等,其提供用于执行其它/用户程序的(公用)运行时环境。
[0089] 图形控制器560基于从CPU 510接收到的数据/指令向显示单元 570生成显示信号(例如,以RGB格式)。显示单元570包含显示屏来显示由显示信号定义的图像。输入接口590可以对应于键盘和定点设备(例如,触摸垫、鼠标)并且可以用来提供输入。网络接口 580提供到网络的连接性(例如,利用互联网协议),并且可以用来与连接到网络(图1的120和130)的其它系统进行通信。
[0090] 二级存储器530可以包含硬盘驱动器535、闪存存储器536和可拆卸存储驱动器537。二级存储器530可以存储数据(例如,URL的部分)和软件指令(用于实现图3的步骤),这使得数字处理系统 500能够提供根据本公开内容的若干种特征。存储在二级存储器530 中的代码/指令可以或者为了更高的执行速度在被CPU 510执行之前复制到RAM 520,或者可以被CPU 510直接执行。
[0091] 二级存储器530可以包含硬盘驱动器535、闪存存储器536和可拆卸存储驱动器537。数据和指令中的一些或全部可以在可拆卸存储单元540上提供,并且数据和指令可以被读取和由可拆卸存储驱动器 537提供给CPU 510。可拆卸存储单元540可以利用与可拆卸存储驱动器537兼容的介质和存储格式来实现,使得可拆卸存储驱动器537 可以读取数据和指令。因此,可拆卸存储单元540包括其中存储有计算机软件和/或数据的计算机可读(存储)介质。但是,计算机(或一般而言机器)可读介质可以是以其它的形式(例如,不可拆卸的、随机访问的,等等)。
[0092] 在本文档中,术语“计算机程序产品”被用来一般地指代可拆卸存储单元540或安装在硬盘驱动器535中的硬盘。这些计算机程序产品是用于向数字处理系统500提供软件的装置。CPU 510可以取回软件指令,并且执行指令,以提供上述本公开内容的各种特征。
[0093] 如在本文所使用的,术语“存储介质”指存储使机器以特定方式操作的数据和/或指令的任何非临时性介质。这种存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如光盘、磁盘、或固态驱动器,诸如存储存储器530。易失性介质包括动态存储器,诸如RAM 520。存储介质的常见形式包括,例如软盘、柔性盘、硬盘、固态驱动器、磁带、或者任何其它磁性数据存储介质(CD- ROM)、任何其它光学数据存储介质、任何具有孔模式的物理介质、 RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其它存储器芯片或盒式磁带。
[0094] 存储介质与传输介质截然不同但是可以与其结合使用。传输介质参与在存储介质之间传送信息。例如,传输介质包括同轴电缆、铜线和光纤,包括包含总线550的配线。传输介质还可以采取声或光波的形式,诸如在无线电波和红外线数据通信中产生的那些。
[0095] 图6是示出在本公开内容的另一种实施例中用于执行请求的批处理的数字处理系统600的框图。系统600的各个方框可以由硬件、软件或硬件和软件的组合来实现,以实现本公开内容的原理。本领域技术人员应当理解,图6中描述的方框可以被组合或分离到子块中来实现如上所述的本公开内容的原理。因此,本文的描述可以支持本文所描述的功能方框的任何可能的组合或分割或其它定义。
[0096] 如在图6中所示,用于在服务器系统中处理请求的系统600可以包括第一接收单元610、选择单元620、检查单元630、通信单元640 以及处理单元650。第一接收单元610可以接收用于成批处理的多个请求。选择单元620可以从多个请求中选择下一个请求。下一个请求需要由第一拥有者拥有的第一受保护资源。检查单元630可以检查是否存在授权由服务器系统代表第一拥有者对第一受保护资源访问的访问令牌。如果访问令牌不存在,则通信单元640可以在离线模式下与第一拥有者通信来接收访问令牌。处理单元650可以通过利用访问令牌访问第一受保护资源来处理下一个请求。
[0097] 根据本公开内容的实施例,通信单元可以包括:用于发送讯息到第一拥有者用于异步授权对第一受保护资源的访问的发送单元641;用于接收用于第一受保护资源的授权许可的第二接收单元642;以及用于通过将授权许可发送给授权服务器获得访问令牌的获取单元643。
[0098] 根据本公开内容的实施例,讯息可以是电子邮件消息或短消息服务(SMS)消息。
[0099] 根据本公开内容的实施例,讯息可以包括统一资源定位符URL,该URL在被第一拥有者异步选择时,使得授权许可被转发给服务器系统。第二接收单元642可以响应于第一拥有者选择URL而接收授权许可并且授权对第一受保护资源的访问。
[0100] 根据本公开内容的实施例,系统还可以包括用于维护指示为包括第一拥有者在内的拥有者生成的访问令牌的凭证数据的维护单元660。检查可以包括检查凭证数据来确定是否存在用于第一拥有者的访问令牌。
[0101] 根据本公开内容的实施例,第一受保护资源可以被托管在资源服务器上。服务器系统、授权服务器和资源服务器可以被实现为支持用于受保护资源的授权的OAuth协议。
[0102] 根据本公开内容的实施例,服务器系统可以是面向服务的体系架构(SOA)服务器。所述多个请求可以对应于多个订单,使得下一个请求是下一个订单。受保护资源可以是个人网站中的账户。第一拥有者可以是授权对访问账户的管理员。处理单元可以包括用于利用下一个订单的处理的当前状态更新账户的更新单元651。
[0103] 贯穿本说明书对“一种实施例”、“实施例”或类似语言的引用意味着联系该实施例所描述的特定特征、结构或特性包括在本公开内容的至少一种实施例中。因此,贯穿本说明书的短语“在一种实施例中”、“在实施例中”以及类似语言的出现可以,但不一定都指代同一实施例。
[0104] 此外,所描述的本公开内容的特征、结构或特性可以在一种或多种实施例中以任何合适的方式来组合。在以上描述中,提供了许多具体的细节,诸如编程、软件模块、用户选择、网络事务、数据库查询、数据库结构、硬件模块、硬件电路、硬件芯片等的例子,以提供对本公开内容的实施例的透彻理解。
[0105] 8.结束语
[0106] 虽然本公开内容的各种实施例已在上面进行了描述,但是应当理解,它们仅仅是作为例子而不是限制给出的。因此,本公开内容的广度和范围不应当由任何上述示例性实施例限制,而是应当仅根据以下权利要求及其等效物来定义。
[0107] 应当理解,在附件中示出的突出本公开内容的功能和优点的图和/或屏幕截图仅仅为了示例的目的给出。本公开内容是足够灵活的并且可配置的,使得它可以以与附图中所示出的不同的其它方式加以利用。
[0108] 此外,以下摘要的目的是使专利局和公众,一般地并且尤其是本领域中不熟悉专利或法律术语或措辞的科学家、工程师和技术人员能够从粗略检查中快速确定本申请的技术公开内容的本质和精髓。摘要不是要以任何方式作为对本公开内容的范围的限制。