CN104255007A

CN104255007A - Oauth框架

Info

Publication number: CN104255007A
Application number: CN201280058348.5A
Authority: CN
Inventors: V·U·斯瑞尼瓦森; R·安加尔; A·桑德海; S·彼哈特
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2011-09-29
Filing date: 2012-09-28
Publication date: 2014-12-31
Anticipated expiration: 2032-09-28
Also published as: IN2014CN02443A; US8935757B2; WO2013049461A3; WO2013049461A2; US20130086657A1; EP2761522A4; JP6018210B2; US20130086645A1; US9043886B2; CN104255007B; EP2761522B1; EP2761522A2; JP2015501021A

Abstract

一种遵循OAuth标准的框架，涉及可以由多个资源服务器使用的通用OAuth授权服务器，以便确保对存储在那些资源服务器上的资源的访问局限于资源所有者同意的访问。每个资源服务器向OAuth授权服务器登记用于那个资源服务器的元数据，该元数据指示由该资源服务器识别的范围。当代表客户端应用从资源所有者请求同意时，OAuth授权服务器参考这种元数据，使得同意具有适当的范围。当构造要提供给客户端应用在访问资源服务器上的资源时使用的访问令牌时，OAuth授权服务器参考这种元数据。OAuth授权服务器使用这种元数据把所发布的访问令牌映射到那些访问令牌准许访问的范围。

Description

OAUTH框架

优先权要求

本申请按照美国法典第35章119条要求于2011年9月29日提交且标题为“RELYING PARTY AND OAUTH FRAMEWORK”的美国临时专利申请No.61/541,026的优先权。

背景技术

身份管理系统是一种信息系统，或者可以用于企业或跨网络身份管理的一组技术。身份管理描述了系统和企业边界中或者跨系统和企业边界的个人身份、其认证、授权、角色和特权的管理，其目的在于在降低成本、停机时间和重复任务的同时提高安全性和生产力。身份管理的一方面是“单点登录”(Single Sign-on；SSO)。在身份管理领域中特别有用的一个标准是OAuth。

SSO是多个相关但独立的软件系统的访问控制的一个特性。利用这个特性，用户登录一次并且获得对所有系统的访问，而不会在每个系统都被提示再次登陆。反过来，单点登出是使得单个登出动作终止对多个软件系统的访问的特性。由于不同的应用和资源支持不同的认证机制，因此，单点登录在内部翻译成并存储与用于初始认证的凭证比较而言不同的凭证。SSO减少了网络钓鱼成功，因为用户没有被培训成在每个地方都不假思索地输入密码。SSO减小了来自不同用户名和密码组合的密码疲劳。SSO减少了花在为同一个身份重复输入密码上的时间。由于更少数量关于密码的信息技术(IT)服务台电话，SSO减小了IT成本。SSO对系统的进入/退出/访问的所有层次提供了安全性，而没有重新提示用户的不便。SSO还允许对合规性的集中式报告。SSO使用所有其它应用和系统用于认证目的时都使用的集中式认证服务器，并且把这与确保用户不必主动输入其凭证多于一次的技术相结合。

OAuth是用于授权的一种开放式标准。授权的间接效果是认证。OAuth允许用户把存储在一个站点的他们的私有资源(例如，照片、视频、联系人列表等)与另一个站点共享，而不必散发其凭证，作为替代，通常是提供用户名和密码令牌。每个令牌准许对一个具体站点的具体资源访问既定的持续时间。这允许用户准许第三方站点访问他们利用另一个服务提供者存储的信息，而不共享他们的访问许可或者他们的全部数据。例如，令牌可以准许在接下来的两小时访问视频编辑站点来获取来自一个具体相册的视频。

例如，在一个典型的场景下，LinkedIn的用户可以被请求把用户的联系人从Yahoo导入到LinkedIn中的许可。LinkedIn可能想获得这些联系人，以便发送例如邀请用户的每个联系人加入LinkedIn的电子邮件消息。在OAuth之前，这种对许可的请求可以涉及用户向LinkedIn提供用户的Yahoo用户身份和密码的请求。这个信息被请求，使得LinkedIn可以作为那个用户登录到该用户的Yahoo账户中，然后从用户的Yahoo账户获得那个用户的联系人。一般来说，允许LinkedIn(或者任何站点)具有用户的Yahoo(或任何其它站点)身份和密码是个坏主意，因为它准许前者站点不受限制地访问后者站点上用户的账户。这种不受限制的访问几乎总是比前者站点实现其目标，诸如仅仅是获得联系人列表，实际所需多得多的访问。

一个更好的构思是为前者站点提供相对于后者站点上用户帐户的有限授权。有限的授权可以规定前者站点相对于后者站点上用户的帐户能够执行的具体操作集合。例如，参考以上的典型场景，有限的授权可以规定LinkedIn只能访问用户的联系人列表，而不执行关于用户在Yahoo上的账户的其它操作。OAuth允许这种有限的授权。OAuth提供了授权的委托。

OAuth通过其委托授权的技术可以相对于类比来理解。当车主暂时把对他的车的控制转让给服务员使得该服务员可以为车主停车时，车主常常不向服务员提供通用的主钥匙，而是向服务员提供更有限用途的服务员钥匙。服务员钥匙允许服务员具有开车的足够访问，但不向服务员提供对车主在车中所拥有的每件事物的访问。以相同的方式，例如，OAuth的使用可以准许第一个站点访问由第二个站点存储的用户的联系人列表，而不允许第一个站点相对于用户在第二个站点上的账户执行其它操作–诸如读取可能存储在第二个站点上的电子邮件消息。OAuth允许给予第一个站点有限的授权来相对于第二个站点执行规定的操作集合，而且不执行其它操作。

对于另一个例子，用户可能想使用由第一个站点，诸如Snapfish，提供的照片打印服务来打印电子存储在独立于第一个站点的第二个站点，诸如Flickr，上的某些彩色照片。更具体而言，用户可能只想打印存储在Flickr上的特定相册，诸如包含用户最近参观阿拉斯加的照片的相册，当中的照片。虽然用户可以具有存储在其Flickr账户上的多个不同相册，但是用户可能只想打印来自阿拉斯加相册的照片。在这种情形下，用户有可能更想让Snapfish不访问除阿拉斯加相册中所包含的那些照片之外其Flickr相册的任何内容。在前面的场景下，利用OAuth术语，Snapfish被认为是客户端，而Flickr被认为是资源服务器(照片数据是资源)以及OAuth授权服务器。作为由资源服务器存储的资源(例如，照片数据)的所有者，用户也是资源所有者。

给定以上给出的例子，用户可以首先使用他的互联网浏览器应用指引客户端(例如，Snapfish)打印资源服务器(例如，Flickr)上用户阿拉斯加相册中的照片。作为响应，客户端(例如，Snapfish)把用户重定向到资源授权服务器(例如，Flickr)的站点。这种重定向操作可以向资源服务器指示客户端期望访问的有限数据集(例如，阿拉斯加相册的内容)。在那个时候，资源授权服务器不知道用户是谁，因为用户还没有向资源授权服务器认证他自己。因此，资源授权服务器需要用户进行认证。如以上所提到的，授权的间接效果是认证。在用户向资源授权服务器认证他自己之后(例如，通过提供与资源授权服务器相关的用户名和密码)，资源授权服务器向用户的互联网浏览器发送同意页面。该同意页面请用户验证资源授权服务器(例如，Flickr)具有向客户端(例如，Snapfish)提供有限的、规定的数据集合(例如，阿拉斯加相册的内容)的用户许可。假设用户同意，则资源授权服务器作为响应向客户端发送授权码。这个授权码可以通过“前方通道”，或者换句话说，利用重定向经用户的互联网，发送。

在这种场景下，客户端(例如，Snapfish)是授权服务器(例如，Flickr)值得信任的合作者。客户端接收授权码，或“准许”，并且存储该授权码。客户端无限期地维护这个授权码，直到用户主动宣告该授权码无效。用户可以登录到OAuth授权服务器，以便看OAuth授权服务器已经代表用户向各个客户端提供的准许列表。响应于接收授权码，客户端(例如，Snapfish)向授权服务器(例如，Flickr)作出“后方通道”调用。后方通道调用是不涉及用户的互联网浏览器的一种通信。后方通道调用从授权服务器请求访问令牌。访问令牌规定客户端被允许在授权服务器上对用户帐户访问的范围。例如，访问令牌可以指示客户端被允许只访问用户的阿拉斯加相册的内容。授权服务器把所请求的访问令牌经后方通道发送回客户端。客户端存储该访问令牌。其后，直到访问令牌到期，或者直到用户宣告该准许(即，授权码)无效，用户可以向资源服务器呈交该访问令牌，以便访问资源服务器上由该访问令牌规定的资源。如果用户已经宣告关于该访问令牌的准许无效，则，即使该访问令牌还没有到期，该访问令牌也变得无效。

除了访问令牌，授权服务器还可以向客户端提供“刷新令牌”。虽然访问令牌常常具有规定的寿命，在此之后它将过期，但刷新令牌是长期令牌。客户端可以连同相关的访问令牌一起存储刷新令牌。其后，如果资源服务器提出反对，说客户端当前访问令牌已经过期，则客户端可以向资源服务器呈交刷新令牌，以便从资源服务器获得新的访问令牌。

有利地，OAuth采用的方法避免向客户端公开资源服务器上用户帐户的用户密码。这种凭证公开的避免防止客户端相对于用户在资源服务器上的账户执行未授权的动作。用户提供其密码的唯一时间是在从客户端站点重定向之后用户与资源服务器的直接初始认证期间。

发明内容

本发明的实施例涉及身份管理、认证和授权框架。在一种实施例中，提供了用于在企业身份和访问管理(IAM)基础设施中集成互联网身份的框架。根据另一种实施例，提供了用于开放式授权的框架。对于OAuth系统，有许多不同的用例，以至于单一的方法不是总能适合每个用例。因此，本发明的实施例使OAuth系统更灵活。本发明的实施例使OAuth系统更容易让该系统的企业管理员为他们自己的使用来定制。本发明的实施例使OAuth系统更可以由应用和资源提供者定制。

传统上，资源服务器和OAuth授权服务器曾经是同一个实体。根据本发明的一个实施例，提供了把资源服务器从OAuth授权服务器的责任中释放出来的通用框架。这些责任可以包括范围管理、授权令牌的发布、刷新令牌的发布，以及访问令牌的发布。因而，通用OAuth授权服务器可以根据这种通用框架来实现。因此，每个个别的资源服务器不需要实现它自己专属的OAuth授权服务器。实际上，根据本发明的一个实施例，多个不同的资源服务器可以全部都同时使用同一个通用OAuth授权服务器的功能。例如，在本发明的一个实施例中，单个OAuth授权服务器可以完全同时地为几个不同的资源服务器管理范围。在资源服务器和OAuth授权服务器之间可以存在多对一的关系。

在本发明的一种实施例中，为了实现与多个不同资源服务器交互的能力，通用OAuth授权服务器维护指示哪些令牌属于哪些资源服务器、每个资源服务器值得信任的合作者是谁等的映射数据。此外，在本发明的一个实施例中，该通用OAuth框架是以这样一种方式构造的，该方式使得资源服务器管理员可以容易地定制该框架，以适应用于他的资源服务器的特定用例。不同的资源服务器管理员可以把他们的具体部件“插入”通用OAuth框架中。因而，在本发明的一种实施例中，每个资源服务器通知通用OAuth授权服务器关于该资源服务器可能使用的潜在范围(即，相对于资源的有限操作)。

在参考以下说明书、权利要求和附图之后，以上所述连同其它特征和实施例将变得更加显然。

附图说明

图1是根据本发明一个实施例、说明OAuth系统体系架构及其逻辑部件的框图；

图2是根据本发明一个实施例、说明资源服务器环境的框图；

图3是根据本发明一个实施例、说明OAuth客户端环境的框图；

图4是根据本发明一个实施例、说明用于向通用OAuth授权服务器登记第一资源服务器的元数据的技术的流程图；

图5是根据本发明一个实施例、说明用于向OAuth授权服务器登记第二资源服务器的元数据的技术的流程图；

图6是说明根据本发明一个实施例可以使用的系统环境的部件的简化框图；及

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

具体实施例

在以下描述中，为了解释，阐述了具体的细节，以便提供对本发明实施例的透彻理解。但是，将认识到，本发明没有这些具体细节也可以实践。于2011年9月29日提交且标题为“RELYING PARTYAND OAUTH FRAMEWORK”的美国临时专利申请No.61/541,026通过引用被结合于此。

图1是根据本发明一个实施例、说明OAuth系统体系架构100及其逻辑部件的框图。体系架构100包括资源所有者(或用户)102、客户端应用104、资源寄存器106以及资源生态系统110。资源生态系统包括客户端寄存器112、令牌-范围寄存器114、范围寄存器116、用户同意120和资源服务器122。虽然示出了一个资源服务器，但是本发明的实施例可以包括多个独立的资源服务器。如从图1中的连接看到的，客户端应用104和资源寄存器106交互。资源所有者102和资源寄存器106并和客户端寄存器112交互。授权服务器118和客户端寄存器112、令牌-范围寄存器114及用户同意120交互。资源服务器122和令牌-范围寄存器114交互。用户同意120和范围寄存器116交互。各种这些部件及其功能在以下进一步讨论。

本发明的实施例可以涉及授权的委托。不同的资源用例有时候需要不同的范围定义。不同的资源有时候会依赖不同的授权模型和解决方案。会需要不同的具体用户动作来给予客户端应用访问由不同资源服务器维护的同意。优选地，每个不同的资源提供者应当不需要提供独立的专属OAuth授权服务器来和那个资源提供者的细节集成。每个资源提供者提供独立专属OAuth授权服务器的不幸结果将是企业希望和多个不同的资源提供者集成并且多个不同的客户端形式因子将不得不处理无数不同的OAuth授权服务器接口。

因此，在本发明的一个实施例中，提供了通用OAuth框架体系架构。该框架可以包括OAuth有线协议部件(客户端和服务器)，包括元数据和运行时寄存器。该框架可以包括可插拔“合同”的基础设施，以定制并部署特定于应用的解决方案。

在本发明的一种实施例中，资源服务器122在令牌-范围寄存器114中存储资源服务器122识别的范围指示。每个这种范围可以指示相对于资源服务器122上存储的不同资源集合可以执行的不同操作集合。因为某些实施例可以包括多个不同的或独立的资源服务器，所以令牌-范围寄存器114可以存储不同资源服务器和不同范围之间的映射。此外，在本发明的一种实施例中，每个范围映射到令牌-范围寄存器114中一个独立的令牌。因而，通过参考令牌-范围寄存器114，资源服务器122可以确定映射到由客户端应用104向资源服务器122呈交的特定令牌的操作集合以及资源集合。资源服务器122可以关于由资源服务器122维护的资源把客户端应用104执行的操作限定到由映射到该特定令牌的操作集合具体指示的那些操作。

因而，在本发明的一种实施例中，多个资源服务器的组中每个特定的资源服务器向OAuth框架提供不同的元数据集合，元数据集合指示可以映射到可用于访问特定资源服务器上的资源的令牌的范围。因此，范围是可以由资源服务器的管理员定制的，从而使OAuth框架灵活并且适用于许多不同的用例。因此，许多不同类型的资源服务器全都可以使用相同的通用OAuth框架，而无需为每种不同类型的资源服务器创建具体的OAuth框架。

在一个实施例中，图1中所示的通用OAuth框架提供了基本的概念结构。OAuth框架可以叠加在现有的身份管理产品之上。在OAuth框架中，合同可以定义与这些现有产品的集成点。OAuth框架与合同实现的结合可以满足各种各样的用例和部署选项。根据一个实施例，OAuth框架包括两个广义的“角色”：消费者/客户端角色，以及授权服务器/资源服务器角色。授权服务器/资源服务器角色在以下参考图2讨论，而消费者/客户端角色在以下参考图3讨论。

图2是根据本发明一个实施例、说明资源服务器环境200的框图。在本发明的一个实施例中，环境200包括资源所有者(或用户)202、客户端应用204、资源服务器210、OAuth授权服务器220、策略服务240以及令牌服务250。资源服务器210包括资源服务器应用212，该应用包括访问令牌确认API214和门(gate)216。OAuth授权服务器220包括令牌-范围寄存器222、资源&范围寄存器224、用户同意编排(orchestration)226、OPSS-TS(Oracle平台安全性服务-TS)228、OPSS-AZ(Oracle平台安全性服务-AZ)230、OAuth核心引擎232、OAuth协议引擎234以及客户端寄存器236。在一个实施例中，资源所有者202通过门216和客户端应用204交互，其中门216访问访问令牌确认API214。客户端应用204还和OAuth授权服务器220交互。访问令牌确认API214和令牌-范围寄存器222并和策略服务240交互。OPSS-TS和令牌服务250交互。OPSS-AZ和策略服务250交互。部件228-234集合起来和令牌-范围寄存器222并和资源&范围寄存器224交互。用户同意编排226与资源&范围寄存器224交互。

在本发明的一个实施例中，资源&范围寄存器224存储与经OAuth授权服务器220暴露的资源和服务相关的资源信息、范围和各种各样的元数据。在本发明的一个实施例中，客户端寄存器236存储用于被授权的远端客户端(例如，客户端应用204)的信任密钥和秘密。在一个实施例中，令牌-范围寄存器222存储基于用户(例如，资源所有者202)同意而发布给客户端(例如，客户端应用204)的访问令牌和刷新令牌。在一个实施例中，令牌-范围寄存器222存储与所发布的访问令牌相关联的AuthZ范围信息。

在本发明的一个实施例中，资源服务器210向OAuth授权服务器220登记其自己的元数据。不同的资源服务器可以向同一个OAuth授权服务器登记不同的元数据。作为登记过程的一部分，这种元数据导入OAuth授权服务器220。元数据指示由资源服务器210识别，或者暴露，的各种不同范围。每个范围规定由资源服务器210维护的不同资源子集。在本发明的一个实施例中，在登记时，由资源服务器210识别的每个范围映射到(只)资源&范围寄存器224中的资源服务器210。因而，在本发明的一个实施例中，对于每个登记的范围，资源&范围寄存器指示在那个范围内可访问的对应资源服务器的资源集合。范围可以指示，例如，只有一张特定的照片可以被访问，或者一个特定的照片文件夹可以被访问，或者特定的文件夹集合可以被访问。范围可以指示相对于规定的资源被允许的操作，诸如读取、更新、删除、创建，等等。

在本发明的一个实施例中，OAuth授权服务器220向客户端应用204发布访问令牌。在一个实施例中，对于每个这种访问令牌，OAuth授权服务器220在令牌-范围寄存器222中存储访问令牌和指定给那个访问令牌的特定范围(选自资源&范围寄存器224中所存储的范围)之间的映射。用于同一资源服务器的不同访问令牌可以具有指定给它们的不同范围。因而，当客户端应用204向OAuth授权服务器220呈交访问令牌时，OAuth授权服务器220可以参考令牌-范围寄存器222来确定映射到那个访问令牌的范围，然后可以参考资源&范围寄存器224来确定在那个范围内可访问的资源。

在本发明的一个实施例中，为了让OAuth授权服务器220向客户端应用204准许访问令牌，需要来自资源所有者202的用户同意。例如，如果客户端应用204请求对来自资源服务器210的特定资源(或者包括那个资源的特定范围)的访问，则资源服务器210可以把该请求重定向到OAuth授权服务器220。OAuth授权服务器220可以调用用户同意编排226，以便请求资源所有者202验证客户端应用204应当被准许访问该特定的资源(或特定的范围)。在一个实施例中，用户同意编排226向资源所有者202指示客户端应用204寻求访问的范围，并且向资源所有者202提供同意或拒绝对那个范围的访问的机会。更具体而言，OAuth授权服务器220可以请求资源所有者220验证客户端应用204应当被准许对由包括特定资源的特定范围规定的访问(如在资源&范围寄存器224中所指示的)。响应于从资源所有者202接收到同意，OAuth授权服务器220可以生成访问令牌并且在令牌-范围寄存器222中存储那个访问令牌和该特定范围之间的映射。OAuth授权服务器220可以向客户端应用204提供该访问令牌。

然后，通过向资源服务器应用212呈交访问令牌，客户端应用204可以尝试访问资源服务器210上的特定资源。资源服务器应用212上的代理可以截获令牌并且在允许客户端应用204访问特定资源之前利用OAuth授权服务器220确认该令牌(例如，经访问令牌确认API214)。如果客户端应用204尝试访问的特定资源不在映射到令牌-范围寄存器222中的访问令牌的范围内(例如，如果客户端应用204尝试访问在资源所有者202之前同意访问的范围之外的文件夹)，则OAuth授权服务器220将不确认该令牌，并且资源服务器210将拒绝准许客户端应用204访问特定的资源。因为，访问的范围是基于资源所有者202对那个范围的具体同意。资源所有者202有机会拒绝向客户端应用204所请求的具体范围给予同意，在这种情况下，OAuth授权服务器220将不为客户端应用204创建访问令牌。在本发明的一种实施例中，每个客户端应用访问由资源服务器210维护的资源的请求还规定映射到资源&范围寄存器224中的资源服务器210的范围，并且就是为这个规定的范围请求资源所有者202的同意，如以上所讨论的。

根据本发明的一个实施例，与以上所讨论的一致，在客户端应用204向资源服务器210呈交访问令牌的时候，访问约束的强制执行发生。强制执行需要对由访问令牌编码的范围的理解。访问令牌是由OAuth授权服务器220经范围定义发布的。访问令牌经由所发布的令牌编码的范围来确认。在本发明的一种实施例中，策略服务240和令牌服务250相结合来维护所发布的访问令牌的状态并且授权所发布的访问令牌。在本发明的一个实施例中，消费者(即，资源服务器210的运营者和/或所有者)可以提供其自己的策略服务240和令牌服务250。OAuth框架可以提供编程合同或编程接口，通过这些合同或接口，这种消费者可以把他们自己的策略和令牌服务以匹配那些消费者定义的范围的方式插入到OAuth框架中。每个消费者可以公布它自己的范围集合。所公布的范围集合可以指示消费者的令牌服务将返回的数据的形式。OAuth框架附加地可以向这种消费者提供允许策略在令牌发布时创建的编程合同或编程接口。这些编程合同或编程接口允许消费者把他们自己的定制编程代码插入OAuth框架。利用这些编程接口，消费者可以把其现有的基础设施连接到OAuth系统中。在一个实施例中，公布其范围集合的消费者负责确保其令牌和/或策略服务返回包括与所公布范围一致的范围信息的令牌。响应于客户端应用204尝试使用令牌，OAuth授权服务器220可以调用将查找消费者的策略并确认那个令牌的应用编程接口(API)。

在一个实施例中，OAuth框架规定消费者的代码(例如，用于令牌服务250和策略服务240的代码)为了与OAuth授权服务器220接口而需要实现的接口。该接口可以公布，使得消费者意识到每个接口期望接收的参数以及每个接口期望返回的值。当客户端应用204对OAuth授权服务器220作出请求时，OAuth授权服务器220对与那个请求相关的API作出响应性调用。例如，这些调用可以涉及对例如生成访问令牌并且把那些访问令牌提供给客户端应用204的消费者编码的部件的调用。在本发明的一种实施例中，OAuth授权服务器220以OPSS-TS228和OPSS-AZ230的形式暴露以上提到的编程合同或编程接口。消费者自己对令牌服务250的实现可以与OPSS-TS228接口，而消费者自己对策略服务240的实现可以与OPSS-AZ230接口。OAuth授权服务器220可以调用独立的API，来进行访问令牌的创建和访问令牌的确认。消费者可以实现执行每个任务的定制编程代码。在确认期间，在令牌创建过程中构造的策略可以被访问，以确定客户端应用204相对于资源寻求执行的动作是否匹配通过客户端应用204呈交的访问令牌编码的策略。

此外，在本发明的一种实施例中，消费者自己对用户同意编排226的实现可以插入到OAuth授权服务器220中，其中用户同意编排226在客户端应用204寻求来自OAuth授权服务器220的访问令牌时被调用。到资源&范围寄存器224和令牌-范围寄存器222的接口可以向消费者提供，使得消费者可以设计其对用户同意编排226的实现，以便从部件222和224获得在构造同意请求时使用的数据。

在本发明的一个实施例中，存储在资源&范围寄存器224中的映射不仅指示包括在每个范围中的资源子集，并且指示被允许由客户端应用相对于那些资源子集执行的排他性操作子集。例如，特定的映射可以指示读取和更新操作但是无创建或删除操作可以相对于资源服务器210上维护的资源(例如，文件、文件夹、目录、列表、简档、图像、文档等)的规定子集执行的特定范围。因而，在本发明的一种实施例中，以上所讨论的同意请求不仅规定与一个范围关联的资源子集，并且规定与那个范围关联的操作子集。因此，资源所有者202精确地知道他同意客户端应用204相对于在同意请求所规定范围内的资源子集执行的操作的种类。

根据本发明的一个实施例，客户端应用204请求等效于资源服务器210已经向OAuth授权服务器220登记的具体范围之一的资源访问。因而，在本发明的一种实施例中，客户端应用204利用意识到将为资源服务器210登记的具体范围来设计。因为客户端应用204可以和由各个不同资源服务器维护的资源交互，所以各个资源服务器的供应者可以对它们的资源服务器将向OAuth授权服务器220登记的标准范围集合取得一致，由此减轻设计者对客户端应用204和其它客户端应用的设计任务。

在本发明的一种实施例中，提供了客户端框架，以便允许客户端应用，诸如客户端应用204，实现用于各种不同类型资源提供者的“钩子”。例如，客户端应用204可以为Google、Facebook、Yahoo、LinkedIn等实现独立的钩子。图3是根据本发明一个实施例、说明OAuth客户端环境300的框图。OAuth客户端环境300包括资源所有者302、资源服务器304、OAuth授权服务器306、客户端应用308以及OAuth客户端320。客户端应用308包括OAuth客户端API310。OAuth客户端320包括OAuth客户端引擎322、资源寄存器324、本地应用寄存器326以及令牌寄存器328。资源服务器304和OAuth授权服务器306彼此交互。资源服务器304和OAuth客户端320彼此交互。OAuth授权服务器306和OAuth客户端320经资源所有者302(例如，通过由资源所有者302的互联网浏览器实现的重定向)彼此交互。资源所有者302还和客户端应用308交互。客户端应用308通过OAuth客户端API310和OAuth客户端引擎322交互。OAuth客户端引擎322和资源寄存器324、本地应用寄存器326及令牌寄存器328交互。

根据本发明的一个实施例，关于客户端应用308可以与之交互的所有不同类型的资源服务器的元数据都存储在资源寄存器324中，使得客户端应用308能够与各种不同的资源服务器交互。资源寄存器可以指示，例如，由每个不同类型资源服务器识别的不同范围集合。因此，客户端应用308能够请求对应于由资源服务器304识别的特定范围的访问，并且这个特定的范围可以在OAuth授权服务器306代表客户端应用308发送到资源所有者302的同意请求中规定。资源提供者可以公布他们与OAuth标准兼容的范围规范，使得设计者可以利用用于那些提供者的资源服务器的适当服务器到范围映射来填充资源寄存器308。在一个实施例中，因为资源寄存器308可以独立于客户端应用308来填充，所以客户端应用308不需要为了与新发现的资源服务器交互而修订；相反，开发者可以简单地把用于那些资源服务器的新映射“插入”客户端应用308与之交互的资源寄存器324中。

充当资源提供者或服务器的复杂网站常常不是整体式的应用。相反，复杂的网站常常由多个不同的应用组成。在本发明的一个实施例中，本地应用寄存器326存储各个不同资源提供者和由那些资源提供者提供或暴露的应用集合之间的映射。每个这种应用都可以在本地应用寄存器326中映射到用于那个应用的独立的统一资源定位器(URL)。在本发明的一种实施例中，本地应用寄存器326存储信任密钥，以行使(exercise)访问远端资源的OAuth客户端角色。

通常，客户端应用308能够使用一个特定的访问令牌多次，以便在那个特定的访问令牌到期之前访问由资源服务器304维护的资源。在本发明的一个实施例中，客户端应用308从OAuth授权服务器306获得的访问令牌存储在令牌寄存器328中。因为客户端应用308可以与多个不同的资源服务器交互，所以令牌寄存器328可以维护访问令牌和与那些访问令牌有关的不同资源服务器之间的映射。令牌寄存器328可以存储用于各种不同远端资源服务器(例如，资源服务器304)以及范围的访问令牌和刷新令牌。

图4是根据本发明一个实施例、说明用于向通用OAuth授权服务器登记第一资源服务器的元数据的技术400的流程图。虽然技术400涉及某些方框或操作，但是备选实施例可以涉及比所说明的那些更多、更少或不同的操作。此外，备选实施例可以涉及以与所说明次序不同的次序对操作的执行。在方框402中，OAuth授权服务器从第一资源服务器接收指示由第一资源服务器识别的第一范围集合的第一元数据集合。在方框404中，响应于接收到第一元数据集合，OAuth授权服务器存储第一范围集合中的范围和由第一资源服务器维护的资源子集之间的映射。在一种实施例中，响应于接收到第一元数据集合，OAuth授权服务器存储特定范围、由第一资源服务器存储的资源子集和映射到该特定范围的特定令牌的持有者被允许相对于第一资源子集中的资源执行的操作集合之间的映射。

在方框406中，OAuth授权服务器接收规定来自第一范围集合的第一范围的特定请求。在方框408中，响应于接收到规定该第一范围的请求，OAuth授权服务器请求包含在该第一范围中的资源的所有者同意准许与第一范围一致的客户端应用访问。在方框410中，响应于从所有者接收到同意，OAuth授权服务器(a)创建第一访问令牌，(b)存储第一访问令牌和第一范围之间的映射，并且(c)向客户端应用发送第一访问令牌。在一种实施例中，响应于从所有者接收到同意，OAuth授权服务器调用由不提供OAuth授权服务器的消费者(例如，第一资源服务器的所有者)提供的编程代码。该编程代码实现由OAuth授权服务器的提供者提供给消费者的接口。该编程代码创建第一访问令牌。

在方框412中，OAuth授权服务器从第一资源服务器接收确认第一访问令牌的请求。在方框414中，响应于接收到确认第一访问令牌的请求，OAuth授权服务器基于第一访问令牌和第一范围之间的映射确认第一访问令牌。在一种实施例中，为了确认第一访问令牌，OAuth授权服务器调用由不提供OAuth授权服务器的消费者(例如，第一资源服务器的所有者)提供的编程代码。该编程代码实现由OAuth授权服务器的提供者提供给消费者的接口。该编程代码确认第一访问令牌。

在方框416中，响应于确认第一访问令牌，OAuth授权服务器向第一资源服务器指示向第一资源服务器呈交第一访问令牌的客户端应用被授权相对于由第一资源服务器维护并由第一范围规定的资源集合执行操作。

图5是根据本发明一个实施例、说明用于向通用OAuth授权服务器登记第二资源服务器的元数据的技术的流程图。虽然技术500涉及某些方框或操作，但是备选实施例可以涉及比所说明的那些更多、更少或不同的操作。此外，备选实施例可以涉及以与所说明次序不同的次序对操作的执行。在方框502中，OAuth授权服务器从与第一资源服务器(在图4中引用)分开的第二资源服务器接收指示由第二资源服务器识别的第二范围集合的第二元数据集合，该第二范围集合与第一范围集合(在图4中引用)不同。在方框504中，响应于接收到第二元数据集合，OAuth授权服务器存储第二范围集合中的范围和由第二资源服务器维护的资源子集之间的映射。在方框506中，OAuth授权服务器存储第二访问令牌和来自第二范围集合的第二范围之间的映射。在方框508中，OAuth授权服务器从第二资源服务器接收确认第二访问令牌的请求。在方框510中，响应于接收到确认第二访问令牌的请求，OAuth授权服务器基于第二访问令牌和第二范围之间的映射确认第二访问令牌。在方框512中，响应于确认第二访问令牌，OAuth授权服务器向第二资源服务器指示向第二资源服务器呈交第二访问令牌的客户端应用被授权相对于由第二资源服务器维护并由第二范围规定的资源集合执行操作。

图6是说明可以根据本发明的一个实施例使用的系统环境600的部件的简化框图。如所示出的，系统环境600包括一个或多个客户端计算设备602、604、606、608，这些客户端计算设备配置为操作诸如web浏览器、专属客户端(例如，Oracle Forms)等的客户端应用。在各种实施例中，客户端计算设备602、604、606、608可以和服务器612交互。

客户端计算设备602、604、606、608可以是通用个人计算机(作为例子，包括运行各种版本的Microsoft Windows和/或AppleMacintosh操作系统的个人计算机和/或膝上型计算机)、智能电话或PDA(运行诸如Microsoft Windows Mobile的软件并且启用Internet、电子邮件、SMS、Blackberry或其它通信协议)，和/或运行各种商业可用的UNIX或像UNIX的操作系统(包括但不限于各种GNU/Linux操作系统)中任何一种的工作站计算机。作为替代，客户端计算设备602、604、606、608可以是能够经网络(例如，以上所述的网络610)通信的任何其它电子设备，诸如瘦客户端计算机、启用互联网的游戏系统，和/或个人发消息设备。虽然示例性系统环境600示为具有四个客户端计算设备，但是任意数量的客户端计算设备都可以被支持。诸如带传感器的设备等的其它设备可以和服务器612交互。

系统环境600可以包括网络610。网络610可以是本领域技术人员熟悉的、可以利用各种商业可用的协议中任何一种支持数据通信的任何类型的网络，包括但不限于TCP/IP、SNA、IPX、AppleTalk等。仅仅是作为例子，网络610可以是局域网(LAN)，诸如以太网、令牌环网等；广域网；虚拟网，包括但不限于虚拟专用网(VPN)；互联网；内联网；外联网；公共交换电话网(PSTN)；红外线网络；无线网络(例如，在本领域中已知的IEEE802.11协议套件、蓝牙协议和/或任何其它无线协议下运行的网络)；和/或这些和/或其它网络的任意组合。

系统环境600还包括一个或多个服务器计算机612，这可以是通用计算机、专用服务器计算机(作为例子，包括PC服务器、UNIX服务器、中档服务器、大型计算机、机架式服务器等)、服务器场、服务器集群，或者任何其它适当的布置和/或组合。在各种实施例中，服务器612可以适于运行前面公开内容中所描述的一个或多个服务或软件应用。例如，服务器612可以对应于根据本发明的一个实施例用于执行依赖方和开放式授权处理的服务器。

服务器612可以运行包括以上讨论的那些当中任何一个以及任何商业可用的服务器操作系统的操作系统。服务器612还可以运行各种附加的服务器应用和/或中间层应用中任何一种，包括HTTP服务器、FTP服务器、CGI服务器、Java服务器、数据库服务器等。示例性数据库服务器包括但不限于从Oracle、Microsoft、Sybase、IBM等可商业获得的那些服务器。

系统环境600还可以包括一个或多个数据库614、616。数据库614、616可以驻留在各个位置。作为例子，数据库614、616中的一个或多个可以驻留在服务器612本地的非临时性存储介质中(和/或驻留在服务器612中)。作为替代，数据库614、616可以远离服务器612，并且经基于网络的或者专用的连接与服务器612通信。在一组实施例中，数据库614、616可以驻留在本领域技术人员熟悉的存储区域网络(SAN)中。类似地，用于执行属于服务器612的功能的任何必要的文件都可以适当地本地存储在服务器612上和/或远端存储。在一组实施例中，数据库614、616可以包括适于响应于SQL格式化的命令而存储、更新和检索数据的关系数据库，诸如由Oracle提供的数据库。

图7是可以根据本发明实施例使用的计算机系统700的简化框图。例如，服务器602可以利用诸如系统700的系统实现。计算机系统700示为包括可以经总线724电耦合的硬件元件。硬件元件可以包括一个或多个中央处理单元(CPU)702、一个或多个输入设备704(例如，鼠标、键盘等)，以及一个或多个输出设备706(例如，显示设备、打印机等)。计算机系统700还可以包括一个或多个存储设备708。作为例子，存储设备708可以包括诸如盘驱动器、光学存储设备以及诸如随机存取存储器(RAM)和/或只读存储器(ROM)的固态存储设备的设备，这些设备可编程、可闪存更新(flash-updateable)等。

计算机系统700可以附加地包括计算机可读存储介质读取器712、通信子系统714(例如，调制解调器、网卡(无线或有线)、红外线通信设备等)，以及可以包括如上所述RAM和ROM设备的工作存储器718。在有些实施例中，计算机系统700还可以包括处理加速单元716，这可以包括数字信号处理器(DSP)、专用处理器等。

计算机可读存储介质读取器712还可以连接到计算机可读存储介质710，一起(并且，可选地，结合存储设备708)综合地代表远端、本地、固定和/或可移除的存储设备外加用于暂时地和/或更持久地包含计算机可读信息的存储介质。通信系统714可以允许数据利用网络1610和/或以上关于系统环境1600所述的任何其它计算机交换。

计算机系统700还可以包括软件元件，示为目前位于工作存储器718中，包括操作系统720和/或其它代码722，诸如应用程序(可以是客户端应用、Web浏览器、中间层应用、RDBMS等)。在示例性实施例中，工作存储器718可以包括可执行代码和用于如上所述依赖方和开放式授权相关的处理的相关联数据结构。应当认识到，计算机系统700的备选实施例可以具有与以上所述不同的多种变化。例如，定制的硬件也可以使用和/或特定的元件可以在硬件、软件(包括便携式软件，诸如小应用程序(applet))或者二者当中实现。另外，可以采用到诸如网络输入/输出设备的其它计算设备的连接。

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

虽然已经描述了本发明的具体实施例，但是各种修改、变更、备选构造和等价物也包含在本发明的范围内。本发明的实施例不限于某些具体数据处理环境中的操作，而是自由地在多种数据处理环境中操作。此外，虽然本发明的实施例已经利用特定的事务和步骤序列进行了描述，但是本领域技术人员应当认识到，本发明的范围不限于所述的事务和步骤序列。

另外，虽然本发明的实施例已经利用硬件和软件的特定组合进行了描述，但是应当认识到，硬件和软件的其它组合也在本发明的范围内。本发明的实施例可以只在硬件中、只在软件中或者利用其组合来实现。

相应地，说明书和附图应当在说明性而不是约束性的意义上看待。但是，很显然，在不背离最广泛主旨和范围的情况下，可以对其进行增加、减少、删除及其它修改和变化。

背景技术

本发明的实施例涉及身份管理、认证及授权框架。

简要概述

本发明的实施例涉及身份管理、认证及授权框架。在一种实施例中，提供了用于在企业身份和访问管理(IAM)基础设施中集成互联网身份的框架。根据另一种实施例，提供了用于开放式授权的框架。还提供了用于依赖方功能性的框架。

参考以下说明书、权利要求和附图，以上所述连同其它特征和实施例将变得更加显然。

附图说明

在这个文档中包括几个附图。

另外，图1是说明根据本发明一个实施例可以使用的系统环境的部件的简化框图；及

图2是说明根据本发明一个实施例可以使用的计算机系统的简化框图。

具体实施例

在以下描述中，为了解释，阐述了具体的细节，以便提供对本发明实施例的透彻理解。但是，很显然，本发明没有这些具体细节也可以实践。

特征：

(1)用于在现有企业身份和访问管理(IAM)基础设施中集成互联网身份的依赖方平台/框架

企业，尤其是具有面向互联网的属性(网站、电子商务应用、移动应用等)的那些企业，期望朝着获得更高采纳和更高收入而拓展他们的用户群。“互联网身份”是在像Facebook、Google、Yahoo等公共站点保留的用户帐户–这些是数千万用户的宝库(treasure trove)。同时，企业在没有配备成处理这些身份的IAM系统中有现有的投资；二者都是就与这些变化的技术集成以及面向互联网的部署的规模和安全性方面而言的。有些现有的解决方案是定制的/自组织的(ad hoc)/点对点的/拍的(slapped-on)/昂贵的–“创可贴”一样一起放到企业上。有些产品提供一些集成解决方案，但是它们过于绑定到产品。整体上看，现有的解决方案缺乏既解决应付变化的互联网环境的问题又保留现有IAM解决方案中投资的可扩充性、可缩放性和安全性。

根据本发明的一个实施例，提供了具有以下特征的框架或平台：

·用于众所周知的互联网身份提供者(IDP)，诸如Google、Yahoo、Facebook、LinkedIn、Twitter等，的内置连接器。

·与兼容IDP集成的、基于标准的接口(OpenID、OAuth(开放式授权)、安全访问标记语言(SAML)等)。

·用于引导IAM供应商(诸如Oracle、CA、IBM等)的内置集成。

·经抽象工作流/过程之上分层的插件点来定制以满足具体部署需求的可扩充性。

示例工作流过程流：

-用户向IDP认证，这导致适当水平的企业会话创建。

-渐进式用户注册。

-经与“本地”认证集成的基于策略的认证升级(up-leveling)。

实施例提供了几个新颖的特征，包括但不限于关于框架、基于工作流/过程的插件、渐进式和按需/应用驱动的用户进入(on boarding)和认证等的特征。

本发明的一个实施例提供了优于现有解决方案的显著改进。抽象工作流/过程模型允许企业处理商业用例，而不是关于产品细节的专门技术。本发明的一个实施例可以结合从小型(例如，简单LDAP、基于JESSIONID的)到大规模IAM部署的各种IAM解决方案一起使用。

(2)OAuth框架

企业需要经互联网与几个实体(消费者、员工、合作者、云服务等)交互，以保留竞争性并成长。社交网络和以用户为中心的身份的最新进展已经导致公司集合起来创建一个称为OAuth的开放式标准，以方便企业之间安全的域间通信。广义地讲，这个标准覆盖从一个域到另一个域对服务和资源的点到点安全访问。服务/资源一般性地分成以下的类：

-用户控制的数据–诸如用户的日历、照片、联系人列表等

-企业控制的数据–诸如CRM SaaS服务、消费者列表、用户管理数据、用户供应(provisioning)服务、SLA等

这些服务/资源可以在内部或在云上托管。

对于经广大的互联网共享数据和资源，由于其简单性和互联网缩放性，OAuth2.0已经在最近两年内获得了极大的普及。

现有解决方案是基于个别资源/服务所有者提供的“工具箱”，通常对于每个客户端形式因子有一个不同的“工具箱”：手机、web浏览器、web服务器、独立应用等。问题是，虽然OAuth是标准的，但它不是“可互操作的”规范–因此每个个别的工具箱以其自己的具体方式实现协议和交互。因此，希望与多个合作者集成并且处于不同客户端形式因子的企业具有处理无数工具箱的巨大挑战。而且，好的实现需要能够处理细粒度和动态的策略的健壮授权模型，以确保数据安全性及其可说明性(accountability)(例如，适应变化的商业关系)。

有些现有解决方案是定制的/自组织的/点对点的/拍的/昂贵的–“创可贴”一样一起放到企业上，它们不能与现有的企业IAM部署良好地集成。整体上，现有解决方案缺乏既解决应付变化的互联网环境的问题又保留现有IAM解决方案中的投资的可扩充性、可缩放性和安全性。

本发明的一个实施例提供了具有以下特征的OAuth框架或平台：

·用于众所周知的互联网资源和授权服务器，诸如Google Docs、Yahoo、Facebook、LinkedIn、Twitter、Salesforce.com、Oracle OD、Oracle Web Center等，的内置连接器。

·用于引导IAM供应商(诸如Oracle、CA、IBM等)的内置集成。

在一种实施例中，工作流过程流如下：

-用户授权导致用于资源/服务访问的令牌发布。

-对远端服务/资源的应用驱动的访问。

-本地资源/服务对合作者实体的基于策略的暴露。

-令牌生命周期–用户驱动的、管理员驱动的、策略驱动的。

实施例提供了几个新颖特征，包括关于框架/平台、基于工作流/过程的插件、按需/应用驱动的资源访问等的特征。

本发明的一个实施例提供了优于现有解决方案的几个改进。抽象工作流/过程模型允许企业处理商业用例而不是关于产品细节的专门技术。本发明的一个实施例可以与从小型(例如，简单LDAP、基于JSESSIONID的)到大规模IAM部署的各种IAM解决方案一起使用。

更多细节在以下章节/部分(部分1至7)中描述。以下各个部分描述各种实施例；该描述本质上不是约束性或限制性的。

第一部分

第二部分

第三部分

云的依赖方(RPC)

_____________________________________________________

执行概述

云的依赖方是方便客户扩充他们的外联网产品以便充分利用新兴的互联网身份的一个系统。

设计成同时启用嵌入式本机集成和松散耦合的部署集成形式因子：

√用于利用目前和未来的IAM套件嵌入和本机集成的API合同

√作为具有RESTful接口的“现成”代理，非入侵式地扩充靠现有IAM产品(例如，pre-Maple OAM、OIF、OpenSSO和OIM环境)运转的现有web资源以及没有现有Oracle IAM足迹的网站

关键商业用例

使客户能够在互联网上从社交媒体和流行社区拓展&扩充他们对用户的外联网服务产品。

√结合以用户为中心的体验的便利和Oracle IAM平台的健壮的身份管理及完善的风险缓解能力

术语

依赖方消费以用户为中心的身份的服务提供商侧的应用/系统

以用户为中心的身份协议 OpenID、OAuth、CardSpace(信息卡)、所有权

互联网IDP 诸如Google、Yahoo、Facebook、Twitter的身份提供者，任何兼容的OpenID

集成&操作的模式 RP部件的部署选项–例如：嵌入式或代理模式

背景

过去几年里关于互联网的一个关键性发展是“互联网身份”的指数级增长。这些身份源自用户对互联网应用的选择，诸如电子邮件(Gmail、Yahoo)、社交网络(Facebook、Twitter)、博客、社区(LinkedIn)等等，并且随着时间的推移已经发展成允许使用相同身份访问互联网上其它应用的便利的“以用户为中心的”身份。例如，Gmail和Yahoo自动地为所有用户提供允许这种便利的OpenID–当然基于用户的同意。

具有面向互联网的特性的大企业–当中许多是Oracle IAM的客户–在这里看到了通过把这种功能(facility)扩充到他们的站点中来拓展他们的用户群的巨大机会–由此提供许多令人垂涎的初始“粘性”，从而导致收入增长和竞争优势。

这些公司跨各行各业–保险、金融、零售、媒体，等等。云的依赖方聚焦在提供必要的基础设施件，以便使这些公司能够充分利用互联网身份，但保留他们在现有应用和AAA/IdM系统中的投资。

以上是一个活动的网站并且这种趋势在去年很短的时间内已经变得流行。以下是一些其它的著名站点。

(请通过对应的“登录(login)”提示导航)

·Kodak、Sears、National Geographic、Fox News、…..等等。如需更多信息，请访问Janrain.com

需求和设计中心

以下图片说明了客户寻求的期望过渡：从为他们的外联网用户本地管理的身份筒仓(silo)到互联网集成的体验。

√断言以用户为中心的互联网身份进入OAM、OIF和OIM认证流

○向用户提供认证选择

○提供同意驱动的认证和属性访问

√启用无痛用户进入(on-boarding)和渐进式的ID配置

○与客户现有的用户自注册流集成

○用户进入和属性/AuthZ权利要求(claim)传播

√启用特定于应用的策略

○启用具有多个应用和服务端点的网站

○特定于应用的IDP选择和权利要求策略

√在互联网上启用多协议/多提供者用例

○用户依靠一个站点账户链接多个IDP关联

○用户向一个OpenID提供者认证并且经Facebook连接同意关于Facebook中的组成员资格共享信息

○用户向OpenID认证并且同意把OAuth访问令牌提供给该站点，以使得能够访问另一个启用了OAuth的SP(假定站点是OpenID RP和OAuth客户端)

○在服务提供商角色中与SAML共存(建议：经RPC中的嵌入式Fedlet)

与企业流的关键区别

√以用户为中心的身份–用户选择如何认证对比企业托管(mandate)其√基于松散“社交”上下文的相对低等级的认证对比更严格的商业(biz)关系。其并不针对高值事务替换现有的更高LOA认证机制。

√更集中在自供应的用户注册–“首先引诱用户…然后使他/她粘住”

√以应用为中心–由此需要是轻量级的&部署起来要简单

部署体系架构及形式因子需求

√实现为OAM-套件的服务组件

√扩充OAM-套件管理控制台

√2种操作模式：代理模式、嵌入式模式(Fedlet类型)

以下说明一些部署场景。

代理模式–无AAA/IDM–通常是独立的网站

代理模式–有AAA/IDM–通常是多应用网站

嵌入式模式–无AAA/IDM–通常是独立的单应用网站

嵌入式模式–有AAA/IDM–通常是多应用网站

合同

RPC暴露以下主要合同

1.IDP选择器接口[C1]

○如果站点想与RPC集成，以处理可用IDP选择的呈现，则这个合同是相关的。

○调用这个接口将导致RPC把用户指引到“扩充的”互联网登录体验。RPC将为所支持的每个IDP暴露用于URL的配置接口。

2.张贴(Post)IDP选择接口[C2]

这个合同允许重定向到RPC端点，以便基于所作出的决定启动IDP流。这包括RPC启动该流所需的全部参数。

3.IDP交互提供者[C3]

这个合同是SPI–这个SPI的提供者包括对vanilla OpenID的实现、具体OpenID实现、其它协议。这个合同主要是使系统集成者、客户及未来的开发能够清楚地添加新的提供者，而没有对核心框架的重大变化。这个合同提供两个子合同:

○SSO/带IDP的Authn

○从IDP的属性提取

4.注册状态检测提供者接口[C4]

主要合同是SPI，而子合同是RESTful调用。在IDP流成功完成后，所配置的提供者被调用。该SPI的缺省实现调用REST调用来查询(经选定的IDP)刚认证过的用户是否已经存在。该SPI的另一种实现可以对所配置的LDAP用户存储库进行直接调用。

5.注册任务流提供者接口[C5]

主要合同是SPI。当[C4]指示用户不存在时，所配置的提供者被调用。该SPI的缺省实现向IDP进行适当的属性查询调用，以检索用于该用户的附加属性并且使用“重定向”到具有用户简档属性的预先配置的注册URL。可选地，它可以传递返回的url，以便向注册流指示一旦用户注册将最终重定向到的页面。

6.会话创建提供者接口[C6]

主要合同是SPI。当[C4]指示用户已经存在时，所配置的提供者被调用。该SPI的缺省实现使用“重定向”到具有该用户身份的预先配置的认证URL。可选地，它可以传递返回的url，以便向认证流指示一旦用户会话创建将最终重定向到的页面。

这些合同的调用在下一部分中的流程细节交互图中标识。以下是图形形式的合同概述。

示例流程:

·用户选择本地认证或者所支持的一个IDP(显示为“Nascar”类型标签)

·如果用户选择一个IDP–则RP在“后台”开始SSO流。

·用户被重定向到IDP，进行认证，在那里，用户输入凭证并且同意与RP共享身份。

·协议流继续返回到RP–以RP验证authn并且取得相关的用户属性结束

·RP向感兴趣的实体(例如，OAM、OIM、OIF等)呈现authn信息和属性

流程细节(请注意相关交互上的合同标签):

a)本地认证流

b)用户注册:新用户流

c)现有用户–认证流:

总结:

·IDP选择器UI

·Google,Yahoo！,Facebook….

·像Fedlet的WAR文件(+.Net)

·用于传送断言的合同

·用于以下的集成代码:

–定制应用(.Net,JavaEE)

–身份套件产品:OAM,OIM,OIF等

附录

______________________________________________________________

用于OAM的OpenID集成设计模式

目标

这个文档包含用于OpenID集成的通用设计模式或蓝图。它是要解决以下目标:

1)提供用于实现集成到面向目前部署(例如AARP)的典型互联网中的OpenID解决方案的清楚设计要点：确保SSO和基于其OpenID的新用户注册。

2)可以在OAM和OIF环境的现有版本中都被充分利用，而不绑定到其中任何一个。

a.在其中任何一个环境中可用的松散耦合的设计模式

b.不需要任何OAM产品增强

3)有助于设计模式(及潜在地还有代码)在相关的客户项目中被Oracle专业服务重用。

4)用来指引访问管理套件的组件内部OpenID RP增强的设计

a.用于其它互联网客户身份集成的类似模型(例如，信息卡)

b.在NG-AM中作为适当的用于访问的共享服务(SSA)人为因素显现的设计模式

假设

假设客户具有现有的OAM部署，以保护对他们应用的访问，包括：

‐定制的用户注册应用或表单，提供用于自注册的UI并在身份存储库中提供OAM将对照其进行认证的用户供应

‐定制的用户登录应用或表单，向OAM Webgate提交用户凭证

‐由OAM Webgate保护的URL资源

还假设客户想扩充他们的部署，以便可选地允许他们的用户对照通过登录UI选自预定列表的OpenID提供者(OP)进行认证。第一次用户向他们的OpenID提供者认证将与和目前部署中类似的注册UI交互，但是具有基于从OP接收到的信息的某些预先填好的信息。

设计模式描述

通过如下开发对客户定制的扩充并且开发新的OpenID依赖方模块，所推荐的设计模式可以用于实现所需的集成：

‐对现有登录UI的扩充，以显示OpenID IDP选择器(Nascar)：OpenID Login Extension。

‐一个编排OP交互(核心OpenID-RP功能性)、OAM交互以及注册UI交互(对于第一次的用户)的新模块，OpenID-RP Module。

‐对现有注册UI的扩充，以显示任何OP提供的用户属性和收集到的附加用户信息，以完成注册：OpenID Registration Extension。

所推荐的设计模式的中心是OpenID-RP模块。它封装了一组利用良好定义的合同与外部实体交互的功能块并且以不需要OAM10g产品增强的方式一起提供OpenID集成。OpenID-RP能力本身包含在OpenID Interaction Handler块中，并且假设适当许可的开放源代码可以用于其实现。其它块是要定制开发的。为了与OpenID-RP模块构建单元交互，需要定义几个新合同，如在图中利用数字指示的。在OAM和ID存储方案中所需的附加属性中将需要配置和策略改变，以便为每个注册的用户存储OpenID相关的信息，例如授权的OpenID提供者、相关联的用户身份等。

为了描述OpenID-RP模块的构建单元及其交互，让我们逐步通过用于未认证用户的请求流(参考所附的交互和序列图)：

a)作为代替，将向尝试访问受保护的资源的用户示出登录页面，其中可以选择列出的一个OpenID提供者

b)在用户选择一个要使用的OP之后，前方通道重定向将对OpenID-RP模块的OpenID AuthN Request Handler发生

c)OpenID-RP模块的OpenID Interaction Handler将进一步把用户重定向到OP，进行认证

d)在向OP认证之后，用户将被指引返回到OpenID-RP模块的OpenIDInteraction Handler

e)该模块将执行Registration Check，以确认OP认证的用户是否可以映射到本地身份存储中的一个条目

f)如果注册检查成功，则创建OAM会话并且用户被指引返回到最初请求的受保护资源

g)否则，调用Registration Taskflow(见以下对图中引用的临时会话的描述)，这将显示注册UI、在身份存储中供应(provision)该用户、建立OAM会话并最终把用户指引返回到最初请求的受保护资源

两个上下文需要在整个流程中传播：代表认证之前用户最初尝试访问的资源的上下文(资源上下文)和代表通过OP认证的用户的上下文(通过认证的用户上下文)。资源上下文需要在该流程结束时可用，以便在认证和注册之后把用户浏览器重定向到最初请求的资源。通过认证的用户上下文需要在注册成功完成之后在一直到创建OAM会话的点的注册任务流程中传送通过认证的用户的身份时可用。

有多种途径来确保必要的上下文安全地贯穿整个流程。该图示出了利用临时OAM会话的概念实现这个目的的一种途径。临时会话是允许用户只访问为完成注册过程而具体指定的资源，就像注册页面或“条款”页面，的OAM会话的逻辑表示。它在不成功的注册检查之后创建，这将造成在ID存储库中创建部分填充的用户记录。临时OAM令牌将利用OAM ASDK为通过认证但还没有完全注册的用户创建。注册扩充UI及其前方的OAM WebGate将消费这个令牌和所包含的用户身份，来把附加的用户提供的注册信息与早先在ID存储库中创建的用户记录关联。在注册完成之后，该流程将返回到OpenID-RP模块，以便为用户创建完整的OAM会话(还是利用OAM ASDK)-在把临时OAM令牌升级到完全通过认证且注册的用户的OAM令牌的意义上。通过格式化认证方案，使得具有低(例如，0)认证许可级别的OAM令牌代表临时会话，而任何更高的许可级别用于完整OAM会话，临时会话的概念可以在OAM10g部署中模拟。

应当指出，图中所示出的规范流程可以更改，以适应现有的环境。如果等效的功能性在别的地方已提供，则OpenID-RP模块的有些接口或子模块可以略去。例如，如果注册UI扩充可以包括在OpenID-RP模块自身当中，则该流程将被简化并且临时会话将不再必要。

部分4:身份依赖方(对云应用)

________________________________________________________________

1.项目概述

________________________________________________________________

1.1.项目描述

具有面向互联网的特性的大企业–当中许多是Oracle IAM的客户–在这里看到了通过把这种功能(facility)扩充到他们的站点中来拓展他们的用户群的巨大机会–由此提供许多令人垂涎的初始“粘性”，从而导致收入增长和竞争优势。这些公司跨各行各业–保险、金融、零售、媒体，等等。云的依赖方聚焦在提供必要的基础设施件，以便使这些公司能够充分利用互联网身份，但保留他们在现有应用和AAA/IdM系统中的投资。

诸如OpenID、OAuth、SAML和信息卡等的联盟标准提供了用于互联网身份认证和授权的基础。通过对各种协议充当依赖方(RP)，这个项目为云中的应用/服务提供轻量级的基础设施和适当的合同。这个项目将在IDaaS的保护下开发。

上图说明了RP与现有网站的部署和集成视图。在这个图中，RP充当现有互联网网站和各个身份提供者之间的代理。RP方便现有网站以最小化的定制用于外部用户认证和注册。类似地，下图代表RP代理与现有AAA/IDM基础设施的集成，其中IDM基础设施带有OAM、OIM等。

这通常是多应用模式，其中应用受Oracle IDM基础设施的保护。IDM环境必须为登录和注册进行定制，以支持OpenID、OAuth等。

RP基础设施还支持嵌入式模式，其中RP组件可以集成到现有网站或IDM组件中。上图说明了RP到现有互联网网站的嵌入式模式。在该嵌入式模式中，合同有可能将是用于更紧密集成的本机合同。对于

IDM基础设施，用于嵌入式模式的部署视图在下面表示。

_________________________________________________________________

2.概念

_________________________________________________________________

IDaaS 作为服务的身份

SaaS 作为服务的软件。也称为“按需软件”，SaaS模型允许供应商开发、托管和操作让消费者使用的软件。

RP 消费来自他们信任的身份提供者的、通过认证的断言并且向他们的应用或网站提供访问的依赖方

InfoCard 信息卡是用户可以在互联网上使用并且由值得信任的身份提供者发布的数字标识符。

OpenID 开放式身份。OpenID是用于认证用户的一个开放式、分散式的标准，它可以用于访问控制，从而允许用户利用相同的数字身份登录到不同的服务，其中这些服务信任认证方。

OP OpenID提供者。认证用户的身份提供者。

OpenID RP 想利用OpenID协议验证终端用户的标识符的网站或应用。这也称为OpenID服务提供者。

SAML 安全性断言标记语言

OAuth OAuth2.0授权协议使第三方应用能够获得对HTTP服务的有限访问，或者代表终端用户通过编排终端用户和HTTP服务之间的批准交互，或者代表其自己通过允许第三方应用获得访问。

资源所有者能够准许对受保护资源进行访问的实体。当资源所有者是人时，它被称为终端用户。

资源服务器托管受保护的资源、能够利用访问令牌接受和响应受保护资源请求的服务器。

客户端代表资源所有者并且利用其自己的授权作出受保护资源请求的应用。

授权服务器在成功认证资源所有者并获得授权之后向客户端发布访问令牌的服务器。

访问令牌代替使用用户的服务提供者凭证，由客户端应用代表用户用来获得对受保护资源的访问的一个值。

_____________________________________________________________

3.需求

________________________________________________________________

3.1.OpenID RP需求

3.1.1.支持OpenID版本2.0

OpenID2.0是OpenID规范的更新版本并且这个核心规范包含协议命名空间、协议参数、签名(signing)和验证过程、密钥交换协议等。扩充也是这个协议的部分，但是对应的协议参数在各自的扩充规范中定义。

3.1.2.支持OpenID版本1.1

OpenID版本2.0是在2007年12月最终定稿的，因此，除传统的OpenID提供者之外，1.1支持可能不是理想地需要的。

3.1.3.支持OpenID简单注册扩充1.0

该简单注册扩充使得RP能够在RP利用从OP获得的用户简档自注册用户帐户。

3.1.4.支持OpenID属性交换扩充1.0

该属性交换简档使得RP能够从OP提取用户属性并且还更新用户简档属性。虽然提取是常见的用例，但是在它对多个RP需要时更新可能是有用的。

3.1.5.支持OpenID提供者认证策略扩充1.0

OpenID提供者认证策略扩充使得在OpenID提供者认证用户的同时，依赖方能够表达认证上下文或策略以及保证水平(LOA)。例如，，RP可以表达OP使用多因素认证进行用户认证。类似地，OP可以返回已经用于RP的保证水平和认证策略。对于RP来说，这意味着利用返回的认证策略验证所请求的认证策略。

3.1.6.提供与OAM11g的集成

依赖方利用最小化的定制提供与Oracle访问管理器(OAM)的集成。集成应当通过经RP基础设施利用OpenID认证提供对OAM保护的应用的访问。假设登录、注册是通过OAM规定(provision)的，RP应当定义协议参数、集成序列。

3.1.7.提供用于与应用或OAM集成的SPI

RP提供用于处理用户注册以及用于会话创建的SPI。作为开箱即用(Out of the box)的形式，RP为OAM提供缺省实现，但是对于非OAM应用和对于任何其它定制，需要适当的SPI用于应用集成。

3.1.8.与诸如OIF等Oracle IDM堆栈的集成

这是在有可能的用例时的按需集成。

3.1.9.支持OpenID提供者的发现

发现是依赖方使用标识符查找与相应OP讲话的必要信息的过程。OpenID有三条路径来基于OP标识符发现关于OP的信息。如果标识符是XRI，则XRI_Resolution将产生一个包含OP信息的XRDS文档。如果标识符是URL，则Yadis将首先被尝试并且，如果成功，则结果将又是XRDS文档。如果Yadis协议对URL失败，则RP将使用基于HTML的提供者发现。

支持基于HTML的发现可能是很好的而且，依照这个规范，基于HTML的发现对于RP是需要的。

3.1.10.支持OpenID提供者和RP之间的直接/间接通信

OpenID定义用于建立诸如利用Diffie-Hellman密钥交换的密钥交换的关联以及用于确认通过认证的断言的直接通信。在后者，即，确认断言，可能不是RP理想地需要的时候，使用密钥交换。

在间接通信中，消息通过用户代理传递。这是在认证请求和响应在RP和OP之间发送时使用的典型协议流。

3.1.11.支持OpenID签名算法HMAC-SHA1和HMAC-SHA256

在生成签名的时候，OpenID支持两种签名算法HMAC-SHA1和HMAC-SHA256。在被支持的时候，HMAC-SHA256是OpenID2.0规范所推荐的。

3.1.12.支持处理肯定和否定OpenID断言

肯定的断言可以完成认证过程，而否定的断言通常需要后续的认证请求。

3.1.13.支持关联

关联在RP和OP之间建立共享的秘密，这用于验证所涉及各方之间的后续消息。如果有可能，则建议形成关联，以最小化安全漏洞。

3.1.14.支持Google和Yahoo作为OpenID提供者

虽然有许多可用的OpenID提供者，但是这个版本支持Google和Yahoo优先作为OpenID提供者。

3.2.TBD

3.3.SAML RP

3.4.OAuth RP需求

3.4.1.支持OAuth版本2.0

OAuth2.0是OAuth规范的较新版本而且这个核心规范包含为客户端、客户端注册等获得访问令牌(可选地刷新令牌)协议请求和响应流。RP实现OAuth客户端角色。

3.4.2.支持向OAuth版本2.0提供者的认证

RP支持资源所有者(用户)向OAuth2.0提供者认证并且检索简档信息，可选地启用本地用户注册。

3.4.3.支持用于客户端所请求的给定范围的访问令牌的返回

RP支持客户端的请求，以返回用于给定范围的访问令牌。

3.4.4.支持Facebook OAuth2.0提供者

RP支持Facebook OAuth2.0提供者。目前Facebook是唯一一个与OAuth2.0兼容的提供者。当它们变得与OAuth2.0兼容时，对于像Linkedin和Twitter的其它提供者得以增加支持。

3.4.5.支持访问令牌高速缓存

RP支持访问令牌(可选地刷新令牌)的高速缓存。这是为了方便访问令牌在其到期之前的使用。而且可选地，使用长期的刷新令牌获得新的访问令牌。

3.4.6.RP寄存器作为OAuth2.0提供者的客户端

RP寄存器作为Facebook OAuth2.0提供者的客户端。这可以是个手动过程，依赖于提供者对客户端应用登记的规定。

3.5.客户端应用需求

3.5.1.支持客户端应用向RP注册

RP提供管理工具(控制台和命令行)，以方便客户端应用的注册。细节包括应用id、描述、特定于应用的用户简档属性、应用需要的认证提供者等。

3.5.2.支持客户端应用和RP之间的安全交互

RP和客户端应用之间的交互是安全的，即，RP确保授权的应用只能连同数据完整性检查一起与它通信。

________________________________________________________________

4.特征描述

________________________________________________________________

4.1.体系架构

下图提供了具有各种应用合同的互联网身份环境中依赖方(RP)体系架构组件的高级视图。

依赖方(RP)是从身份提供者发布的身份认证断言的消费者。在上图中，Google、Yahoo、Facebook是用户在其中具有账户的身份提供者。这种体系架构中的依赖方利用网站/应用来部署，这依赖于来自一个互联网认证提供者的用户认证。

该体系架构包括五个不同的实体:

1.依赖方(RP)基础设施，为作为依赖方的OpenID、OAuth等提供协议实现，并且为网站/应用集成提供各种合同。

2.消费者。消费者是能够向各种消费者应用启用RP功能性的第三方应用/网站或Oracle IDM组件本身。

3.身份提供者(IP或IDP)为终端用户提供认证并且向依赖方(OpenID提供者、OAuth提供者、用于信息卡的STS、SAML IDP等)提供通过认证的断言。

4.SPI或提供者：RP基础设施依赖功能性使用SPI模型调用各种合同和对应的提供者。例如，对于用户注册，可以使用OIM提供者等。

5.用于系统配置、审计、日志等的配置和数据层。

设计考虑：

1.RP是可以独立部署或者嵌入到现有应用中的松散耦合组件。

2.用于现有访问或会话提供者的最小化定制并且有可能具有对现有登录和注册UI的小扩充。

3.用于例如信息卡、OAuth、SAML等其它客户身份集成的类似模型。

4.RP应当不需要假设诸如OAM、OIF等Oracle基础设施组件的存在。

5.用于应用/产品集成的SPI模型。

4.1.1体系架构流和合同：

以下说明各种组件与RP基础设施之间的交互和合同。

以上体系架构暴露了由RP给予网站/应用以及给予外部互联网认证提供者的各种合同。

由RP暴露的合同如下定义：

-IDP选择器接口(C1)

-张贴(Post)IDP选择器接口(C2)

-IDP接口提供者接口(C3)

-注册状态检查接口(C4)

-注册任务流提供者接口(C5)

-会话创建提供者接口(C6)

-配置提供者接口(C7)

-属性映射/属性提供者接口(C8)

1.IDP选择器接口(C1):这个合同向网站/应用提供认证/身份提供者列表，使得应用可以出现包括各个外部认证提供者(例如Yahoo、Google、Facebook等)的登录页面

·如果站点想与RPC集成，以处理可用IDP选择的呈现，则这个合同是相关的

·调用这个接口将导致RPC把用户指引到“扩充的”互联网登录体验。RPC将为所支持的每个IDP暴露用于URL的配置接口

2.Post IDP选择器接口(C2):这个合同允许重定向到RPC端点，

以便基于所作出的决定启动IDP流。当应用/网站重定向到RP时，这定义以下初步合同参数。

-返回url，

-保证水平(例如LOA1、LOA2等)，

-用户属性名(可选地用于认证，但用于注册)

-认证提供者名(例如Google)，

-协议类型(openid)

-应用ID(例如http://www.example.com)

-应用类型(例如Oracle Access Manager11g)

-范围(OAuth)

该设计文档将详细解释用于每个协议的全部所需参数。这个合同将具有用于每个协议的提供者模型。

3.IDP交互提供者接口(C3):这个合同是SPI–这个SPI的提供者包括对OpenID、OAuth、其它协议的实现。对于SAML，这个合同将使用Fellet。这个合同主要是使系统集成者、客户及未来的开发能够清楚地添加新的提供者，而没有对核心框架的重大变化。这个合同提供两个子合同：

·SSO/带IDP的Authn

·从IDP的属性提取

这个合同定义在部分4.1.2中详细描述的RP适配器。

4.注册状态检查接口(C4):主要合同是SPI，而子合同是对应用的RESTful回调，以检查用户的存在。作为替代，它可以使用对存储库的直接LDAP调用来检查用户的存在。这又是一个提供者模型并且依赖于应用/网站集成模型。

5.注册任务流提供者接口(C5):如果通过执行C4发现用户不存在，则这个合同定义用户注册。作为替代，提供者可以依赖于从IDP等获得的用户属性选择渐进式注册。该SPI的缺省实现对IDP进行适当的属性查询调用，以检索用于用户的附加属性并且使用“重定向”到具有用户简档属性的预先配置的注册URL。可选地，它可以传递返回的url，以便向注册流指示一旦用户注册将最终重定向到的页面。

6.会话创建提供者接口(C6):主要合同是SPI。当C4指示用户已经存在时，所配置的提供者被调用。该SPI的缺省实现使用“重定向”到具有该用户身份的预先配置的认证URL。可选地，它可以传递返回的url，以便向认证流指示一旦用户会话创建将最终重定向到的页面。

7.配置提供者接口(C7):这个接口允许RP充分利用现有的配置存储用于其自己的配置数据。这里的意图是提供与RP在其中部署的环境的无缝配置/管理。

8.用户属性映射器/授权提供者接口(C8):这个接口由RP用来存储每个“应用”或者更准确地说，RP用户属性映射数据的消费者，以及属性RP给授权从IDP检索。C7和C8是管理合同。

以下描述对于不同合同的各个流程图。

本地认证流：

在这个流程中，用户选择使用本地认证并且网站/应用创建新本地会话。

用户注册(新用户流)

这个流程描述了当用户选择使用外部互联网认证提供者时的注册过程。在这个流程中，网站/应用不在本地存储库中找用户并且通过使用从通过认证的断言获得的属性给出本地注册的选项。

用户认证流：

这个协议流程描述了在假设用户在本地存储库中存在的情况下的用户认证过程。

OAuth访问令牌检索流：

这个流程描述了当客户端应用为给定的资源范围请求RP时的OAuth访问令牌检索流。在这个流程中，RP为了获得授权代码和访问令牌而启动OAuth请求/响应。RP使用访问令牌提取用户简档并最终把访问令牌+用户id+oauth标识符等数据返回到客户端应用。

4.1.2依赖方适配器

RP交互处理器暴露用于用户会话创建和用于用户注册的SPI模型。RP暴露称为RPAdapter的接口，该接口使RP能够使用可插拔模型在应用的上下文中调用适配器。

*处理用户登录过程。这个实现可以选择为了会话创建而重定向访问提供者的返回url或者本地创建一个会话并且利用用于返回url的适当会话cookie重定向

4.1.3属性映射&策略

用户属性是通常在依赖方和认证提供者之间交换的关键且敏感的数据。但是，由协议或者由认证提供者暴露的属性不必与依赖方提供者上的身份属性匹配。这个文档建议在RP的每个应用有一个属性映射配置。RP将使用该属性映射并且在对身份提供者进行查询时创建对应的协议请求。类似地，当把从认证提供者获得的属性利用适当的转换转播回网站/应用消费时，将使用相同的属性映射。

如果必要的话，则经协议的属性映射需要工作。

用于应用的属性策略是通过属性映射间接可配置的。例如，RP将只向应用返回那些通过属性映射配置的属性。经用户的属性策略在本文档的范围之外。

这个规范建议用于属性映射的以下初步接口：

映射器本身可以在应用和所使用的协议的上下文中获得。

4.1.4依赖方与Oracle IDM堆栈的集成

虽然RP提供了与任何应用或网站集成的独立基础设施，但是缺省模式提供与Oracle身份管理堆栈的完整集成。下图说明了依赖方与OAM和OIM的集成。

在这个体系架构中，主要有四个组件：OAM基础设施、OIM基础设施、RP基础设施和外部认证提供者。Oracle访问管理器为受各自Oracle网关保护的各个应用提供集中式认证和单点登录。用于Oracle访问管理器的身份存储通常是通过具有数据库或LDAP服务器的Oracle身份管理器规定的。在上图中，网关截获对应用资源的用户请求并且重定向到OAM，用于按照所配置的认证策略进行认证。

图4.8的交互图说明了RP与OAM的集成的序列流程。下图具体说明了OpenID提供者，还适应于OAuth提供者及其它协议提供者。

在访问受OAM保护的网站时，用户被重定向到由OAM进行的凭证收集。用于RP认证方案的凭证收集器将是具有可能的NASCAR扩充的定制登录页面，该扩充列出了所有已知的OpenID提供者、OAuth提供者、值得信任的合作者、信息卡(InfoCard)提供者等。登录扩充的一个例子在下面说明。

作为替代，另一个流行的基于OpenID的登录页面在下面示出。

一旦用户点击了选定的认证提供者，它将通过执行合同C2重定向到RP，以启动对应的协议。C3是RP/IDP协议合同。基于选定的身份提供者，适当地为用户呈现IDP登录页面。一旦用户认证并授权，对应的认证断言就发送回RP。

请求上下文为整个事务维护，使得RP和/或OAM可以适当地重定向回受保护的应用。当其成功地完成IDP和RP之间的SSO过程时，RP交互处理器调用注册检查接口合同来检查用户的存在。SPI模型允许这个合同独立于RP设计并且将依赖于该合同的运行时人为因素。

如果用户存在检查返回真，则RP还检查渐进式注册。渐进式注册是指从身份提供者获得的用户属性比现有属性提供用户身份多一点细节的情况。在这种情况下，用户被重定向，用于利用新的属性集合重新注册。关于此的更多细节将在设计文档中添加。

会话创建提供者接口：

当用户存在时，通过安全地按照TAP机制定义的合同传输用户属性和认证状态，以上RPAdapter重定向到“返回URL”。“返回URL”将TAP认证方案端点。在OAM服务器的TAP认证方案确认来自RP的响应并且创建用户会话。

注册任务流接口：

当用户不存在时，RP适配器利用对应的用户属性重定向到(通过配置提供的)“注册URL”。在OAM服务器的注册扩充利用从OP获得的用户属性值对预先填充注册页面并且把它呈现给用户。除用户属性值是预先填充的之外，这类似于OAM服务器上的自注册。

以下OAM/OIM扩充需要为RP集成开发。

OAM扩充1:现在还没有用于RP集成的认证方案。现在演示(demo)利用OIF(Oracle身份联盟管理器)认证方案，但是，OAM和OIF之间的合同是独立的。RP需要OAM中新的认证方案。RP使用TAP(受信任授权协议，之前称为DAP、委托认证协议)机制与OAM交换合同参数。TAP协议由OAM基础设施定义。

OAM扩充2:TAP协议现在还没有通用到足以在OAM和可信任的合作者之间交换除用户id之外的属性或参数。TAP协议将需要扩充至交换属性和任何其它需要的参数。

OAM扩充3:用于RP认证方案的OAM凭证收集器需要被开发。用于这个登录扩充的内容将从依赖方获得。

OAM/OIM扩充4:用户注册或用户创建接口需要由这个扩充提供。现在还没有可远程控制的(remotable)API，如来自OAM或OIM的API，来创建用户，但是，这个扩充可以使用

-使用RESTful接口(在部署中需要附加的组件IDAAS/REST)

-使用直接的LDAP接口(依赖于部署)。

OAM/OIM扩充5:用户存在检查需要来自OAM或OIM的API支持。现在还没有可远程控制的API，如来自OAM或OIM的API，来检查用户存在。这类似于扩充4。

部分5：依赖方

_______________________________________________________________

1.介绍

_______________________________________________________________

依赖方(RP)提供了使网站或服务提供者能够在他们的本地认证基础设施之外使用各种基于互联网的认证系统的基础设施来提供对各种资源/服务的安全访问。Oracle的对云的依赖方(RPC)的目标是为Oracle IDM消费者和非IDM环境都提供简单且轻量级的基础设施。RP的设计确保它以最小化的集成需求在独立和嵌入式模式中都工作。为了实现这个目标，RP基础设施基于合同模型并且为应用/网站暴露少量接口，以提供适当的集成选项。

1.1依赖方基础设施合同

下图表示各个实体之间依赖方基础设施之间的合同模型。

RPC是一个自包含的web应用，它主要在协议消费者一侧处理诸如OpenID、OAuth、SAML、InfoCard等各种协议。RP暴露以下接口。

C1–IDP(身份提供者)选择器接口：

IDP选择器接口合同向网站/应用提供已知身份提供者的列表。这个合同使得网站能够为现有的登录屏幕/网页建立扩充，以显示所有外部认证系统，诸如互联网身份提供者(Google、Yahoo等)、值得信任的合作者认证系统(利用SAML)等。

C2–Post IDP选择器接口：

Post IDP选择器接口允许网站交换为了让RP与外部身份系统交互所需的选定的IDP、协议和任何其它协议/用户属性。

C3–IDP交互提供者接口：

IDP交互提供者接口仅仅是在RP到外部认证系统之间并且这个合同依赖于身份提供者的类型执行对应的协议。

C4–注册状态检查接口：

注册状态检查接口使得RP能够基于从身份提供者获得的认证断言/属性找出本地用户的存在。虽然这从需求的角度来说是可选的，但是这个合同使得网站/应用能够提供自注册选项。

C5–注册任务流提供者接口：

注册任务流提供者合同使得RP能够基于C4接口启动注册任务流。这个合同是要在本地系统中创建具有适当属性的用户。

C6–会话创建提供者接口：

会话创建提供者接口是要为网站访问建立用户会话。用户会话是通过依赖来自值得信任的外部认证提供者的认证断言创建的。

管理合同:

C7–配置提供者接口：

这个接口允许RP充分利用现有的配置存储用于其自己的配置数据。这里的意图是提供与RP在其中部署的环境的无缝配置/管理。

C8–用户属性映射器/授权提供者接口:

这个接口由RP用来存储每个“应用”或者更准确地说，RP消费者的用户属性映射数据，以及RP被授权从IDP检索的属性。

2.高级设计

______________________________________________________

2.1设计体系架构

以下框图说明了依赖方基础设施的体系架构视图。

这个体系架构图说明了独立模式中的RP部署，其中RP是J2EE容器上自包含的war/ear部署。RP核心组件包括初始化协议端点、返回URL以及其它特定于协议的API。RP协议处理器是一个用于各种协议任务的SPI。例如，OpenID处理器、SAML处理器、OAuth处理器等用于调用对应的协议调用。SPI模型允许使用各种底层组件，诸如对SAML使用Fedlet。Fedlet正在作为依赖方war文件的一部分被捆绑，以处理SAML协议。卡空间选择器现在只是一个占位符，以允许该体系架构灵活地与任何第三方协议提供者一起工作。

由RP暴露的每个合同都是SPI，该SPI允许用于任何第三方应用或网站以及与Oracle IDM基础设施的非常灵活的集成。用于每个接口的缺省实现是作为开箱即用地提供的，以便使诸如OAM、OIM、OVD、审计及配置的Oracle IDM基础设施工作。虽然框架将允许使用缺省实现，但合同是每个应用的，因为用于每个应用/网站的需要可以不同。对于11g R1PS2，与OpenID相关的所有合同都将被实现。

执行流

以下示出的序列图描述了用户到网站提供者和/或AAA(本地身份系统)、RP以及到IDP之间的交互。

在上图中，应用/网站和AAA(认证、授权和审计aka IDM)通常是共同定位的并且有时候可以是同一个系统。依赖方被应用推到前面来处理互联网认证。

1.当用户在网站/应用网页上选择登入或登录选项时，为用户呈现本地登录以及列出所有已知身份提供者的、基于互联网的认证。通常，这需要对现有登录页面的定制来显示身份提供者的列表。用于这种登录扩充的内容由依赖方系统提供。

2.对于选定的认证方法和提供者，AAA/网站检查本地系统策略并且获得任何属性并建立认证上下文。

3.AAA/网站重定向到依赖方，以调用互联网认证。RP和AAA系统之间信息的交换是经二者之间的合同。这主要是安全地交换属性并且把认证过程委托给RP，由此需要建立信任。

4.基于选定的身份提供者和方法，RP利用适当的协议重定向到IDP。

5.在用户在IDP认证之后，IDP向RP发送回认证断言。

6.RP确认认证断言，基于该认证断言获得用户信息。在这个步骤中，首先RP执行用户存在检查合同，以确定用户是否在本地AAA/网站系统中存在。

7.一旦用户合同已执行，RP就重定向回到AAA/网站上的返回url，以完成会话创建。

8.最后，把网站访问提供给用户。

2.2系统布局

依赖方对现有认证基础设施充当网关/代理，进行基于互联网的认证。该系统设计成在两种模式下使用。

独立模式：RP是自包含的war文件应用并且在网站/IDM基础设施之前独立地部署。RP充当进行外部认证的代理。在适用的地方，合同通过HTTP协议执行。当应用不想通过自身改变来启用像OpenID、OAuth等协议时，这种模型是有用的。而且，这种模型在部署中有多于一个应用/网站的时候也是有用的。

嵌入式模式：在嵌入式模式中，RP二进制文件和web组件作为现有应用/AAA的一部分捆绑。在IDM部署中，RP是Oracle访问管理器的一部分。嵌入式模式提供与应用的更紧密集成并且RP配置的管理可以集成到现有的应用配置管理中。

3.设计描述

_______________________________________________________________

RP基础设施既包括内置的也包括诸如Fedlet等捆绑组件。以下设计组件描述了高级基础设施元件。这里所描述的设计描述提供了适应任何协议的灵活性。

3.1.Servlet URL组件

Servlet URL组件是RP核心组件的一部分。RP servlet主要包含初始化URL，以便按照合同C2基于绑定信息调用适当的协议。初始化servlet基于选定的身份提供者、协议等来设置合同。而且，通常，大部分互联网身份协议都需要返回URL，在其中发回认证断言。由于张贴到这个返回URL的数据格式是特定于协议类型的，因此它对于每个协议是独立的URL。例如，OpenID返回URL将是OpenIDReturnServlet。

以下表示利用OpenID协议的RP的servlet组件视图。

RPInitServlet确认输入合同参数、读取协议参数并且调用对应的协议处理器，在这种情况下是OpenIDHandler。OpenID处理器构造协议请求并且重定向到适当的IDP，进行认证。OpenIDReturnServlet从IDP接收响应、调用OpenIDHandler来确认该响应并且最终重定向回到目标URL。

3.2.协议适配器

协议适配器是一个SPI，其中为每个协议调用具体的处理器。这允许插入用于各种协议的任何非本机实现的灵活性。下图表示RP协议处理器调用先/后认证和登出请求的类图。

RP处理器被如上提到的RPInitServlet调用，来处理各种协议，诸如OpenID\OAuth处理器、SAML处理器、InfoCard等。

3.3.合同SPI

RP基础设施目前暴露了用于各种任务的几个合同。所暴露的每个合同都是SPI模型，因为每个合同组件可以彼此变化。现在有六个运行时合同和三个管理合同。这些是针对每个应用的合同并且合同是利用应用ID初始化的。

3.3.1.IDP选择器接口:

IDP选择器接口允许识别已知身份提供者的列表。这个接口为远端客户暴露RESTful接口，以获得身份提供者的列表。该框图解释用于远端网站的合同。REST服务使用本机IDP选择器接口来从SAML配置(基于Fedlet的配置)并从RP配置检索身份提供者列表。RP配置接口管理OpenID、OAuth提供者，同时充分利用来自Fedlet的SAML配置。在嵌入式模式中，IDP选择器接口可以直接被调用。

以下接口概述由这个合同暴露的数据。

3.3.2Post IDP选择接口:

Post IDP选择接口是要在依赖方和网站/AAA之间安全地交换数据以及任何认证状态。虽然该接口通用到足以与任何第三方应用集成，但是应用/AAA可以基于合同使用不同的技术。

下图表示post IDP选择接口调用。

以下接口描述post IDP选择接口。

合作者应当需要按照相互的协议签名并加密合同参数。对于OAM，使用TAP(受信任认证协议)机制在RP和OAM之间安全地传输合同参数。通常这种机制需要在RP和网站中都维护的共享秘密。

以下合同参数在接口中获得:

-协议

-提供者名字

-应用ID(或者合作者ID)

-属性集合(具有格式rp.attribute.<attributename>＝value)

-保证水平(认证水平的分类)

3.3.3.IDP交互提供者接口:

IDP交互接口是非常特定于RP的，来处理各种协议。协议处理器SPI属于这个合同。虽然这个接口对于提供任何定制实现不是预期的，但是该接口允许插入诸如用于SAML2的Fedlet等各种协议提供者。

3.3.4.注册状态检查接口:

这个接口是要由身份提供者检查被断言的主体的用户存在。IDP断言通过属性或者通过唯一标识符包含该主体信息。通常本地用户是通过诸如电子邮件id的公共属性识别的。在有些实施例中，使用诸如OpenID标识符或SAML伪名称的用户标识符。以下接口允许检查用户的存在。

下图解释注册状态检查接口的调用。

以上说明了用于IDM基础设施的检查用户合同，其中REST服务被置于IDM前端，以检查用户的存在。在post IDP交互之后，RPProtocolHandler调用RegistrationStatus接口来检查用户的存在。

3.3.5.注册任务流提供者接口:

注册任务流提供者接口允许在不存在用户的时候基于IDP断言来创建用户。虽然这在有些情况下是可选的，例如在企业情况下，但是通常互联网应用给出一个让用户在向IDP认证之后进行本地用户注册的选项。

以下接口用于注册用户。

这个接口的实现通常重定向到现有的互联网应用/AAA，以完成用户注册。RP不具有终端用户UI接口。以下对于用户注册会是可能的。

如上图中所示，注册UI扩充是RP基础设施的一部分，其中它可以为用户呈现具有预先填好的、从身份提供者接收到的用户属性。当OracleIDM和互联网应用一起用作AAA时，一旦用户选择注册，UserRegistration接口就使用IDAAS REST服务创建用户。

3.3.6.会话创建提供者接口:

通过基于IDP断言创建用户会话，会话创建提供者接口允许用户访问网站/互联网应用资源。以下接口定义会话创建提供者。

下图说明了具有OAM的会话提供者接口。会话提供者接口被RPProtocolHandler调用，以创建用户会话。对于OAM，利用TAP机制，利用创建用户会话的初始请求上下文，诸如用户id、用户属性的用户信息被发送回OAM。

3.3.7.配置提供者接口:

RF基础设施需要既支持独立模式又执行嵌入式模式。因此，RP配置接口应当是提供者模型，其中配置存储独立于接口。下图绘出了配置SPI。

3.3.8.属性映射器接口:

属性映射接口允许RP把IDP协议属性映射到本地属性。本地用户属性通常与本地存储库方案关联，其中本地存储库方案明显与IDP协议所定义的内容不同。例如，OpenID定义名字属性为“openid.ax.type.fname”，这通常映射到来自LDAP用户方案的“givenname”。属性映射是在RP配置中对每个应用配置的。

3.4.OAuth设计

作为OAuth客户端实现的一部分，OIC尝试实现以下目标。

认证:

OIC使用户(资源所有者)能够向OAuth提供者认证、检索用户简档信息、可选地使用户向应用(客户端)注册。在这里，没有访问令牌返回到应用(非常像OpenID认证过程)。

流程：利用Facebook作为OAuth提供者进行解释。

3.4.1.1IDP选择器合同：应用(客户端)使用RPfC的认证提供(或者通过iframe或者利用RPfC的IDP REST服务数据使用应用自己的登录UI)。

3.4.1.2Post IDP选择器合同：用户选择一个具体的OAuth提供者，即，Facebook。它在登录页面上的URL看起来如下：

http://sepc.us.oracle.com:18080/idaas_rp/RPInitServlet？applicationID＝SamplePortal&protocol＝oauth&selectedIDP＝Facebook

3.4.1.3IDP交互提供者合同：一旦用户选择了一个IDP，控制就转到RPfC的RPInitReturnServlet。如果选定的IDP的协议是OAuth，则RP调用OAuthHandler，OAuthHandler又使用对应的OAuthProvider实现来完成OAuth请求/响应流(例如：FacebookImpl–由认证提供者厂家基于选定的IDP和在以上URL中提供的协议信息返回的一个oauth提供者实现)。

3.4.1.4FacebookImpl如下完成OAuth请求/响应流。

*授权码请求带范围、重定向url以及客户端id。在这里，用户给予同意。

信息:重定向到以下URL:

https://graph.facebook.com/oauth/authorize？client_id＝162875890440655scope＝user_birthday,user_location,email&

display＝page&redirect_uri＝http://sepc.us.oracle.com:8080/OAuthDemo/OAuthReturnServlet

FacebookImpl缺省地使用电子邮件、用户生日(user_birthday)和用户位置(user_location)范围作为用户认证的一部分来检索简档数据。

Facebook授权码响应:

EGMOpgMz9UGBPasVF7kXSBHyarD0MIg5fNM-

syW7v50.eyJpdiI6InJzVE9TUWRzNEdPZkdjR0dRX20tNUEifQ.B26VRhRY1vMBx1BdoWF_I1q-

7Kq8lxY7JqIpZu24SCwtyLd64FE4GYIJXZtoRMGGcD96f7opzMDftHFLlyknY9d

OADgqC3UANSrdiILwnxAgniRONh9-

1J63QXG6sfCUePyq2MfejhkZ1sL8CLmi0A

*访问令牌请求带客户端id、客户端秘密、重定向url以及授权码：后方通道通信

https://graph.facebook.com/oauth/access_token？client_id＝162875890440655&redirect_uri＝http://sepc.us.oracle.com:8080/OAuthDemo/OAuthReturnServlet&client_secret＝30628b7ccbbc421521d0bfbf944bfc55&code＝EGMOpgMz9UGBPasVF7kXSBHyarD0MIg5fNM-yW7v50.eyJpdiI

Facebook访问令牌响应:

access_token＝162875890440655|2.teYwXPWgVERRO_hgMr2BdQ__.3600.1304715600.1-100001298313088|r-SY98AzavDLaJrGcllgFsZQDRk&expires＝6429

高速缓存访问令牌和刷新令牌(如果可用的话)：访问令牌如在部分

3.4.3中解释的那样被高速缓存。

3.4.1.5FacebookImpl如下进行用户简档请求并且获得简档数据

*利用访问令牌提取用户简档:

https://graph.facebook.com/me？access_token＝162875890440655％7C2.Gcbl9gQUbW59efeH3OOgHQ__.3600.1304031600.1-100001298313088％7CVChG-TnkJ1IsbOnMDH2EAyG6Xt0

JSON格式的响应:

信息:用户简档：{"id":"..","name":”..",....}

RPfC基于应用的属性映射配置处理用户简档数据。

3.4.1.6注册状态检查与注册流：OAuthReturnServlet通过把简档数据传递到它来调用应用的用户注册合同。借助Idaas REST服务利用电子邮件地址(或者如配置中所规定的)，合同实现检查用户是否存在。如果不存在，则注册页面基于合同而显示(应用可以具有其自己的实现或者使用RPfC的缺省注册页面)。

3.4.1.7.会话合同：如果使用RPfC缺省提供者，则创建一个会话并且把简档数据设置到该会话中。如果使用OAM合同，则简档数据设置到TAP令牌中。

3.4.2.授权:

OIC使得客户端能够如下所述地进行具体的授权请求：

3.4.2.1客户端规定对其来说需要访问令牌的范围和OAuth提供者。OIC又尝试(因为涉及用户同意，所以使用“尝试”一词)向客户端返回访问令牌。

3.4.2.2客户端规定从OAuth提供者它所需的用户简档属性。OIC又尝试从OAuth提供者提取那些属性并且可选地方便通过注册流更新用户简档信息。(这个用例也适用于OpenID提供者)

OIC使得客户端能够如下所述地进行具体的授权请求:

3.4.2.1访问令牌请求:客户端规定对其来说需要访问令牌的范围和OAuth提供者，并且OIC又向客户端返回相关的访问令牌。

流程:

作为查询参数，客户端向RPInitServlet发送范围数据，连同访问令牌要发送到其的返回url。基本上涉及如在部分3.1中解释的Post IDP选择器和IDP交互合同。

例子:

http://sepc.us.oracle.com:18080/idaas_rp/RPInitServlet？applicationID＝SamplePortal&protocol＝oauth&selectedIDP＝Facebook&scope＝read_stram,publish_stream&returnURL＝http://sampleportal.com/oauth_redirect

客户端规定的范围转发到OAuth提供者。RP如在部分3.1.4中所描述的那样获得访问令牌。

用户简档信息也利用访问令牌提取。OAuthReturnServlet重定向到客户端规定的返回url，连同访问令牌+用户id+oauth提供者名字JSON数据。

如果没有提到返回url，则认为它是错误情况。

高速缓存逻辑：访问令牌如在3.3中解释的那样被高速缓存。

3.4.2.2属性请求:客户端规定从OAuth提供者它所需的用户简档属性。

OIC又尝试从OAuth提供者提取那些属性并且可选地方便通过注册流更新用户简档信息(这个用例也适用于OpenID协议)。RPfC存储应用的属性-oauth提供者属性映射配置。

流程:

3.4.2.2.1客户端向RPfC作出对属性以及可选地对返回url的请求。基本上涉及如在部分1中所解释的Post IDP选择器和IDP交互合同。

例子:

http://sepc.us.oracle.com:18080/idaas_rp/RPInitServlet？applicationID＝SamplePortal&protocol＝oauth&selectedIDP＝Facebook&attributes＝a1,a2&returnURL＝http://sampleportal.com/oauth_redirect

属性查询参数可以包含:

具体的名字

*或者没有值–意味着在RPfC中配置的所有属性

如果用户已经通过认证，则客户端将如下作为查询参数发送用户标识符:

http://sepc.us.oracle.com:18080/idaas_rp/RPInitServlet？applicationID＝SamplePortal&protocol＝oauth&selectedIDP＝Facebook&attributes＝a1,a2&userid＝abcfb.com&returnURL＝http://sampleportal.com/oauth_redirect

3.4.2.2.2基于用户标识符，RP尝试如在部分3.3中解释的那样从高速缓存获得访问令牌。如果没有提供用户标识符，则RP完成请求/响应流(如以上在3.1.4中所描述的)并且如下进行属性请求:

情况1.提供具体的属性:利用FaceBookImpl

https://graph.facebook.com/me？fields＝a1,a2&access_token＝2227470867|2.eZ5UyRegzovvA2K1qCgp0Q__.3600.1304708400.0-

100001298313088|m1cHHDKC9KcXAqJmK-

PiujXc_3o&returnURL＝http://sampleportal.com/oauth_redirect

属性名需要被确认，如在应用-属性配置中所规定的。

如果OAuth提供者完全不支持请求具体的属性，则RPfC得到完整的用

户简档数据，并且基于属性映射配置处理该数据。

情况2.*或者没有值被提到。

https://graph.facebook.com/me？access_token＝2227470867|2.eZ5UyRegzovvA2K1qCgp0Q__.3600.1304708400.0-

100001298313088|m1cHHDKC9KcXAqJmK-PiujXc_3o

3.4.2.2.3在提取属性之后，OAuthReturnServlet把属性JSON响应(或者提供者发送的任何内容)重定向回到返回url。如果没有提供返回url，则进行RPfC的缺省用户注册处理。

3.4.2.2.4高速缓存访问令牌和刷新令牌(如果可用的话)：访问令牌如在部分3.4.3中所解释的那样被高速缓存。

3.4.3.高速缓存逻辑

要高速缓存的数据：应用ID、客户端ID(OIC id)、用户ID、范围、访问令牌串、到期时间、刷新令牌串(如果可用的话)以及访问令牌的任何其它属性。

客户端ID+用户ID+范围–作为关键值并且包含以上数据的对象存储在高速缓存中。

用户ID基本上是按照提供者决定的。对于Facebook，它是用户以其开始的电子邮件地址。

访问令牌查找：如果有访问令牌可用，则检查是否令牌的到期时间。如果没有到期，则使用该访问令牌。

如果到期(除去访问令牌)，则使用刷新令牌获得新的访问令牌。

如果刷新令牌自己到期，则取消整个OAuth流，即，获得认证码、获得访问令牌等

客户端可以可选地规定是使用高速缓存的令牌还是强迫RPfC获得新的访问令牌作为其向RPfC的请求的一部分。查询参数是：

useCachedAccessToken＝<true/false>

3.4.4.配置数据

OAuthProvider(每个提供者)

·名字/ID(facebook,google,linkedin等)

·授权url–以获得授权码

·访问令牌url–以获得访问令牌

·简档url–以获得用户简档信息

·属性–用户简档属性名

·范围–资源许可的列表？？

·消费者密钥–作为提供者的消费者的OIC应用

·消费者秘密–作为提供者的消费者的OIC应用

·OIC实例名–向提供者注册的OIC实例，其中名字需要给出。

·OIC实例url–向提供者注册的OIC实例，其中该实例的url需要给出

应用：

·每个OauthProvider

○属性–来自提供者的用户简档属性应用需求的列表

○范围–资源许可的列表？？

·返回url–访问令牌要发送到的地方

·属性–特定于应用的用户简档属性名

3.4.5.OIC向OAuth提供者注册

OIC需要作为应用向OAuth提供者注册，以方便OAuth通信。每个提供者具有它们自己要遵循的注册过程，以便获得消费者密钥和秘密。这里是对于一些提供者的一些数据点。

Facebook:应用设置:http://developers.facebook.com/setup/(注册之后的样本应用数据)

应用名称:oic

应用URL:http://sepc.us.oracle.com:18080/

应用ID:204367999595412

应用秘密:eaed1a1ef047791a03b02a74d5f95031

在RPfC配置中定义OauthProvider时，这个数据连同以下需求给出。

授权URL:

https://graph.facebook.com/oauth/authorize？client_id＝％1$s&display＝page&redirect_uri＝％2$s

访问令牌URL:

https://graph.facebook.com/oauth/access_token？client_id＝％1$s&redirect_uri＝％2$s&client_secret＝％3$s&code＝％4$s

简档URL:https://graph.facebook.com/me？access_token＝％1$s所支持的范围:

http://developers.facebook.com/docs/authentication/permissions/

4.内部API/类

___________________________________________________________

4.1.OpenID API

OpenID是一个轻量级协议并且只使用HTTP请求和响应。这里所描述的API是要为RP提供可扩充的和可重用的框架，以支持OpenID协议。以下说明各个OpenID协议元素的类图。

以下的类描述描述高级API调用

4.1.1.OpenIDManager

4.1.2.认证/属性请求

4.1.3.关联

关联是要在依赖方和OpenID提供者之间建立共享的秘密

4.1.4.发现

发现是一个为了RP的消费而查找OpenID提供者端点和策略的过程。发现协议是RP为了找出OP信息而执行的第一个协议。OpenID定义三条不同的途径，Yaids协议、XRI解析和HTML发现。

4.2.RPProtocolHandler

RPProtocolHandler接口是要为各种任务，诸如登录/登出/合同等，调用不同的协议实现。

4.3.RequestContext

4.4.OAuth API/类

高级类图:

第六部分

第七部分

图1是说明根据本发明一个实施例可以使用的系统环境100的部件的简化框图。如所示出的，系统环境100包括一个或多个客户端计算设备102、104、106、108，这些设备配置为操作诸如web浏览器、专属客户端(例如，Oracle Forms)等客户端应用。在各种实施例中，客户端计算设备102、104、106、108可以与服务器112交互。

客户端计算设备102、104、106、108可以是通用个人计算机(作为例子，包括运行Microsoft Windows和/或Apple Macintosh操作系统的各种版本的个人计算机和/或膝上型计算机)、智能电话或PDA(运行诸如Microsoft Windows Mobile的软件并且启用Internet、电子邮件、SMS、Blackberry或其它通信协议)，和/或运行各种商业可用的UNIX或像UNIX的操作系统(包括但不限于各种GNU/Linux操作系统)中任何一种的工作站计算机。作为替代，客户端计算设备102、104、106、108可以是能够经网络(例如，以下所述的网络110)通信的任何其它电子设备，诸如瘦客户端计算机、启用互联网的游戏系统，和/或个人发消息设备。虽然示例性系统环境100示为具有四个客户端计算设备，但是任意数量的客户端计算设备都可以被支持。诸如带传感器的设备等的其它设备可以和服务器112交互。

系统环境100可以包括网络110。网络110可以是本领域技术人员熟悉的、可以利用各种商业可用的协议中任何一种支持数据通信的任何类型的网络，包括但不限于TCP/IP、SNA、IPX、AppleTalk等。仅仅是作为例子，网络110可以是局域网(LAN)，诸如以太网、令牌环网等；广域网；虚拟网，包括但不限于虚拟专用网(VPN)；互联网；内联网；外联网；公共交换电话网(PSTN)；红外线网络；无线网络(例如，在本领域中已知的IEEE802.11协议套件、蓝牙协议和/或任何其它无线协议下运行的网络)；和/或这些和/或其它网络的任意组合。

系统环境100还包括一个或多个服务器计算机112，这可以是通用计算机、专用服务器计算机(作为例子，包括PC服务器、UNIX服务器、中档服务器、大型计算机、机架式服务器等)、服务器场、服务器集群，或者任何其它适当的布置和/或组合。在各种实施例中，服务器112可以适于运行前面公开内容中所描述的一个或多个服务或软件应用。例如，服务器112可以对应于根据本发明的一个实施例用于执行依赖方和开放式授权处理的服务器。

服务器112可以运行包括以上讨论的那些当中任何一个以及任何商业可用的服务器操作系统的操作系统。服务器112还可以运行各种附加的服务器应用和/或中间层应用中任何一种，包括HTTP服务器、FTP服务器、CGI服务器、Java服务器、数据库服务器等。示例性数据库服务器包括但不限于从Oracle、Microsoft、Sybase、IBM等可商业获得的那些服务器。

系统环境100还可以包括一个或多个数据库114、116。数据库114、116可以驻留在各个位置。作为例子，数据库114、116中的一个或多个可以驻留在服务器112本地的非临时性存储介质中(和/或驻留在服务器112中)。作为替代，数据库114、116可以远离服务器112，并且经基于网络的或者专用的连接与服务器112通信。在一组实施例中，数据库114、116可以驻留在本领域技术人员熟悉的存储区域网络(SAN)中。类似地，用于执行属于服务器112的功能的任何必要的文件都可以适当地本地存储在服务器112上和/或远端存储。在一组实施例中，数据库114、116可以包括适于响应于SQL格式化的命令而存储、更新和检索数据的关系数据库，诸如由Oracle提供的数据库。

图2是可以根据本发明实施例使用的计算机系统200的简化框图。例如，服务器102可以利用诸如系统200的系统实现。计算机系统200示为包括可以经总线224电耦合的硬件元件。硬件元件可以包括一个或多个中央处理单元(CPU)202、一个或多个输入设备204(例如，鼠标、键盘等)，以及一个或多个输出设备206(例如，显示设备、打印机等)。计算机系统200还可以包括一个或多个存储设备208。作为例子，存储设备208可以包括诸如盘驱动器、光学存储设备以及诸如随机存取存储器(RAM)和/或只读存储器(ROM)的固态存储设备的设备，这些设备可编程、可闪存更新(flash-updateable)等。

计算机系统200可以附加地包括计算机可读存储介质读取器212、通信子系统214(例如，调制解调器、网卡(无线或有线)、红外线通信设备等)，以及可以包括如上所述RAM和ROM设备的工作存储器。在有些实施例中，计算机系统200还可以包括处理加速单元216，这可以包括数字信号处理器(DSP)、专用处理器等。

计算机可读存储介质读取器212还可以连接到计算机可读存储介质210，一起(并且，可选地，结合存储设备208)综合地代表远端、本地、固定和/或移动存储设备外加用于暂时地和/或更持久地包含计算机可读信息的存储介质。通信系统214可以允许数据利用网络1610和/或以上关于系统环境1600所述的任何其它计算机交换。

计算机系统200还可以包括软件元件，示为目前位于工作存储器218中，包括操作系统220和/或其它代码222，诸如应用程序(可以是客户端应用、Web浏览器、中间层应用、RDBMS等)。在示例性实施例中，工作存储器218可以包括可执行代码和用于如上所述依赖方和开放式授权相关的处理的相关联数据结构。应当认识到，计算机系统200的备选实施例可以具有与以上所述不同的多种变化。例如，定制的硬件也可以使用和/或特定的元件可以在硬件、软件(包括便携式软件，诸如小应用程序(applet))或者二者当中实现。另外，可以采用到诸如网络输入/输出设备的其它计算设备的连接。

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

Claims

1.一种方法，包括：

在OAuth授权服务器处，从第一资源服务器接收指示由第一资源服务器识别的第一范围集合的第一元数据集合；

响应于接收到第一元数据集合，在OAuth授权服务器处，存储第一范围集合中的范围和由第一资源服务器维护的资源子集之间的映射；

在OAuth授权服务器处，存储第一访问令牌和来自第一范围集合的第一范围之间的映射；

在OAuth授权服务器处，从第一资源服务器接收确认第一访问令牌的请求；

响应于接收到确认第一访问令牌的请求，OAuth授权服务器基于第一访问令牌和第一范围之间的映射确认第一访问令牌；及

响应于确认第一访问令牌，OAuth授权服务器向第一资源服务器指示向第一资源服务器呈交第一访问令牌的客户端应用被授权相对于由第一资源服务器维护并由第一范围规定的资源集合执行操作。

2.如权利要求1所述的方法，还包括：

在OAuth授权服务器处，接收规定第一范围的特定请求；

响应于接收到规定第一范围的请求，OAuth授权服务器请求包含在第一范围中的资源的所有者同意准许与第一范围一致的客户端应用访问；

响应于从所有者接收到同意，OAuth授权服务器(a)创建第一访问令牌，(b)存储第一访问令牌和第一范围之间的映射，并且(c)向客户端应用发送第一访问令牌。

3.如权利要求1所述的方法，还包括：

响应于接收到第一元数据集合，在OAuth授权服务器处，存储第一范围、由第一资源服务器存储的第一资源子集和映射到该第一范围的令牌的持有者被允许相对于第一资源子集中的资源执行的第一操作集合之间的映射。

4.如权利要求1所述的方法，其中确认第一访问令牌包括OAuth授权服务器调用由不提供OAuth授权服务器的消费者提供的编程代码；其中该编程代码实现由OAuth授权服务器的提供者提供给消费者的接口；其中该编程代码确认第一访问令牌。

5.如权利要求1所述的方法，还包括：

在OAuth授权服务器处，接收规定第一范围的特定请求；

响应于从所有者接收到同意，OAuth授权服务器调用由不提供OAuth授权服务器的消费者提供的编程代码；其中该编程代码实现由OAuth授权服务器的提供者提供给消费者的接口；其中该编程代码创建第一访问令牌。

6.如权利要求1所述的方法，还包括：

在OAuth授权服务器处，从与第一资源服务器分开的第二资源服务器接收指示由第二资源服务器识别的第二范围集合的第二元数据集合，该第二范围集合与第一范围集合不同；

响应于接收到第二元数据集合，在OAuth授权服务器处，存储第二范围集合中的范围和由第二资源服务器维护的资源子集之间的映射；

在OAuth授权服务器处，存储第二访问令牌和来自第二范围集合的第二范围之间的映射；

在OAuth授权服务器处，从第二资源服务器接收确认第二访问令牌的请求；

响应于接收到确认第二访问令牌的请求，OAuth授权服务器基于第二访问令牌和第二范围之间的映射确认第二访问令牌；及

响应于确认第二访问令牌，OAuth授权服务器向第二资源服务器指示向第二资源服务器呈交第二访问令牌的客户端应用被授权相对于由第二资源服务器维护并由第二范围规定的资源集合执行操作。

7.一种包括指令的计算机可读存储器，指令当被一个或多个处理器执行时，使这一个或多个处理器执行：

8.如权利要求7所述的计算机可读存储器，其中，指令当被一个或多个处理器执行时，还使这一个或多个处理器执行：

在OAuth授权服务器处，接收规定第一范围的特定请求；

9.如权利要求7所述的计算机可读存储器，其中，指令当被一个或多个处理器执行时，还使这一个或多个处理器执行：

响应于接收第一元数据集合，在OAuth授权服务器处，存储第一范围、由第一资源服务器存储的第一资源子集和映射到该第一范围的令牌的持有者被允许相对于第一资源子集中的资源执行的第一操作集合之间的映射。

10.如权利要求7所述的计算机可读存储器，其中确认第一访问令牌包括OAuth授权服务器调用由不提供OAuth授权服务器的消费者提供的编程代码；其中该编程代码实现由OAuth授权服务器的提供者提供给消费者的接口；其中该编程代码确认第一访问令牌。

11.如权利要求7所述的计算机可读存储器，其中，指令当被一个或多个处理器执行时，还使这一个或多个处理器执行：

在OAuth授权服务器处，接收规定第一范围的特定请求；

12.如权利要求7所述的计算机可读存储器，其中，指令当被一个或多个处理器执行时，还使这一个或多个处理器执行：

13.一种OAuth授权服务器，包括：

配置为从第一资源服务器接收指示由第一资源服务器识别的第一范围集合的第一元数据集合的一个或多个硬件处理器；

配置为，响应于接收到第一元数据集合，存储第一范围集合中的范围和由第一资源服务器维护的资源子集之间的映射的一个或多个硬件处理器；

配置为存储第一访问令牌和来自第一范围集合的第一范围之间的映射的一个或多个硬件处理器；

配置为从第一资源服务器接收确认第一访问令牌的请求的一个或多个硬件处理器；

配置为，响应于接收到确认第一访问令牌的请求，基于第一访问令牌和第一范围之间的映射确认第一访问令牌的一个或多个硬件处理器；及

配置为，响应于确认第一访问令牌，向第一资源服务器指示向第一资源服务器呈交第一访问令牌的客户端应用被授权相对于由第一资源服务器维护并由第一范围规定的资源集合执行操作的一个或多个硬件处理器。

14.如权利要求13所述的OAuth授权服务器，还包括：

配置为接收规定第一范围的特定请求的一个或多个硬件处理器；

配置为，响应于接收到规定第一范围的请求，请求包含在第一范围中的资源的所有者同意准许与第一范围一致的客户端应用访问的一个或多个硬件处理器；

配置为，响应于从所有者接收到同意，(a)创建第一访问令牌，(b)存储第一访问令牌和第一范围之间的映射，并且(c)向客户端应用发送第一访问令牌的一个或多个硬件处理器。

15.如权利要求13所述的OAuth授权服务器，还包括：

配置为，响应于接收到第一元数据集合，存储第一范围、由第一资源服务器存储的第一资源子集和映射到该第一范围的令牌的持有者被允许相对于第一资源子集中的资源执行的第一操作集合之间的映射的一个或多个硬件处理器。

16.如权利要求13所述的OAuth授权服务器，其中一个或多个硬件处理器配置为至少部分通过调用由不提供OAuth授权服务器的消费者提供的编程代码来确认第一访问令牌；其中该编程代码实现由OAuth授权服务器的提供者提供给消费者的接口；其中该编程代码配置为确认第一访问令牌。

17.如权利要求13所述的OAuth授权服务器，还包括：

配置为在OAuth授权服务器处接收规定第一范围的特定请求的一个或多个硬件处理器；

配置为，响应于接收到规定该第一范围的请求，请求包含在第一范围中的资源的所有者同意准许与第一范围一致的客户端应用访问的一个或多个硬件处理器；

配置为，响应于从所有者接收到同意，调用由不提供OAuth授权服务器的消费者提供的编程代码的一个或多个硬件处理器；其中该编程代码实现由OAuth授权服务器的提供者提供给消费者的接口；其中该编程代码配置为创建第一访问令牌。

18.如权利要求13所述的OAuth授权服务器，还包括：

配置为，从与第一资源服务器分开的第二资源服务器接收指示由第二资源服务器识别的第二范围集合的第二元数据集合的一个或多个硬件处理器，该第二范围集合与第一范围集合不同；

配置为，响应于接收到第二元数据集合，存储第二范围集合中的范围和由第二资源服务器维护的资源子集之间的映射的一个或多个硬件处理器；

配置为存储第二访问令牌和来自第二范围集合的第二范围之间的映射的一个或多个硬件处理器；

配置为从第二资源服务器接收确认第二访问令牌的请求的一个或多个硬件处理器；

配置为，响应于接收到确认第二访问令牌的请求，基于第二访问令牌和第二范围之间的映射确认第二访问令牌的一个或多个硬件处理器；及

配置为，响应于确认第二访问令牌，向第二资源服务器指示向第二资源服务器呈交第二访问令牌的客户端应用被授权相对于由第二资源服务器维护并由第二范围规定的资源集合执行操作的一个或多个硬件处理器。