CN101110824B - 在联盟计算环境中处理事务的方法和设备 - Google Patents

Abstract

提供一种在联盟计算环境中处理事务的方法。在第一联盟实体从第二联盟实体接收资源请求。第一联盟实体根据第一联盟实体和第二联盟实体间的信任关系响应对于第二联盟实体的联盟协议操作。第一联盟实体的服务由分布式数据处理系统中的一组数据处理系统提供，并且该组数据处理系统中的每个数据处理系统能够充当身份提供商。该组数据处理系统中的第一数据处理系统将其自身确立为跨该组数据处理系统相对于第二联盟实体充当身份提供商，并随后用于作为身份提供商针对来自第二联盟实体的请求执行联盟协议操作。

Description

在联盟计算环境中处理事务的方法和设备

技术领域

本发明涉及改进的数据处理系统，特别涉及多计算机数据传送的方法和设备。更具体地说，本发明涉及联网的计算机系统。

背景技术

为了降低用户管理的成本和改进企业之间的互操作性，创建了联盟计算空间。联盟(federation)是遵从特定互操作性标准的企业的松散耦合的关联；对于联盟中用户的特定计算操作而言，联盟提供了在那些企业之间的信任机制。例如，联盟合作伙伴可以充当用户的归属域或身份提供商。相同联盟中的其他合作伙伴可以依赖于用户的身份提供商以进行用户认证凭证的基本管理，例如接受由用户的身份提供商提供的一次性登录令牌(single-sign-on token)。

随着企业开始支持联盟业务交互，这些企业应当提供反映两个商家之间的增加的合作和使用户的操作负担尽可能小的用户体验。在这些联盟中，这些企业已经开始互操作以支持用户可能不知晓也可能只是最低限度地知晓的各种联盟协议。例如，联盟的企业可执行各种类型的操作(可能要求与用户的很少交互以完成该操作)以进行用户帐户管理，如管理用户特定的别名标识符。联盟的企业应当合作到用户不被底层基础机制(这种类型的操作通过所述机制而协作)的知识而混淆或负担过重。

但是，在联盟中实施这些操作时应当考虑一个折中。应当以对联盟企业高效的方式执行各种操作(例如，可能要求与用户的最小交互以完成操作的那些操作)，特别是对企业中的所有用户都要求的那些类型的操作。例如，当需要为成千或成百万的用户(例如特定企业的所有客户)执行特定操作时，用于执行操作的机制需要是可缩放的，以便其不使联盟企业的计算资源的负担过重，而且，可以以各种方式执行这些不同类型的操作，所述各种方式在其对必要操作涉及的联盟企业有不同的负担。

处理联盟企业中的计算资源负担问题的一种方式是在分布式数据处理系统中实施联盟功能性。例如，可以在分布式数据处理系统中支持身份提供商的服务。但是，分布式数据处理系统的特性可能是有问题的；联盟协议操作的某些要求会使用于在分布式数据处理系统中执行那些联盟协议操作的功能性的实施变得比较复杂。

因此，实施联盟企业及其计算基础结构，以便联盟企业的数据处理系统中的联盟协议操作可被有效和可配置地管理是有利的。有效地实施用于分布式数据处理系统中的联盟协议操作的功能性(特别是用于在分布式数据处理系统中执行身份提供商的联盟协议操作的功能性)是特别有利的。

发明内容

提出了用于在联盟计算环境中处理事务的方法、设备和计算机程序产品。在第一联盟实体从第二联盟实体接收资源请求。第一联盟实体根据第一联盟实体和第二联盟实体间的信任关系响应第二联盟实体的联盟协议操作。由分布式数据处理系统中的一组数据处理系统提供第一联盟实体的服务，并且该组数据处理系统中的每个数据处理系统能够充当身份提供商。该组数据处理系统中的第一数据处理系统确立其自身对于该组数据处理系统相对于第二联盟实体充当身份提供商。然后，对于来自第二联盟身体的请求，使用第一数据中心作为身份提供商来执行联盟协议操作。

附图说明

在随附的权利要求中阐述表征本发明的新颖特征。在参照附图阅读本发明时，将能最佳理解本发明本身、进一步的目标及其优点。在附图中：

图1A表示数据处理系统的典型网络，每个数据处理系统均可实现本发明。

图1B表示可在其中实施本发明的数据处理系统中使用的典型计算机体系结构。

图2是一个框图，其相对于一个事务例示了联盟环境的术语，所述事务是由用户向第一联盟企业启动的，所述第一联盟企业作为响应在联盟环境中的下游实体处调用动作。

图3是一个框图，例示了将给定域处的预先存在的数据处理系统与可用于支持本发明的实施方式的某些联盟体系结构组件相集成。

图4是一个框图，例示了一种方式的实例，其中联盟体系结构的某些组件可被用于建立信任关系以支持本发明的实施。

图5是一个框图，例示了根据能够支持本发明的示例联盟体系结构，在使用信任代理的联盟域和信任中介之间的一组示例性信任关系。

图6是一个框图，例示了支持联盟一次性登录操作的联盟环境。

图7是一个框图，例示了用于实施联盟用户生命周期管理功能性以便支持本发明的联盟域中的某些组件。

图8A是一个框图，例示一个联盟实体，其实施为分布式数据处理系统以支持用于实施身份提供商功能性的资源的灵活分配。

图8B-8E是框图，例示了其中第一联盟实体与第二联盟实体交互的情形，所述第二联盟实体使用分布式数据处理系统以支持浮动的身份提供商。

图9A-9C是一组流程图，例示了用于在支持浮动身份提供商分配的联盟实体中处理资源请求的过程。

图10A-10D是一组文本串，例示了可嵌入在cookie中以支持浮动身份提供商的分配的某些信息。

图11A-11B是一对流程图，例示了用于重置浮动身份提供商的分配的过程。

图12是数据流图示，例示了可在联盟客户机或用户与支持浮动身份提供商的联盟实体之间传送的某些数据业务量。

具体实施方式

一般来说，可构成或与本发明相关的设备包括广泛的数据处理技术。因此，作为背景，在详细描述本发明之前首先描述分布式数据处理系统的硬件和软件组件的典型组织。

现在参见附图，图1A表示数据处理系统的典型网络，每个数据处理系统均可实现本发明。分布式数据处理系统100包含网络101，其是可用于在分布式数据处理系统100中连接在一起的各种设备和计算机之间提供通信的介质。网络101可包括永久连接，如有线或光缆，或者通过电话或无线通信进行的临时连接。在所示的例子中，服务器102和服务器103以及存储单元104连接到网络101。此外，客户机105-107也连接到网络101。客户机105-107以及服务器102-103可由各种计算设备表示，如主机、个人计算机、个人数字助理(PDA)等。分布式数据处理系统100可包括额外的服务器、客户机、路由器、其他设备以及未示出的其他对等体系结构。

在给出的实例中，分布式数据处理系统100可包括因特网，其中网络101表示使用各种协议(如LDAP(轻量级目录访问协议)、TCP/IP(传输控制协议/因特网协议)、HTTP(超文本传输协议)等)彼此通信的网络和网关的全球集合。当然，分布式数据处理系统100还可包括一系列不同类型的网络，如企业内部网、局域网(LAN)或广域网(WAN)。例如，服务器102直接支持客户机109和网络110，其构成了无线通信链路。启用网络的电话机111通过无线链路112连接到网络110，PDA 113通过无线链路114连接到网络110。电话机111和PDA 113也可以使用适当的技术(例如蓝牙^TM无线技术)通过无线链路115直接在它们之间传输数，以便创建所谓的个人区域网络或个人自组织网络。类似地，PDA 113可通过无线通信链路116将数据传送到PDA 107。

本发明可以在各种硬件平台和软件环境中实施。图1A只是异构计算环境的一个示例，不应理解为对本发明的结构限制。

参见图1B，这是一个可在其中实施本发明的数据处理系统中使用的典型计算机体系结构的框图。数据处理系统120包含与内部系统总线123连接的一个或多个中央处理单元(CPU)122，所述内部系统总线123使随机存取存储器(RAM)124、只读存储器126和输入/输出适配器128互连，所述输入/输出适配器128支持各种I/O设备，如打印机130、盘单元132或未示出的其他设备，如音频输出系统等。系统总线123还连接提供对通信链路136的访问的通信适配器134。用户接口适配器148连接各种用户设备，如键盘140和鼠标142或未示出的其他设备，如触摸屏、铁笔、麦克风等。显示适配器144将系统总线123连接到显示设备146。

本领域技术人员能够理解，图1B中的硬件可根据系统实施有所不同。例如，系统可以具有一个或多个处理器，如基于

的处理器和数字信号处理器(DSP)，一种或多种类型的易失性或非易失性存储器。除图1B中的硬件或者替代图1B中的硬件，还可以使用其他外围设备。所述实例不应理解为对本发明的任何结构限制。

除了能够在各种硬件平台上实施外，本发明可以在各种软件环境中实施。可以使用典型的操作系统来控制在每个数据处理系统中的程序执行。例如，一个设备可以运行

操作系统，另一个设备包含简单的

运行时环境。代表性的计算机平台可包括浏览器，这是用于访问各种格式的超文本文档(例如，图形文件、字处理文件、可扩展标记语言(XML)、超文本标记语言(HTML)、手持设备标记语言(HDML)、无线标记语言(WDL)以及其他各种文件格式和类型)的公知软件应用。应当注意，预期图1A所示的分布式数据处理系统完全能够支持各种对等子网和对等服务。

在前面给出了一些当前技术的简要描述后，下面的描述将涉及在其中可运行本发明的联盟计算机环境。在详细描述本发明前，先介绍一些术语。

术语

术语“实体”或“方”通常指组织、个人或代表组织、个人进行操作的系统，或者其他系统。术语“域”意味着网络环境中的额外特征，但是可以互换地使用“实体”、“方”和“域”。例如，术语“域”也可指DNS(域名系统)域，或者更一般地，指包括呈现为外部实体的逻辑单元的各种设备和应用的数据处理系统。

术语“请求”和“响应”应当理解为包括适用于在特定操作中涉及的信息(例如，消息、通信协议信息或其他相关联的信息)的传送的数据格式化。受保护的资源是其访问被控制或限制的资源(应用、对象、文档、页面、文件、可执行代码或其他计算资源、通信类型资源等)。

令牌(token)提供了成功操作的直接证据，并且由执行操作的实体产生，例如在成功认证操作后产生的认证令牌。Kerberos令牌是可在本发明中使用的认证令牌的一个例子。有关Kerberos的更多信息，可参见Kohl等人的“The Kerberos Network AuthenticationService(V5)″，Internet Engineering Task Force(IETF)Request forComments(REt)1510，09/1993。

断言(assertion)提供了某些动作的间接证据。断言可以提供身份、认证、属性、授权决定或其他信息和/或操作的间接证据。认证断言提供了由不是认证服务、但是听从认证服务的实体进行的认证的间接证据。

安全性断言标记语言(SANL)断言是可用于本发明的一种可能断言格式的例子。SAML已由Organization for the Advancement ofStructured Information Standards(OASTS)传播，OASTS是非盈利性的全球社团。SAML在″Assertions and Protocol for the OASISSecurity Assertion Markup Language(SAML)″，CommitteeSpecification 01，05/31/2002中被描述如下：

安全性断言标记语言(SAML)是用于交换安全性信息的基于XML的框架。安全性信息以有关主体的断言的形式表示，其中主体是在特定安全性域中具有身份的实体(人或计算机)。主体的典型例子是由其在特定因特网DNS域中的电子邮件地址识别的人。断言可以传递关于由主体执行的认证动作的信息、主体的属性以及有关主体是否被允许访问特定资源的授权决定。断言被表示为XML构造并具有嵌套结构，由此单个断言可以包含有关认证、授权和属性的几个不同的内部声明。注意，包含认证声明的断言只描述先前发生的认证的动作。断言由SAML权威机构发出，即，认证权威机构、属性权威机构和策略决定点。SAML定义了客户机可从SAML权威机构请求断言并从其获得响应的协议。此协议由基于XML的请求和响应消息格式构成，可以与多种不同的下层通信和传输协议绑定；SAML当前定义到SOAP over HTTP的一个绑定。SAML权威机构可使用各种信息源(如作为请求中的输入接收的外部策略存储器和断言)来创建其响应。因此，当客户机总是消费断言时，SAML权威机构既可以是断言的产生者也可以是断言的消费者。

SAML规范指明，断言是提供由发布者进行一个或多个声明的信息包。SAML允许发布者进行三种不同的断言声明：认证，其中由特定装置在特定时间认证规定的主体；授权，其中已准许或拒绝允许规定主体访问规定资源的请求；以及属性，其中规定的主体与提供的属性相关联。如下所述，在必要时，各种断言格式可被转换为其他断言格式。

认证是确认由用户或代表用户提供的一组凭证的过程。认证是通过核实用户所知道的一些东西、用户具有的一些东西或者用户是什么(即，有关用户的一些物理特征)来执行的。用户所知道的一些东西可包括共享的秘密(如，用户的口令)，或者通过核实只对特定用户已知的一些东西(如用户的加密密钥)。用户具有的一些东西可包括智能卡或硬件令牌。有关用户的一些物理特征可包括生物统计学输入，如指纹或视网膜图。应当注意，用户通常是但不一定必须是自然人，用户可以是机器、计算设备或者使用计算资源的其他类型的数据处理系统。应当注意，用户通常但不一定必须拥有单个唯一的标识符；在某些情况下，多个唯一的标识符可以与单个用户相关联。

认证凭证是在各种认证协议中使用的一组质询/响应信息。例如，用户名和口令组合是最熟悉的认证凭证的形式。其他形式的认证凭证可以包括各种形式的质询/响应信息、公共密钥基础结构(PKI)证书、智能卡、生物统计学资料等。认证凭证与认证断言不同：认证凭证由用户作为与认证服务或服务的认证协议序列的一部分而提供；而认证断言是有关用户认证凭证的成功出示和确认的声明，随后在必要时在实体间传送。

可并入本发明的计算环境的联盟模型

在万维网的情况下，用户开始期待从与一个因特网域中的一个应用交互跳到另一个域中的另一个应用，而不必考虑在每个特定域间的信息障碍。用户不希望由于必须为了单个事务在多个域中进行认证带来的麻烦。换言之，用户期待组织应当互操作，但是用户通常还希望域能够尊重其隐私。此外，用户可能更希望限制永久存储个人信息的域。这些用户期待存在于日益变化的异构环境(其中，许多企业和组织正在发布有竞争性的认证技术)中。

在允许企业对用户提供一次性登录体验的联盟模型中支持本发明。换言之，可以在联盟、异构环境中实施本发明。作为可从联盟、异构环境中受益的事务的例子，用户能够向一个域进行认证并随后让该域为事务中可能涉及的每个下游域提供适当的断言。这些下游域需要能够理解和信任认证断言和/或其他类型的断言，即使在域和这些其他下游域之间没有预先建立的断言格式。除了识别断言外，下游域需要能够将在断言中包含的身份转换为在特定域中代表用户的身份，即使没有预先建立的身份映射关系。

在联盟环境中支持本发明。通常，企业具有其自身的用户注册器，并维护与其自身的用户组的关系。每个企业通常具有其自身的认证这些用户的手段。但是，用于本发明的联盟方案允许企业以集体方式协作，从而一个企业中的用户能够通过企业参与企业联盟来利用与一组企业的关系。用户可以在任何联盟企业处被给予对资源的的访问，就像他们具有与每个企业的直接关系那样。不要求用户在每个感兴趣的商业处注册，并且不总是要求用户识别和认证其本身。因此，在此联盟环境中，认证方案允许在信息技术中在快速发展的异构环境中的一次性登录体验。

在本发明的情况下，联盟是一组不同的实体(如企业、企业中的逻辑单元、组织、机构等)，他们协作以为用户提供一次性登录、易于使用的体验；联盟环境不同于典型的一次性登录环境，因为两个企业不需要具有定义传送有关用户的什么信息以及如何传送的直接、预先建立的关系。在联盟环境中，实体提供服务，所述服务处理认证用户、接受由其他实体提供的认证断言(例如，认证令牌)以及提供某种形式的将被担保的用户的身份转换为在本地实体中被理解的身份。

联盟简化了服务提供商的管理负担。服务提供商可以依赖于其与作为一个整体的联盟的信任关系；服务提供商不需要管理认证信息，如用户口令信息，因为其可以依赖于由用户的认证归属域或身份提供商实施的认证。

支持本发明的系统还关心建立基础的联盟身份管理系统，其中松散耦合的认证、用户录用、用户简档管理和/或授权服务跨安全性域进行协作。联盟身份管理允许驻留在全异的安全性域中的服务安全地互操作和协作，即使在这些全异的域中在底层安全性机制和操作系统平台中是存在差异的。

身份提供商与服务提供商

如上所述以及如下文将详述的，联盟环境提供显著的用户优势。联盟环境允许用户在第一实体进行认证，所述第一实体可充当发出在第二实体处使用的有关用户的认证断言的发布方。用户可随后在第二不同的实体(称为依赖方)处通过出示由第一实体发出的认证断言来访问受保护的资源，而不必明确地在第二实体处明确地重新认证。从发布实体传递到依赖实体的信息采取断言的形式，并且该断言可包含采取声明形式的各种不同类型的信息。例如，断言可以是有关用户的被认证身份的声明，或者它可以是有关与特定用户相关联的用户属性信息的声明。此外，可根据依赖方的访问控制规则、身份映射规则、可能还有依赖方维护的一些其他用户属性，由依赖方使用此信息来提供对依赖方的资源的访问。

参见图2，这是一个框图，其相对于一个事务例示了联盟环境的术语，所述事务是由用户向第一联盟企业启动的，所述第一联盟企业作为响应在联盟环境中的下游实体处调用动作。图2示出了对于给定的联盟操作，取决于实体在联盟中的角度，术语可能不同。更具体地说，图2示出支持本发明的计算环境支持信任的传递性和认证断言过程的传递性；域或实体可以根据其对由另一个域或另一个实体所断言的身份的信任发出断言。

用户202通过对在企业204处的受保护资源的请求启动事务。如果用户202已由企业204认证或在事务过程中最终将由企业204认证，那么企业204可被称为用户的针对此联盟会话的归属域。假定此事务要求企业206的某种类型的操作，并且企业204将断言传送到企业206，则企业204是相对于特定操作的发布实体，并且企业206是操作的依赖实体。

发布实体发出由依赖域使用的断言；发布实体通常但不一定必须是用户的归属域或用户的身份提供商。因此，通常是这样的情形：发布方已使用典型的认证操作认证用户。但是，有可能发布方已经先前充当依赖方，由此，其从不同的发布方接收了断言。换言之，由于用户启动的事务可能通过联盟环境中的一系列企业层叠，接收方可能随后充当下游事务的发布方。通常，有能力代表用户发出认证断言的任何实体均可充当发布实体。

依赖实体是从发布实体接收断言的实体。依赖方能够接受、信任和理解由第三方代表用户(即，发布实体)发出的断言；通常是依赖实体的责任来使用适当的认证权威机构来解释认证断言。依赖方是依赖于代表用户或由另一实体出示的断言。在这种方式中，用户可以在依赖实体被给予一次性登录体验，而不要求依赖实体提示用户输入用户的认证凭证作为与用户的交互会话的一部分。

参见图2，假定事务要求进一步的操作，从而企业206将断言传递到企业208，于是企业206是相对于随后或次级事务操作充当发布实体的上游实体，企业208是充当该操作的依赖实体的下游实体；在这种情况下，企业208可被看作是相对于原始事务的另一个下游实体，尽管也可以仅相对于两个实体描述随后的事务。

如图2所示，联盟实体可充当用户的归属域，其提供有关联盟用户的身份信息和属性信息。联盟计算环境中提供身份信息、身份或认证断言或者身份服务的实体可被称为身份提供商。相同联盟中的其他实体或联盟伙伴可依赖于身份提供商进行用户的认证凭证的基本管理，例如接受由用户的身份提供商提供的一次性登录令牌；用户进行认证的域可被称为用户的(认证)归属域。身份提供商可在物理上受到用户的雇主、用户的ISP或一些其他商业实体的支持。

身份提供商是一种特定类型的服务，其将身份信息作为服务提供给联盟计算环境中的其他实体。相对于多数联盟事务而言，认证断言的发布方通常是身份提供商；任何其他实体均可与身份提供商相区别。可将在联盟计算环境中提供服务的任何其他实体分类为服务提供商。一旦用户已经向身份提供商认证，联盟中的其他实体或企业仅在给定的联盟会话或给定的联盟事务中被看作服务提供商。

在一些情况下，在联盟环境中可以有多个实体充当用户的身份提供商。例如，用户可以在多个联盟域中具有帐户，每个联盟域能够充当该用户的身份提供商；这些域不一定具有有关其他域的信息，也不一定具有在不同域处的用户身份。

尽管可能是在联盟环境中有多个企业可充当身份提供商，例如，因为有多个具有生成和确认用户的认证凭证等的能力的企业，联盟事务通常只涉及单个的身份提供商。如果仅有单个的联盟实体能够认证用户，例如，因为在联盟中有且仅有一个用户已经与之进行了联盟录用或注册操作的实体，那么可以期待此实体充当用户的身份提供商，以支持用户在整个联盟环境中的事务。

在一些要求多个服务提供商的互操作的联盟事务中，下游服务提供商可从上游服务提供商接受断言；上游服务提供商可充当作为依赖方的下游服务提供商的发布实体的条件可取决于服务提供商之间信任关系的类型以及服务提供商之间事务的类型。但是，在简单联盟事务的范围中，只有一个实体充当发布实体。

可在给定的计算环境中支持本发明，其中可将联盟基础结构添加到现有系统，同时使对现有的非联盟体系结构的影响降至最小。因此，在任何给定企业或服务提供商处的包括认证操作在内的操作不一定受实体可能还参与联盟环境这一事实的改变。换言之，即使实体的计算系统可能集成到联盟环境中，用户仍能继续以非联盟方式直接执行与企业的各种操作，包括认证操作。但是，用户在相对于给定的实体执行联盟操作时能够具有相同的最终用户体验，就像用户以非联盟方式与给定实体执行了类似操作一样。因此，应当注意，当给定企业参与联盟时，不是给定企业的所有用户都一定参与联盟事务；企业的一些用户可以与企业的计算环境交互而不执行任何联盟事务。

此外，在给定企业的计算环境中的用户注册(例如，在计算机系统中建立用户帐户)不一定受企业可能还参与联盟环境这一事实的改变。例如，用户仍然可以通独立于联盟环境的传统或现存注册过程在域中建立帐户。因此，在某些情况下，当企业参与到联盟计算环境中时，在企业建立用户帐户可能包括也可能不包括跨联盟有效的帐户信息的建立。

联盟体系结构——传统系统的联盟前端

参见图3，图3是一个框图，例示了将给定域处的预先存在的数据处理系统与可用于支持本发明的实施方式的某些联盟体系结构组件相集成。联盟环境包括为用户提供各种服务的联盟实体。用户312与客户机设备314交互，其可能支持浏览器应用316和各种其他客户机应用318。用户312不同于客户机设备314、浏览器316或在用户与其他设备和服务之间充当接口的任何其他软件。在某些情况下，下面的描述可以在用户(在客户机应用中明确动作)和代表用户进行动作的客户机应用之间进行区分。不过，请求者通常是可假定为代表用户操作的中介(如基于客户机的应用、浏览器、SOAP客户机等)。

浏览器应用316可以是典型的浏览器(包括在移动设备中找到的那些)，其包括多个模块，例如HTTP通信组件320和标记语言(ML)解释器322。浏览器应用316还可以支持插件，如web服务客户机324和/或可下载小程序(它们可能要求也可能不要求虚拟机运行时环境)。Web服务客户机324可使用简单对象访问协议(SOAP)，这是在分散、分布式环境中定义结构化和类型化信息的交换的轻量级协议。SOAP是基于XML的协议，其包括三个部分：定义描述消息中有什么以及如何处理它的框架的包络；表示应用定义的数据类型的实例的一组编码规则；以及表示远程过程调用和响应的惯例。用户312可以使用浏览器应用316访问基于web的服务，但是用户312也可以通过客户机设备314上的其他web服务客户机访问web服务。一些联盟操作可通过用户的浏览器使用HTTP重新定向，以在联盟环境的实体中交换信息。但是，应当注意，本发明受到一系列通信协议的支持，并不意味着将本发明限定到基于HTTP的通信。例如，联盟环境中的实体可在必要时直接通信；不要求消息通过用户浏览器来重新定向。

可以按照可将联盟环境要求的组件与现存系统集成的方式来支持本发明。图3示出了将这些组件实现为现存系统的前端的一个实施例。联盟域处的现存组件可被看作传统应用或后端处理组件330，包括与如图4所示的方式类似的认证服务运行时(ASR)服务器332。在域控制对应用服务器334的访问时(这可被看作生成、检索或以其他方式支持或处理受保护资源335)，ASR服务器332负责认证用户。域可以继续使用传统用户注册应用336，以注册用户来访问应用服务器334。相对于传统操作认证注册用户所需的信息被存储在企业用户注册器338中；企业用户注册器338对联盟组件也是可访问的。

在加入联盟环境后，域可以继续操作而不受联盟组件干扰。换言之，可配置域，以便用户可继续直接访问特定的应用服务器或其他受保护资源，而不必通过联系点服务器或其他实施此联系点服务器功能的组件；以这种方式访问系统的用户将经历典型的认证流和典型的访问。但是，这样，直接访问传统系统的用户将无法建立对域的联系点服务器已知的联盟会话。

域的传统功能性可通过使用联盟前端处理340集成到联盟环境中，所述联盟前端处理340包括联系点服务器342和信任代理服务器344(或更简单地说，信任代理344或信任服务344)，其本身与安全性令牌服务(STS)346交互，这在下面相对图4进行描述。联盟配置应用348允许管理用户配置联盟前端组件，以允许其通过联盟接口单元350与传统后端组件进行接口。可以在不同的系统组件或模块中实现联盟功能性。在优选实施方式中，用于执行联盟操作的多数功能性可通过单个联盟应用中的逻辑组件的集合实现；联盟用户生命周期管理应用352包括信任服务344以及一次性登录协议服务(SPS)354。信任服务344可包括身份和属性服务(IAS)356，其负责身份映射操作、属性检索等，作为联盟功能性的一部分。还可以在一次性登录操作期间通过一次性登录协议服务354使用身份和属性服务356。可在特定情况中使用联盟用户注册器358以针对联盟特定的目的维护用户相关的信息。

给定企业处的传统或现存认证服务可以使用各种已知认证服务或令牌，如用户名/口令或者基于智能卡令牌的信息。但是，在优选的支持本发明的联盟计算系统中，可通过使用联系点服务器在联盟环境中使用传统认证服务的功能性。用户可以继续直接访问传统认证服务器，而不通过联系点服务器，不过以这种方式访问的用户将经历典型的认证流和典型的访问；直接访问传统认证系统的用户不能根据本发明生成作为身份证明的联盟认证断言。联盟前端的一个角色是将在联系点服务器接收的联盟认证令牌转换为传统认证服务理解的格式。因此，不一定要求通过联系点服务器访问联盟环境的用户针对传统认证服务进行重新认证。优选地，将通过联系点服务器和信任代理的组合向传统认证服务认证用户，从而好像用户参与认证对话一样。

联盟体系结构——联系点服务器、信任代理和信任中介

参见图4，这是一个框图，例示了一种方式的实例，其中联盟体系结构的某些组件可被用于建立信任关系以支持本发明的实施。联盟环境包括为用户提供各种服务的联盟企业或类似实体。通过客户机设备上的应用，用户可以尝试访问各种实体(如企业410)处的资源。对于来自客户机的访问由企业410支持并通过企业410可用的资源的请求而言，在每个联盟企业处的联系点服务器(如企业410处的联系点(POC)服务器412)是进入联盟环境的入口点。联系点服务器使对现有、非联盟体系结构(如传统系统)中的现存组件的影响降至最小，因为联系点服务器处理许多联盟要求。联系点服务器提供会话管理、协议变换，可能还启动认证和/或属性断言变换。例如，联系点服务器可将HTTP或HTTPS消息转换为SOAP，反之亦然。如下面详述，联系点服务器还可用于调用信任代理以转换断言，例如从发布方接收的SAML令牌可被转换为接收方理解的Kerberos令牌。

信任服务(也称为信任代理、信任代理服务器或信任服务)，如企业410处的信任代理(TP)414，建立并维护联盟中两个实体之间的信任关系。信任服务通常具有将发布方使用的格式转换为可由接收方理解的格式的认证令牌格式转换能力(通过安全性令牌服务，如下详述)。

联系点服务器和信任服务的使用一起减小了实施联盟体系结构对现有、非联盟系统集合的影响。因此，示例的联盟体系结构要求每个联盟实体实施至少一个联系点服务器和至少一个信任服务，无论实体是企业、域、或者其他物理或逻辑实体。不过，示例性的联盟体系结构不一定要求对现有、非联盟系统集合的任何改变。优选地，对于给定的联盟实体有单个信任服务，虽然为了可用性目的，可以有信任服务组件的多个实例，或者对于联盟实体中的各种较小实体有多个信任服务，例如，企业中的独立子公司。有可能给定的实体可能属于一个以上的联盟，不过这种情况不一定要求多个信任服务，因为单个信任服务可能能够管理多个联盟中的信任关系。

信任服务的一个角色可以是确定或负责确定另一个域和/或该域中的信任服务要求的令牌类型。信任服务具有处理将发布方使用的格式转换为可由接收方理解的格式的认证令牌格式转换的能力或责任。信任服务414还负责在企业410中发生的任何用户身份转换或属性转换，或者此责任可由不同的身份和属性服务(如图3所示的身份和属性服务356)支持。此外，信任代理可以支持实施别名，作为唯一识别用户的用户身份的代表，而不会提供有关用户真实身份的任何信息。此外，信任代理可以发出授权和/或会话凭证，以由联系点服务器使用。但是，信任服务可以调用信任中介作为辅助，如下所述。可能要求身份转换以将对发布方已知的用户身份和属性转换为对接收方有意义的情形。这种转换可由发布实体处的信任服务调用，也可由接收实体处的信任服务调用，或者由这二者调用。

信任服务414，或者如上所述的不同的身份和实现服务，可包括内部化的组件(或与之交互)，表示为安全性令牌服务(STS)组件416，其将提供令牌转换并将调用认证服务运行时(ASR)418，以确认和生成令牌。安全性令牌服务提供信任服务所要求的令牌发布和确认服务，这可包括身份转换。因此，安全性令牌服务包括对现有认证服务运行时的接口，或者它将认证服务运行时纳入服务本身中。除了在信任服务中被内部化，安全性令牌服务还可被实现为独立的组件，例如，以便由信任服务器调用，或者它可以在事务服务器中被内部化，例如作为应用服务器的一部分。

例如，安全性令牌服务组件可接收发出Kerberos令牌的请求。作为要为其创建令牌的用户认证信息的一部分，该请求可包括含有用户名和口令的二进制令牌。安全性令牌服务组件将针对例如LDAP运行时确认用户名和口令(典型认证)，并将调用Kerberos KDC(密钥分布中心)以生成此用户的Kerberos票券(ticket)。此令牌被返回给信任服务以在企业中使用；但是，此使用可包括对令牌进行外部化，以传送到联盟中的另一个域中。

用户可能希望访问联盟环境中多个企业(如企业410和企业420)处的资源。与如上对企业410描述的情况类似，企业420包括联系点服务器422、信任服务424、安全性令牌服务(STS)426和认证服务器运行时428。虽然用户可直接启动与每个企业的独立事务，但是用户可以启动与企业410在联盟环境中层叠的事务。企业410可能要求与联盟环境中的多个其他企业(如企业420)协作，以完成特定事务，即使用户可能在其启动事务时并不知道这种必要性。企业420作为下游实体参与进来，如有必要，企业410可将断言呈现给企业420，以便进一步进行用户的联盟事务。

可能信任服务不知道如何解释由关联的联系点服务器接收的认证令牌和/或如何转换给定的用户身份和属性。这时，信任服务可选择调用信任中介组件处的功能性，如信任中介430。信任中介维护与各个信任代理/服务的关系，由此提供信任服务间的可迁移的信任。使用信任中介允许联盟环境中的每个实体(如企业410和420)与信任中介建立信任关系，而不是与联盟环境中的每个实体建立多个单独的信任关系。例如，当企业420作为下游实体参与到由企业410处的用户启动的事务中时，企业410处的信任服务414可确信企业420处的信任服务424能够通过在必要时调用信任中介430处的帮助，以理解来自信任服务414的断言。尽管图4示出具有单个信任中介的联盟环境，但是联盟环境可具有多个信任中介。

应当注意，尽管图4示出联系点服务器412、信任服务414、安全性令牌服务组件416和认证服务运行时418作为不同的实体，但是这些组件不一定在单独的组件上实施。例如，可以将这些单独组件的功能性实施为单个应用、单个物理设备上的多个应用、或者多个物理设备上的分布式应用。此外，图4描述了企业的单个联系点服务器、单个信任服务、单个安全性令牌服务，但是替代的配置可每个企业包括多个联系点服务器、多个信任服务和多个安全性令牌服务。联系点服务器、信任服务、安全性令牌服务和其他联盟实体可以各种形式实现，如软件应用、对象、模块、软件库等。

信任服务/STS可能能够接受和确认不同的认证凭证，包括传统凭证，如用户名和口令组合和Kerberos票券，以及联盟认证令牌格式，包括由第三方产生的认证令牌。信任服务/STS可允许接受认证令牌，作为其他地方的认证的证明。认证令牌由发布方产生，并用于指示用户已向该发布方认证。发布方产生认证令牌，作为断言用户的已认证的身份的手段。信任服务/STS还能够处理属性令牌或用于保证通信会话或对话安全的令牌，例如，那些用于以类似于SSL会话标识符的方式管理会话信息的令牌。

安全性令牌服务在必要时调用认证服务运行时。认证服务运行时支持能够认证用户的认证服务。认证服务充当认证权威机构，通过认证响应提供成功或失败认证尝试的指示。信任服务/STS可使认证服务内部化，例如其中存在不需要与现有传统基础结构交互的web服务的全新安装的情形。否则，安全性令牌服务组件将调用外部认证服务来确认认证令牌。例如，安全性令牌服务组件可“解包”含有用户名/口令的令牌，然后使用LDAP服务访问用户注册器以确认示出的凭证。

当由另一个组件(如应用服务器)使用时，安全性令牌服务组件可被用于产生一次性登录到传统认证系统所需的令牌；这个功能可与一次性登录协议服务(如图3所示的SPS 354)中的功能性组合或被其替代。因此，安全性令牌服务组件可用于内部目的(即，在企业内部)和用于外部目的(即，跨联盟中的企业)的令牌转换。作为内部目的的例子，Web应用服务器可通过IBM CICS(客户信息控制系统)事务网关与主机接口；CICS是一系列应用服务器和连接器，其为使命重要的应用提供企业级在线事务管理和连接性。Web应用服务器可调用安全性令牌服务组件以将Kerberos票券(如由Web应用服务器内部使用的)转换为CICS事务网关要求的IBM

通票。

如图4所示的实体可使用如前面介绍的术语来解释，如“身份提供商”和“服务提供商”。作为建立和维护信任关系的一部分，身份提供商的信任服务可确定服务提供商的信任服务要求/接受什么令牌类型。因此，在从安全性令牌服务调用令牌服务时，信任服务使用此信息。当需要身份提供商的信任服务来产生服务提供商的认证断言时，信任服务确定所需的令牌类型，并从安全性令牌服务请求适当的令牌。

当服务提供商的信任服务从身份提供商接收认证断言时，信任服务知道期待哪种类型的断言以及需要在服务提供商内部使用什么类型的断言。因此，服务提供商的信任服务请求安全性令牌服务根据接收的认证断言中的令牌生成所需的内部使用令牌。

信任服务和信任中介均具有将从身份提供商接收的断言转换为由服务提供商理解的格式的能力。信任中介具有解释对于与之具有直接信任关系的每个信任服务的断言格式的能力，由此允许信任中介在身份提供商和服务提供商间提供断言转换。这种转换可由任一方通过其本地信任服务请求。因此，身份提供商的信任服务可请求在其被发送到服务提供商之前转换断言。同样，服务提供商的信任服务可请求转换从身份提供商接收的断言。

断言转换包括用户身份转换、认证断言转换、属性断言转换或其他形式的断言转换。重述前面的内容，由联盟重的信任组件(如信任服务和信任中介)处理断言转换。信任服务可本地执行转换，无论在身份提供商或在服务提供商，或者信任服务可从信任中介调用帮助。

假定身份提供商和服务提供商已经具有与信任中介的单个信任关系，信任中介可动态创建，即中介(broker)，发布方和依赖方之间的新的信任关系(如有必要)。在由信任中介提供的信任关系中介操作后，身份提供商和服务提供商可直接维护关系，从而不需要针对未来的转换要求调用信任中介。应当注意，认证令牌的转换可发生在三个可能的位置：身份提供商的信任服务、服务提供商的信任服务和信任中介。优选地，身份提供商的信任服务生成信任中介理解的认证断言以发送给服务提供商。随后，服务提供商请求将来自信任中介的此令牌转换为可由服务提供商识别的格式。令牌转换可发生在认证断言的传输之前、传输之后或者在传输之前和传输之后都发生。

联盟体系结构中的信任关系

在能够支持本发明的示例性联盟环境中，有必须管理的两种类型的“信任域”：企业信任域和联盟信任域。这两种类型的信任域之间的差别部分地基于管理与信任域的信任关系的商业协议和用于建立信任的技术。企业信任域包含由企业管理的那些组件；该信任域中的所有组件可默示地彼此信任。通常，在企业中建立信任不需要商业协议，因为部署的技术在企业内部创建固有的信任，例如通过要求组件间的互相认证的SSL会话或通过将组件放置在单个、紧密控制的数据中心中，从而物理控制和接近证明默示信任。参见图2B，传统应用和后端处理系统可代表企业信任域，其中组件在安全内部网络上通信。

联盟信任域是跨企业边界的域；从一个角度讲，联盟信任域可代表不同企业信任域间的信任关系。联盟信任域跨联盟伙伴间的企业边界通过信任代理建立。信任关系涉及某种类型的自举(bootstrap)过程，借此在信任代理间建立初始信任。此自举过程的一部分可包括建立共享密钥和定义预期和/或允许的令牌类型和标识符转换的规则。通常，此自举过程可在带外实施，因为此过程也可以包括建立管理企业参与联盟的商业协议和与此参与关联的库。

在联盟商业模型中建立信任有若干种可能的机制。在联盟模型中，出于商业原因，需要联盟参与者间的信任的基本概念，以便提供一定等级的确信：在参与者之间传递的断言(包括令牌和属性信息)是有效的。如果没有信任关系，那么服务提供商不能依赖于从身份提供商接收的断言；服务提供商不能使用它们来确定如何解释从身份提供商接收的信息。

例如，大型公司可能希望链接数千个全球客户，并且该公司可以使用非联盟解决方案。作为第一个例子，公司可以要求全球客户使用来自商业许可证权威机构的数字许可证以建立相互信任。商业许可证权威机构使得公司处的服务器能够信任在每个全球客户处的服务器。作为第二个例子，公司可以使用Kerberos实施第三方信任；公司及其全球客户可以实施被信任的第三方Kerberos域服务(其实现基于共享秘密的信任)。作为第三个例子，公司可以建立具有由其全球客户的服务器相互信任的所有权安全性消息令牌的专有方案。

如果公司需要管理与较小数量的全球客户的信任关系时，这些方案中任何一个均是可接受的，但如果有成百上千的潜在联盟伙伴，则这可能变得不可管理。例如，尽管可能公司强迫其较小的伙伴实施专有方案，但公司不可能对其较大的伙伴施加许多要求。企业可以使用通过信任代理和还可能通过信任中介建立和维护的信任关系。图示的示例性联盟体系结构的优势在于，其不施加高于和超过企业及其潜在联盟伙伴的当前基础结构的额外要求。

但是，这种示例性联盟体系结构并不使企业及其潜在联盟伙伴省去建立商业和库协议(参与联盟所要求的)所需的基础工作。此外，参与者不能忽略信任关系的技术自举。示例性联盟体系结构允许此自举是灵活的，例如第一联盟伙伴可以发出具有特定信息的Kerberos票券，而第二联盟伙伴可发出具有特定信息的SAML认证断言。

在示例性联盟体系结构中，由信任代理管理信任关系，这可包括根据两个信任代理间预先建立的关系确认和转换从身份提供商接收的令牌的安全性令牌服务(或者与之交互)。在一个联盟企业建立与另一个联盟企业的信任关系(或令牌转换不可行的情况下)不可行的情况下，可以调用信任中介；但是，联盟企业需要与信任中介建立关系。

参见图5，是一个框图，例示了根据能够支持本发明的示例联盟体系结构，使用信任代理和信任中介在联盟域之间的一组示例性信任关系。虽然图4介绍了信任中介，图5例示了示例性联盟体系结构中迁移的信任关系的重要性。

联盟域502-506分别包括信任代理508-512。信任代理508具有与信任代理510的直接信任关系514。信任中介520具有与信任代理510的直接信任关系516，并且信任中介520具有与信任代理512的直接信任关系518。信任中介520用于根据与其他联盟伙伴的迁移的信任，代表联盟参与者建立信任关系。迁移的信任的原则允许信任代理510和信任代理512通过信任中介520具有中介的信任关系522。信任代理510或512都不需要知道如何转换或确认彼此的断言；可以调用信任中介以将断言转换为有效的、信任的、在另一个信任代理可以理解的断言。

可通过使用ebXML(使用XML的电子商务)标准相对于联盟企业间的关系规定合同义务的商业协议和库。例如，可用ebXML文档表示直接信任关系；共享直接信任关系的每个联盟域会具有表示为ebXML文档的合同的副本。联盟中各种实体的操作特征可在ebXML编排中规定和在ebXML注册器中公布；希望参与特定联盟(例如，操作信任代理或信任中介)的任何企业将需要遵从由该特定联盟为联盟中的所有信任代理或信任中介规定的已公布要求。安全性令牌服务可解析这些ebXML文档，以获得有关转换来自其他域的令牌的方式的操作细节。不过，应当理解，可以使用其他标准和机制来支持本发明，以规定实施联盟中的信任关系的方式的细节。

联盟体系结构中的一次性登录

在给定的用户会话期间，用户可访问许多联盟域以使用那些域提供的web服务。域可以公布它们使用标准规范(如UDDI和WSDL，这二者均使用XML作为共同数据格式)提供的服务的描述。用户通过也遵从这些标准规范的应用找到可用服务和服务提供商。SOAP提供用于传递以XML表示的请求和响应的范例。联盟环境中的实体可以使用这些标准等。

在联盟中，用户期待具有一次性登录的经历(其中用户完成单次认证操作)，并且此认证操作足以用于用户会话的持续时间，而不管联盟伙伴在该会话期间进行访问。会话可被定义为从(并且包括)初始用户认证(即登录)到登出的一组事务。在会话中，用户的动作将部分由针对该会话授予该用户的特权来管理。

如上描述的联盟体系结构支持一次性登录操作。为了促进一次性登录体验，支持联盟环境的web服务也将支持使用由第三方产生的认证断言或安全性令牌来提供用户认证的证据。此断言将包含某种类型的用户成功向发布方进行认证的证据以及该用户的标识符。例如，用户可以与一个联盟伙伴完成传统的认证操作，例如通过提供该联盟伙伴用于建立该用户的认证凭证的用户名和口令，并且然后联盟伙伴能够将由认证/发布方生成的SAML认证断言提供给不同的联盟伙伴。

联盟环境还允许web服务或其他应用来请求web服务，并且这些web服务也会被认证。Web服务环境中的认证是核实web服务请求的号称的身份、从而企业会限制对授权客户机的访问的动作。请求或调用web服务的用户总是会被认证，所以在支持本发明的联盟环境中的认证的需求与用于用户认证的web服务的当前要求没有任何不同。

认证访问企业计算资源而不参与联盟会话的用户不受联盟基础结构的存在的影响。例如，通过HTTP/S与基于形式的认证机制进行认证以访问特定域处的非联盟资源的现存用户不受针对联盟环境在域处的支持的引入。部分通过联系点服务器(其又可以调用单独的信任代理或信任服务组件)处理认证；使用联系点服务器减小对现有域的基础结构的影响。例如，可将联系点服务器配置为传递要由域处的后端或传统应用和系统处理的所有非联盟请求。

联系点服务器可选择调用基于HTTP的认证方法，如基本认证、基于形式的认证或某些其他认证方法。联系点服务器还通过支持已由用户作为认证(如SAML认证断言)的证明出示的断言的处理来支持联盟域，其中断言已跨在企业域之间；一次性登录服务用于识别断言/人造物品(artifact)(当其在联盟协议的上下文中接收时)。联系点服务器可调用信任服务，其又可调用其安全性令牌服务，以确认认证凭证/安全性令牌。

web服务或其他应用的认证包括与用户认证的相同的过程。来自web服务的请求可携带包含认证断言的安全性令牌，并且此安全性令牌将由信任服务与由用户出示的令牌相同的方式确认。来自web服务的请求可被此令牌伴随，因为web服务应已发现请求的服务要求什么认证断言/安全性令牌，如在UDDI中通知的那样。

参见图6，是一个框图，例示了支持联盟一次性登录操作的联盟环境。通过客户机设备和适当的客户机应用，如浏览器，用户600希望访问由企业/域610提供的web服务，所述企业/域610支持充当联盟环境中的联盟域的数据处理系统。域610支持联系点服务器612和信任代理或信任服务614；类似的，域620支持联系点服务器622和信任代理或信任服务624，而域630支持联系点服务器632和信任代理或信任服务634。信任代理/服务依赖于信任中介650的帮助，如上所述。额外的域和信任代理/服务可以参与联盟环境。图6用于描述域610和域620之间的联盟一次性登录操作；可在域610和域630之间发生类似的操作。

用户完成相对于域610的认证操作；此认证操作由联系点服务器612处理。当用户请求访问要求认证的身份的某些资源(例如为了访问控制目的或个性化目的)时，触发认证操作。联系点服务器612可调用传统的认证服务，或者其可调用信任代理614以确认用户出示的认证凭证。在用户的联盟会话期间，域610变为用户的身份提供商或归属域。

在稍后的时间点上，用户在联盟伙伴(如也支持联盟域的企业620)启动事务，由此触发联盟一次性登录操作。例如，用户可以在域620启动新的事务，或者用户的原始事务可层叠到其他域处的一个或多个额外事务中。作为另一个例子，用户可以通过联系点服务器612调用对域620中的资源的联盟一次性登录操作，例如通过选择在域610中托管的web页面上的特殊链接或者通过请求在域610中托管但显示在域620中托管的资源的门户页面。联系点服务器612将请求发送到信任代理614以为用户生成格式化为由域620理解或信任的一次性登录令牌。信任代理614将此令牌返回到联系点服务器612，其将此令牌发送到域中的联系点服务器622。域610充当域620处的用户的发布方，域620充当依赖方。用户的令牌会与用户的请求一同传送到域620，此令牌可通过用户浏览器使用HTTP重定向进行发送，或者其可通过代表在由信任代理614提供的令牌中识别的用户，直接对于联系点服务器622(通过HTTP或者SOAP-over-HTTP)调用该请求来进行发送。

联系点服务器622接收请求以及联盟一次性登录令牌并调用信任代理624。信任代理624接收联盟一次性登录令牌、确认令牌，假定令牌是有效的和被信任的，为用户生成本地有效的令牌。信任代理624将本地有效的令牌返回给联系点服务器622，其为域620中的用户建立会话。如有必要，联系点服务器622可在另一个联盟伙伴启动联盟一次性登录。

域620处的令牌确认由信任代理624处理，可能是在安全性令牌服务的帮助下。取决于域610出示的令牌的类型，安全性令牌服务可能需要访问域620处的用户注册器。例如，域620可提供包含要相对于域620处的用户注册器进行确认的用户名和口令的二进制安全性令牌。因此，在此例中，企业简单地从联盟伙伴确认安全性令牌。域610和620间的信任关系确保域620可以理解和信任域610代表用户出示的安全性令牌。

联盟一次性登录不仅要求在依赖域确认代表用户出示给依赖域的安全性令牌，而且根据包含在安全性令牌中的信息还要求确定本地有效的用户标识符可能还有与此标识符关联的属性。直接信任关系和建立此关系所需的商业协议的一个结果是发布域或依赖域中至少一方或这二者知道如何将发布域提供的信息转换为在依赖域有效的标识符；依赖域中的此标识符可以是由发布方断言的身份的一对一映射的结果或者可能是另一类型的映射的结果，例如身份到角色的多对一映射(即，不要求这是本地发布方标识符的唯一一对一映射)。在上面的简单例子中，假定发布域(即域610)能够向依赖域(即，域620)提供在域620中有效的用户标识符。在此情况下，依赖域不需要调用任何身份映射功能。域620处的信任代理624将为用户生成为此用户“担保”的安全性令牌。接受的令牌类型、在令牌上要求的签名以及其他要求都作为联盟商业协议的一部分预先建立。管理标识符转换的规则和算法也作为联盟商业协议的一部分预先建立，并由对于令牌管理和交换的议定策略进行定义。在两个参与者间的直接信任关系的情况下，标识符转换算法应已为那两方建立并且可能不与联盟中的任何其他方相关。

但是，并不总是发布域知道如何将用户从域610的本地标识符映射到域620的标识符。在某些情况下，可能是依赖域知道如何进行此映射，而在其他情况下，任何一方均不知道如何进行此转换，此时可能需要调用第三方信任中介。换言之，在中介的信任关系的情况下，发布域和依赖域彼此之间不具有直接的信任关系。但是，它们具有与信任中介的直接信任关系，如信任中介650。标识符映射规则和算法将作为此关系的一部分被建立，并且信任中介将使用此信息来帮助进行中介的信任关系所要求的标识符转换。

域620在联系点服务器622接收域610发布的令牌，所述联系点服务器622调用信任代理624以确认令牌并执行身份映射。在此情况下，由于信任代理624不能将用户从域610的本地标识符映射为域620的本地标识符，信任代理624调用信任中介650，其确认令牌并执行标识符映射。在获得了用户的本地标识符后，信任代理624，可能通过其安全性令牌服务，可生成由域620处的后端应用要求的任何本地令牌，例如可能要求Kerberos令牌以便于从联系点服务器到应用服务器的一次性登录。在获得了本地有效的令牌后，如果需要，联系点服务器能够为用户建立本地会话。联系点服务器还可以处理用户请求的粗粒度授权，并将授权的请求转发到域620中的适当应用服务器。

联盟用户生命周期管理

图2-6的说明中的一部分解释了可用于联盟环境的组件的组织，而其他部分则解释了跨联盟环境支持一次性登录操作的过程。联盟环境中的服务提供商或依赖域不一定必须管理用户的认证凭证，并且那些依赖域可利用由用户的身份提供商或归属域提供的单个一次性登录令牌。不过，上面图2-6的描述没有解释可在联盟伙伴的联盟域处以有利的方式实现联盟用户生命周期管理的明确过程。

联盟用户生命周期管理功能性/服务包括相对于多个联盟域处给定用户的特定用户帐户或用户简档支持或管理联盟操作的功能；在某些情况下，功能或操作限于用户的给定联盟会话。换言之，联盟用户生命周期管理功能性指的是可能仅在联盟计算环境中单个用户会话的生命周期期间，允许跨多个联盟伙伴管理联盟操作的功能。

每个联盟域可能相对于每个相应联盟域处的功能管理用户帐户、用户简档或者某种类型的用户会话。例如，特定的联盟域可能不管理该特定联盟域中的本地用户帐户或用户简档，但该联盟域可能管理在成功完成联盟域处的一次性登录操作后的联盟事务的本地用户会话。作为由该特定联盟域支持的联盟用户生命周期管理功能性的一部分，联盟域可参与一次性登出操作，这允许在联盟事务完成后联盟域终止本地用户会话，由此改进安全性和促进资源的有效使用。

在使用联盟用户生命周期管理功能性的另一个例子中，用户可以参与要求加入多个联盟域的在线事务。联盟域可以本地管理用户简档，以便适应在每个涉及联盟域的用户联盟会话期间相对于联盟域的用户体验。作为由该特定联盟域支持的联盟用户生命周期管理功能性的一部分，在给定的联盟事务期间，可以无缝方式使用联盟域的本地用户简档中的信息以及来自参与给定的联盟事务的其他联盟域处的其他简档的信息。例如，来自用户的多个本地用户简档的信息可在特定类型的合并操作中被组合，从而用户的信息在视觉上被呈现给用户，例如在web页面中，从而用户不知晓用户信息的不同始发地或源头。

联盟用户生命周期管理功能性还可以包括帐户链接/取消链接的功能。为用户提供跨联盟伙伴共同的唯一用户标识符，这使得能够进行一次性登录和检索有关用户的属性(如有必要)，作为在一个联盟伙伴进行请求完成的一部分。此外，联盟伙伴可使用共同的唯一用户标识符从身份提供商请求额外的属性，以便以匿名方式指向用户。

参见图7，是一个框图，例示了用于实施联盟用户生命周期管理功能性以便支持本发明的联盟域中的某些组件。图7描述了单个联盟域(如图3所示的联盟域)的组件。图7的某些组件与参照前面的图(例如图3)讨论的组件类似或相同：联系点服务器/服务702等同于联系点服务器342；运行控制对受保护资源的访问的服务的应用服务器704等同于应用服务器334；受保护或控制的资源706等同于受保护资源335；并且联盟用户生命周期管理(FULM)应用708等同于联盟用户生命周期管理应用352。尽管图3中没有示出防火墙，但是在图7中示出了防火墙。防火墙710和防火墙712创建外部DMZ(电子禁区：electronic DeMilitarized Zone)，其保护企业的计算环境不受企业域外部(例如通过因特网)的威胁的侵害。

图3和图7中的不同角度并非不兼容的或目的相反的。与图7中所示的示例相反，图3没有示出防火墙，而且联系点服务器342驻留在联盟前端340中；此外，联盟用户生命周期管理应用352包含在联盟前端340中。在图7中，联系点服务器702被示为驻留在防火墙710和712(其构成企业域的电子或物理前端)间的DMZ中；此外，联盟用户生命周期管理应用/服务708以电子方式驻留在防火墙712后面。信任服务714、一次性登录协议服务716以及身份和属性服务718采用企业用户注册器720和联盟用户注册器722(如有必要)。通过将图3中的联盟前端340和后端330看作组件的逻辑组织，同时将图7的DMZ和其他组件看作为形成物理或电子前端以及物理或电子后端，这二者任何之一可包含联盟组件，图3和图7的不同角度是可以被接受的。

重述联系点实体/服务的角色，联系点实体提供会话管理，至少相对于用户与具有企业的计算环境的联盟功能性的交互；企业计算环境的传统后端中的应用也可以实施其自身的会话管理功能性。假定企业相对于联盟计算环境实施策略功能性，联系点实体可充当某个其他联盟伙伴的策略决定点的策略强制执行点。此外，假定给定联盟功能性的实施，联系点实体负责在不使用一次性登录操作的那些情况中相对于用户启动方向认证操作是可允许的。如此，联系点实体可以多种形式实施，例如作为反向代理服务器、作为web服务器插件或以某种其他方式。联系点功能性也可以在应用服务器本身中实施，在这种情况下，联盟用户生命周期管理服务可在逻辑上位于DMZ中。

更重要的是，再次参见图7，联盟用户生命周期管理应用708还包括对与联盟用户生命周期管理插件724(在图3中未示出)接口、交互或以其他方式进行互操作的支持。在图7的示例性体系结构中，联盟协议运行时插件提供用于各种类型的独立公布或开发的联盟用户生命周期管理标准或简档的功能性，如：WS联盟无源客户机；以及库联盟ID-FF一次性登录(B/A、B/P和LECP)、注册名标识符、联盟终止通知和一次性登出。可在不同的URI访问不同组的联盟协议。此手段允许联盟用户生命周期管理应用在单个应用中并行支持联盟用户生命周期管理的多个标准或规范，如WS联盟web服务规范与库联盟规范，由此最小化对支持不同联盟协议的总体环境的配置影响。

更具体地说，通过适当地将用户请求重定向和/或转发到联盟用户生命周期管理应用，可由联系点服务器调用适当的联盟用户生命周期管理功能性。再次参见图7，联系点服务器702接受用户请求730，其随后被分析以确定已接收的请求类型，这可能由已接收的请求消息类型指出，或者如上所述，通过确定请求消息中的目的地URI来指出。虽然对于受保护资源的请求732被继续转发给应用服务器704，将对于联盟用户生命周期管理功能的请求734(如调用一次性登出操作的请求)转发给联盟用户生命周期管理应用708，其根据需要调用适当的联盟用户生命周期管理插件，以满足接收的请求。当定义新的联盟协议或新的联盟功能时，或者当现有的联盟协议或联盟功能被以某种方式修改或改进了，可简单地通过插入新的支持模块来加入支持，或者可通过修改先前安装的插件来改进支持。

图7的联盟用户生命周期管理应用的实施的示例示出联盟用户生命周期管理应用能够支持多个同时联盟用户生命周期管理功能，并且提供可插入(pluggability)特性，由此允许在需要时以插件的形式将新功能性加入到联盟用户生命周期管理应用，而不需要对现有基础结构的任何改变。例如，假定使用基于Java^TM的联盟用户生命周期管理应用实施本发明，可通过将新开发的Java^TM类配置为联盟用户生命周期管理应用的Java^TM CLASSPATH来添加对新联盟协议(如，新公布的一次性登录协议)的支持，其中这些新的类支持新标准以及协议接口，以支持本发明。

示例性的联盟体系结构利用其中要集成联盟用户生命周期管理解决方案的现有环境。可以容易地修改联盟用户生命周期管理应用，以随着新的协议/标准的发展支持它们，同时对总体基础结构有很小的改变。支持新的联盟用户生命周期管理功能性可能需要的任何变化几乎独占地位于联盟用户生命周期管理应用中，这将要求配置联盟用户生命周期管理应用以理解添加的功能性。

在其他联盟组件中可能有最小的配置改变，例如在联系点服务器中，以便允许总体基础结构能够调用新的联盟用户生命周期管理功能性，同时继续支持现有的联盟用户生命周期管理功能性。但是，联盟用户生命周期管理应用在功能上独立于剩余的联盟组件，因为联盟用户生命周期管理应用可能只要求与联盟环境的其他联盟组件的最小交互。例如，在示例性实施方式中，联盟用户生命周期管理功能性可能与基于企业的数据存储库(如LDAP数据存储库)集成，如果联盟用户生命周期管理信息(如根据库联盟简档的NameIdentifier值)将保存在外部可访问的联盟用户生命周期管理数据存储库而不是专用的内部联盟用户生命周期管理数据存储库(对外部实体不明显或不可访问)中。

因此，现有环境需要极小的变化来支持联盟用户生命周期管理功能性。而且，对联盟用户生命周期管理功能性的改变(包括添加新的功能性)对现有联盟环境具有很小的影响。因此，当公布新的一次性登录标准时，容易添加对此标准的支持。

传统的用户认证仅涉及企业计算环境和最终用户的交互；企业选择实施此认证相互交换的方式是该企业的选择，这对任何其他企业没有影响。但是，当希望支持联盟或跨域一次性登录功能性时，则需要企业合作伙伴彼此交互。这一要求不能使用专用协议可缩放地进行。尽管直接将对基于标准的联盟协议的支持直接添加到联系点实体看来是个鲁棒的解决方案，但是必须修改作为已经存在于企业的计算环境中的现有组件的联系点实体；而且，每次这些公开的联盟协议之一改变时都必须修改。将此功能性移出联系点实体提供了更为模块化的途径，其中此可插拔的功能性使得易于维护对这些协议的迁移或更新。

在分布式数据处理系统中实施浮动身份提供商

如上所述，在实施联盟协议操作时需要考虑一个折中。一些操作(如，那些可能要求与用户的最小交互以完成操作的操作)应当以对用户的负担最小的方式执行，但它们也应当以对联盟企业有效的方式执行，特别是对于可能对企业中的所有用户都需要的那些操作类型。相对于支持特定的联盟协议所要求的操作，联盟企业可能对实施那些操作的方式以及对用户和对联盟企业的计算资源带来的负担方面不具有大的灵活性。可能要求联盟企业根据联盟企业同意的联盟规范以特定方式执行特定动作。换言之，可通过商业合同要求联盟企业实施特定联盟操作，而不管那些操作的计算负担。

但是，联盟环境中的功能性的许多方面可被分类为支持一个或多个商业目标的操作，所述目标是由联盟中的一个或多个企业期望的，但是不一定要求它们以便支持联盟协议或者不一定要求它们以便参与到联盟中。由于所得到的用于支持企业特定的商业目标的动作可能在联盟环境中有多个分支，实施支持操作的方式应当以在联盟中的成千或成百万用户间是可缩放的方式来完成。在实施期望的企业商业目标时，有责任管理企业中的联盟功能的系统管理员应能够以有效的方式配置其计算资源。

如上所述，处理对联盟企业中的计算资源的负担的一种方式是在分布式数据处理系统中实施联盟功能性。但是，分布式数据处理系统的特性可能是有问题的；联盟协议的一些要求可能使在分布式数据处理系统中执行那些联盟协议的功能性的实施变得复杂。例如，可在分布式数据处理系统中支持身份提供商的服务；但是在现有技术实施之前，以不在分布式数据处理系统中实施它们的方式静止地将身份提供商分配给客户机或服务提供商。

为了改进身份提供商的现有技术实施，本发明提供了用于有效管理联盟协议操作(特别是相对于在分布式数据处理系统中实施身份提供商)的分布式计算基础结构。本发明允许将联盟实体(如，服务提供商)定向到适当的数据处理系统或数据中心(其在较大的分布式数据处理系统中提供身份提供商的功能性，同时仍然允许具有分布式数据处理系统的优势)。本发明的方式提供了实施身份提供商的资源的灵活分配，同时为联盟实体提供从身份提供商期待的功能性。

参见图8A，是一个框图，例示一个联盟实体，其实施为分布式数据处理系统以支持用于实施身份提供商功能性的资源的灵活分配。图8A示出了联盟计算环境中的多个联盟实体，即联盟。联盟实体可包括服务提供商(如服务提供商802)、身份提供商(如身份提供商804)以及客户机(如客户机806)，它们受到各种联盟服务提供商、联盟身份提供商或其他联盟实体(均通过联盟空间中的一个或多个网络，如网络808，通信)的支持或与之交互。联盟实体810是联盟环境中的一个一般化的实体，取决于正在发生的联盟操作的类型，其可代表服务提供商、身份提供商或典型的联盟客户机。

联盟实体820通常与其他联盟实体(如，联盟实体810)交互。虽然图8A的例子集中于联盟实体820包括充当身份提供商的功能性的事实，但应当注意，联盟实体820可包括额外的联盟功能性，如与服务提供商或某个其他类型的联盟实体相关联的联盟功能性(取决于正在发生的联盟操作的类型)。例如，联盟实体820可生成包括与安全性相关的数据对象在内的数据对象，如认证凭证或用户属性断言，或者数据对象可包括媒体内容、科学数据或某种其它类型的一般化数据。从这个角度讲，联盟实体810一般可被看作提交请求消息以访问联盟实体820处的资源的请求联盟实体，而联盟实体820可被看作将具有数据的响应消息返回到联盟实体810的响应联盟实体。在典型的操作中，如请求的或要求的，联盟实体820可发出断言，例如SAML断言，如上所述。联盟实体810可根据用于不同联盟计算环境的一个或多个规范，使用用于各种联盟协议操作/简档的那些断言，例如，以便完成联盟一次性登录认证操作。

现在介绍本发明的更为重要的全新方面，图8A还示出了根据本发明的联盟实体的实施方式，其中联盟实体被组织为作为身份提供商支持执行操作的分布式功能性的分布式数据处理系统。为了分布其处理负载，联盟实体820可选地使用负载均衡器822，在多个数据处理系统(如数据处理系统824、数据处理系统826和数据处理系统828)间接收和转发到来的请求消息，如请求根据联盟协议执行操作的请求；因此，联盟实体820是具有一组多个数据处理系统824-828的分布式数据处理系统。负载均衡器822可采用各种已知算法来在多个数据处理系统间分布工作负载，包括图形分布，如其中将来自给定区域中的用户请求定向到相同地理区域中的数据中心。

相对于多个数据处理系统的数据业务量以类似图7所示的方式通过防火墙和联系点服务器。数据处理系统824的数据业务量通过防火墙830、联系点服务器832和防火墙834。数据处理系统826的数据业务量通过防火墙836、联系点服务器838和防火墙840。数据处理系统828的数据业务量通过防火墙842、联系点服务器844和防火墙846。在本发明的一个实施例中，数据处理系统824-828及其关联的基础结构可代表地理上分布的数据中心，由此允许负载均衡器822在数据处理系统824-828间，以对资源请求的始发地和数据处理系统824-828的位置在地理上适当的方式，分布数据业务量及关联的处理负载。对于地理分布的数据中心，防火墙836、联系点服务器838和防火墙840又可代表被复制以确保数据中心中的高度可用性的一组机器。

尽管图8A中没有详细示出，数据处理系统824-828包含处理联盟协议操作/简档(如上已经参考其他附图进行了讨论，例如由图3所示的联盟前端340和图7的防火墙712后面的组件表示的部分)的功能性。例如，每个数据处理系统824-828包含联盟用户生命周期管理(FULM)组件，其类似于图3中的FULM 352和图7中的FULM708.

更重要的是，响应联盟实体(如，联盟实体820)的分布式数据处理系统中的一组数据处理系统(如，数据处理系统824-828)中的每个数据处理系统(如，数据处理系统824)可被配置为包括可相对于给定的请求联盟实体灵活或动态分配的身份提供商的功能性。换言之，响应联盟实体的分布式计算环境中的一组数据处理系统中的每个数据处理系统包括充当身份提供商的能力，而给定的请求联盟实体暂时(temporally)被分配给分布式计算环境中的一组数据处理系统中的特定数据处理系统。请求联盟实体和选择为其身份提供商的数据处理系统的关联或分配最好是暂时可配置的；所述关联或分配在可配置的时段后失效。因此，特定请求联盟实体和分配的数据处理系统间的关联最好不是永久的。此外，最好没有响应联盟实体的数据处理系统到特定的请求联盟实体的预定分配；例如，在响应联盟实体处收到来自请求联盟实体的资源请求之前没有预定的分配，并且在可配置的时间过期后没有预定的分配。这样，在响应、分布式、联盟实体中的身份提供商功能性分配的动态特征可被看作在响应联盟实体的分布式计算环境中的一组数据处理系统中的数据处理系统间浮动。换言之，认为在联盟实体的分布式计算环境中的数据处理系统中的身份提供商功能性的灵活分配“浮动”。

参见图8A，数据处理系统824、826和828分别包含浮动的身份提供商功能组件850、852和854。浮动的身份提供商功能组件包括充当身份提供商的能力，同时还包括允许上述浮动或动态分配特征的能力。换言之，数据处理系统824、826和828包括硬件和/或软件，按照可灵活分配给定数据处理系统的身份提供商功能性的方式支持身份提供商的功能性，以便根据本发明按动态方式执行由请求联盟实体请求的操作，如下详述。

图8B-8E示出了发生某些动作、以致可使用本发明来支持身份提供商功能性的浮动分配的更详细示例。应当注意，尽管本发明适用于各种联盟协议以及各种联盟操作的一般化联盟操作，一些示例性联盟操作用于示例浮动的身份提供商功能性；更具体地说，以下更详细地说明一个例子，其中由联盟一次性登录操作代表特定的联盟操作。

参见图8B-8E，这是框图，例示了其中第一联盟实体与第二联盟实体交互的情形，所述第二联盟实体使用分布式数据处理系统实施以支持浮动的身份提供商。图8B-8E与图8A的联盟实体820类似的方式描述了联盟实体的一些组件，从而相同的附图标记表示相同的组件。

参见图8B，联盟实体810向联盟实体820发送资源请求。在图8B所示的时间点上，联盟实体820尚未确定向联盟实体820中的哪个数据处理系统发送到来的资源请求以满足该请求，即，以响应该请求。此外，联盟实体820尚未确定对资源请求的响应是否要求完成任何与联盟相关的操作；因此，联盟实体820中没有数据处理系统被选择来相对于联盟实体810提供身份提供商的功能性。

在某个时间点上，检查资源请求，并随后将其发送或转发到构成联盟实体820的分布式数据处理系统的其中一个数据处理系统。参见图8C，联盟实体820已经将到来的资源请求内部路由到数据处理系统828，可能根据配置的策略、计算要求或其他原因。例如，负载均衡器可能根据负载均衡算法的当前状态将到来的请求定向到数据处理系统828。替代地，可能确定到来的请求要求使用可能仅在数据处理系统828中可用而不在数据处理系统824或826中可用的受保护资源。无论如何，在图8C所示的时间点，数据处理系统828可能已经也可能尚未确定对资源请求的响应是否要求完成任何与联盟相关的操作或者是否要求身份提供商的服务。

不过，在某个时间点上，数据处理系统828确定对资源请求的响应要求完成至少一个与联盟相关的操作或者要求身份提供商的服务，即，要求身份提供商功能组件的服务。此外，数据处理系统828确定具有其身份提供商功能性的数据处理系统还未分配给联盟实体810。

给定每个数据处理系统824-828包含执行身份提供商的与联盟相关的操作的功能性，并且给定数据处理系统828已经在处理要求身份提供商的服务的请求，数据处理系统828分配或以其他方式确立其自身为身份提供商，用于相对于联盟实体810满足身份提供商的服务的任何需要，包括当前正被处理的请求和在可配置的时间段中的任何后续请求。参见图8D，数据处理系统828已将其自身确立为充当相对于请求联盟实体810使用的身份提供商。这种针对联盟实体810的身份提供商的自分配对于在最好是可配置的时段中从联盟实体810接收的任何后续请求均有效。根据联盟实体820的各种策略或者根据操作联盟实体820的组织的各种企业目标，分配的时间有效性可随着本发明的不同实施而改变。

参见图8E，联盟实体810已向联盟实体820发送了另一个资源请求。联盟实体820已将到来的资源请求内部路由到数据处理系统828，同样可能是根据计算要求，例如因为到来的请求要求使用仅在数据处理系统824中可用而不在数据处理系统826或828中可用的受保护资源。不同于如图8D那样处理到来的请求，在图8E所示的时间点上，图8E示出数据处理系统824可确定数据处理系统828已经被选择、分配或以其他方式确立为用于相对于处理来自联盟实体810的请求提供身份提供商的服务的数据处理系统。在随后的某个时间点上，数据处理系统824可根据需要使用数据处理系统828及其浮动身份提供商功能性852，以便针对来自联盟实体810的当前到来资源请求获得身份提供商的服务。数据处理系统824从数据处理系统828请求身份提供商操作的方式可以不同；例如，数据处理系统824可以向数据处理系统828发送请求消息，但是取决于协议，这些消息可能需要通过请求联盟实体重定向，如下面参照其他附图描述的。

现在参见图9A-9C，一对流程图描述了在根据本发明的实施方式支持浮动身份提供商的分配的联盟实体中处理资源请求的过程。所示的过程表示可执行以完成参照图8B-8E描述的示例的计算步骤。

参见图9A，在响应联盟实体从请求联盟实体接收到资源请求(步骤902)。响应联盟实体将请求路由到响应联盟实体的分布式计算环境中的一组数据处理系统中的其中一个数据中心/数据处理系统(步骤904)。当前的数据中心，即接收并处理到来请求的数据处理系统，确定响应联盟实体的分布式计算环境中的其中一个数据处理系统是否已被分配来相对于请求联盟实体提供身份提供商的服务(步骤906)。如果数据处理系统尚未被分配来相对于请求联盟实体充当身份提供商，则数据中心确立其自身为被分配来相对于请求联盟实体提供身份提供商的服务的数据处理系统(步骤908)。如果在步骤906确定先前已经分配了数据中心，则过程分支，因为不需要在步骤908进行分配。

然后，进一步处理来自请求联盟实体的到来请求，以便生成响应；在请求被处理时，给定的请求联盟实体的先前分配的数据中心被用于其身份提供商功能性(如有必要)(步骤910)。在处理了到来请求后，生成响应，并且响应联盟实体将响应消息返回到请求联盟实体(步骤912)，由此结束该过程。

参见图9B，在图9B中所示的过程类似于图9A中所示的过程。在图9A中，流程图描述了其中响应联盟实体中的数据处理系统通常在步骤906确定数据处理系统的分配或者通常在步骤908将其本身确立为分配的数据处理系统的过程。相比之下，图9B描述了更为具体的过程，其中使用cookie机制来确定分配或确立分配。换言之，图9B示出了本发明的一个特定实施，其使用cookie来指示相对于请求联盟实体充当身份提供商的数据中心的先前分配。

在响应联盟实体从请求联盟实体接收资源请求(步骤922)。响应联盟实体将请求路由到响应联盟实体的分布式计算环境中的一组数据处理系统中的其中一个数据中心/数据处理系统(步骤924)。当前的数据中心，即当前处理接收的资源请求的数据中心，确定接收的资源请求是否与WAYF(Where Are You From)cookie一同接收或以其他方式伴随有此cookie(步骤926)。换言之，在图9B所示的本发明的实施方式中，WAYF cookie的存在等同于存在相对于请求实体充当身份提供商的数据中心的分配。因此，当前数据中心通过确定到来的请求是否伴有或以其他方式关联有可被称为WAYF(WhereAre You From)cookie的有效的特定类型cookie，来确定其作为成员的分布式数据处理系统(如图8A所示的数据处理系统824)中的数据中心先前是否被分配为相对于请求联盟实体充当身份提供商。如果是，则不创建或设置另一个WAYF cookie。但是，如果未获得或接收WAYF cookie，或者如果获得或接收的WAYF cookie由于某种原因无效，则创建或设置WAYF cookie(步骤928)。如此处理WAYFcookie，以致其用于后续的资源请求并且也与当前正处理的资源请求相关联，例如，从而其被设置并且在当前正满足的资源请求的处理中可用。

在本发明的一个实施方式中，WAYF cookie可被看作DDPS-IDcookie，即分布式数据处理系统(DDPS)标识符(ID)cookie。WAYFcookie的内容识别或者以其他方式指出特定的数据处理系统或数据中心(即在具有一组数据处理系统的分布式数据处理系统中)，其已在处理资源请求期间将其自身确立为随后相对于请求联盟实体提供身份提供商服务的自分配的数据中心。WAYF cookie由请求联盟实体与对当前资源请求的响应一同返回或响应于后续的资源请求返回；于是，WAYF cookie会被适当的客户机应用高速缓存以伴随后续的资源请求消息到达响应联盟实体。由于WAYF cookie是由响应联盟实体(即在分布式数据处理系统中)中的将其自身分配为充当请求联盟实体的身份提供商的数据中心/数据处理系统创建或设置的，WAYFcookie可被看作从其被发出的地方划界，由此指出应当用于在WAYFcookie的有效时段中的身份提供商操作的数据中心/数据处理系统。

随后，当前数据中心继续处理接收的资源请求(步骤930)。步骤930-934可被看作处理循环。在资源请求被处理的同时的某个时间点或多个时间点上，进行有关是否需要身份提供商的服务的一个或多个确定(步骤932)，即是否需要身份提供商执行操作，并且过程相应进行分支。如果不需要身份操作或者在已经执行身份操作之后，检查是否应针对当前资源请求执行更多处理(步骤934)；如果是，则处理分支回到步骤930。在某个时间点上，资源请求的处理会完成，并且当前数据中心会将响应消息发送到请求联盟实体(步骤936)，由此结束图9B的过程。

参见图9C，如果在图9B的步骤932中确定需要身份提供商的服务，则当前数据中心使用与当前资源请求一同接收、获得或关联的WAYF cookie；当前数据中心提取生成WAYF cookie的数据中心/数据处理系统的指示或标识符(步骤942)，即，将其自身分配为相对于联盟实体提供身份提供商的功能性的数据中心。当前数据中心于是将请求发送到分配的数据中心(步骤944)；会根据需要由给定的联盟协议格式化请求消息，以便请求由身份提供商执行特定的功能。在某个时间点，将由当前数据中心从分配的数据中心接收身份提供商功能的响应(步骤946)，并且该执行的功能的结果将帮助满足当前资源请求的处理，这可能在步骤936要求额外的处理，这同样可能要求充当身份提供商的数据中心的进一步帮助。不过，在某个时间点，资源请求的处理会结束，并且当前数据中心会将响应消息发送到请求联盟实体，由此结束该过程。

参见图10A-10D，是一组文本串，例示了可嵌入在cookie中以支持浮动身份提供商的分配的某些信息。应当注意，在cookie中也可以存在在实施本发明的系统中采用的其他文本串或子串，如″name＝″(如诸如HTTP的通信协议要求的。例如，将包括已生成cookie的联盟实体的域名，由此告知客户机应用在将资源请求发送到域时哪个域应当接收cookie。

参见图10A，初始文本串是cookie标识符1002，此文本串指示cookie是WAYF cookie，并且其可被用作cookie的名称。第二文本串是身份提供商(IdP)标识符1004；此文本串指示特定的联盟实体(如图8A所示的联盟实体820)正在以某种方式充当伴有WAYF cookie的请求的身份提供商，由此辨别该联盟实体820，而不是联盟中许多其他可能的身份提供商，已生成WAYF cookie。

Cookie ID 1002和身份提供商ID 1004可能允许与在现有解决方案中使用WAYF cookie的其他系统的互操作。但是，本发明提供了嵌入在WAYF cookie中以使得系统能够根据本发明支持WAYFcookie的新颖处理。更具体地说，第三文本串是数据处理系统ID 1006或数据中心ID 1006；此文本串指示在一组数据中心中将其自身分配为相对于请求联盟实体充当身份提供商的数据中心，如上所述。应当理解，文本串的格式化、文本串的顺序以及其他信息可根据本发明的实施而不同。

尽管图9B所示的过程示例了其中可将WAYF cookie的存在解释为等同于将数据中心分配为身份提供商的存在，一个替代的实施方式可允许使用WAYF cookie而不将数据中心分配为身份提供商。换言之，可使用WAYF cookie来维护响应联盟实体(其作为相对于请求联盟实体充当身份提供商的联盟实体)的标识，但是响应联盟实体中的分布式计算环境中没有特定的数据中心被分配来执行身份提供商功能性。参见图10B，可由图10B所示的WAYF cookie的内容来支持此情形，其中文本串1008包含已被设置为“NULL”或空值的其他表示的数据中心ID值。可发生以及使用此操作的方式将参照图11A-11B进行描述。

以与其它类型的cookie的过期值类似的方式，WAYF cookie最好具有过期时戳或指示WAYF cookie的临时有效性时段的类似数据，例如有限数量的小时。参见图10C，文本串1010指示WAYF cookie的过期时间，例如作为表示时间值的十六进制值。

如上参照图10B，可以有本发明的实施，其中使用WAYF cookie、但是响应联盟实体的分布式计算环境中没有特定的数据中心被分配来执行身份提供商功能性是有用的。此外，在本发明的一个实施方式中，可以对将数据中心分配为身份提供商设置时限；在这个时限过期后，数据中心的分配无效。为了实现此功能性，WAYF cookie可被配置为通过特别为该目的包含过期时间值来支持数据中心分配的过期。参见图10D，文本串1012支持数据中心分配的过期时间，例如作为表示时间值的十六进制值。这样，DPS分配过期值1012相对于WAYFcookie中的与数据中心分配相关的任何信息指示WAYF cookie的内容的过期，例如数据中心的标识符以及可存储在WAYF cookie中的任何其他相关信息。如果数据中心接收到资源请求以及其中DPS分配过期值1012指示DPS分配已过期的WAYF cookie，则接收数据可将其自身分配为用于执行身份提供商功能性的数据中心；此数据中心可随后修改WAYF cookie以包括其标识符，从而WAYF cookie指示该数据中心现在是分配的数据中心。

参见图11A-11B，这是一对流程图，例示了用于重置浮动身份提供商的分配的过程。参见图11A，示出了与如图9A或图9B所示的过程类似开始的过程。在响应联盟实体从请求联盟实体接收资源请求(步骤1102)。响应联盟实体将请求路由到响应联盟实体的分布式计算环境中一组数据处理系统中的其中一个数据中心/数据处理系统(步骤1104)，其随后处理该请求(步骤1106)。

在处理此请求时，确定相对于第一联盟实体的会话是否终止，或者类似的，是否相对于第一联盟实体执行了登出操作(步骤1108)；这可包括在被分配为相对于请求联盟实体充当身份提供商的数据中心处的处理。如果与请求联盟实体的会话以某种方式结束，例如请求联盟实体正登出，则修改WAYF cookie中的信息以反映不再需要分配的数据中心。换言之，该过程支持替代的实施方式，如上参照图10B所述，其中可允许使用WAYF cookie而不将数据中心分配为身份提供商；可继续使用WAYF cookie来维护响应联盟实体(其作为相对于请求联盟实体充当身份提供商的联盟实体)的标识，但是响应联盟实体中的分布式计算环境中没有特定的数据中心被分配来执行身份提供商功能性。因此，修改WAYF cookie来清除或设置分配的数据中心的身份(步骤1110)，从而WAYF cookie不包含分配的数据中心的标识符或指示符。在某点上，最终将响应消息以及WAYF cookie返回到请求联盟实体(步骤1112)，由此结束该过程。

图11A所示的过程重置将数据中心分配为身份提供商。相比之下，图11B示出使用WAYF cookie的过程或子过程，其中已经重置了充当身份提供商的数据中心的标识符。使用如图11B所示的过程，同时通过响应联盟实体来满足资源请求，如图9B所示。换言之，如图11B所示的过程可集成在如图9B所示的过程中，如图中的流程图连接元素所示。因此，与图9C所示的过程相比，如图11B所示的过程可被看作本发明的替代实施方式。

参见图11B，该过程通过获得WAYF cookie并检查它开始(步骤1122)，例如与在步骤930中处理资源请求同时和在步骤932中确定需要身份提供商的服务之后。确定WAYF cookie是否指示响应联盟实体，而不是联盟中的某个其他联盟实体，正在相对于请求联盟实体充当身份提供商(步骤1124)。如果是，则确定是否有特定的数据中心被分配来相对于请求联盟实体充当身份提供商(步骤1126)。如果WAYF cookie不包含特定数据中心的分配，则当前数据中心将WAYF cookie设置为指示当前数据中心将其本身分配为相对于请求联盟实体充当身份提供商(步骤1128)。例如，可能已经重置了数据中心分配，如相对于图11A所示的过程所述。在后续的某个时间点，例如，在处理后续接收的资源请求时，数据中心可分配其本身作为身份提供商(步骤1128)。当前数据中心于是执行必要的身份提供商操作和生成响应(步骤1130)以用于继续处理资源请求。

如果WAYF cookie包含数据中心的分配，则分配的数据中心的身份从WAYF cookie中提取(步骤1132)，并且对于必要的身份提供商操作的请求被发送到识别的数据中心(步骤1134)。

如果在步骤1124确定WAYF cookie指示联盟中的某个其他联盟实体正在相对于请求联盟实体充当身份提供商，则对于必要身份提供商操作的请求被发送到识别的身份提供商(步骤1136)。

如论如何，从无论哪个源获得对于必要身份提供商操作的结果或响应(步骤1138)，以便如有必要继续处理当前的资源请求，如图9B所示。

现在参见图12，这是数据流图示，例示了根据本发明可在联盟客户机或用户与支持浮动身份提供商的联盟实体之间传送的某些数据业务量。图12示出了这样的情形，其中联盟客户机或用户尝试访问联盟实体“A”中的受保护资源，所述联盟实体“A”被实施为包括各支持浮动身份提供商的多个数据中心或数据处理系统的分布式数据处理系统。在图12所示的情形中，联盟客户机或用户初始尝试访问数据中心“DPS-X”处的受保护资源，随后尝试访问数据中心“DPS-Y”处的受保护资源。

应当注意，在数据中心“DPS-X”和数据中心“DPS-Y”处显示的元件只用于示例相对于浮动身份提供商分配的数据业务量流；可以使用其他未示出的组件。例如，当联系点服务器支持认证操作时，联系点服务器可采用认证服务器的服务，如参照图3所述，或者FULM(联盟用户生命周期管理)组件可使用SPS(一次性登录协议服务)组件。作为另一个例子，web应用服务器可用作到后端应用(如图12所示的“DPS-X APP”和“DPS-Y APP”)的接口；web应用服务器可与联盟接口单元/过滤器和/或FULM组件交互。图12的数据流在联盟客户机或用户发送对联盟实体“A”中的受保护资源的请求时开始(步骤1202)。在某个时间点，请求被路由到数据中心“DPS-X”，例如通过负载均衡器，并在数据中心“DPS-X”的联系点服务器处接收。

由于客户机正在请求受保护资源，联系点服务器需要核实客户机/用户是否存在有效的安全性凭证。如果客户机/用户已经与数据中心“DPS-X”建立了会话，那么客户机/用户可能已经经历了生成安全性凭证的认证操作；如果是，则联系点服务器可允许将对受保护资源的请求发送到适当的资源。但是，如果客户机/用户尚未经历认证操作，或者客户机/用户的安全性凭证已经过期，则联系点服务器确定需要认证操作。联系点服务器例如以HTTP重定向消息(具有状态/原因代码“302”的HTTP响应消息)的形式，将客户机应用(例如，浏览器)重定向到FULM组件(步骤1204)。

重定向消息将客户机重定向到适当的位置，例如由重定向消息的“位置”头标中的URI所识别的，其识别控制联盟认证操作的联盟实体中的适当服务。响应于从客户机接收重定向消息，客户机将HTTP Get消息发送到适当的服务(如在来自联盟实体的HTTP重定向消息中的URI所指示的)(步骤1206)。

当FULM组件接收到请求时，其确定已将客户机重定向到请求特定的登录资源。FULM组件确定请求没有相关联的WAYF cookie，例如通过确定请求不伴有WAYF cookie，或者更具体地说，通过检测HTTP Get请求消息不包括含有WAYF cookie的头标。作为响应，FULM组件创建WAYF cookie(步骤1208)，其含有已由数据中心“DPS-X”创建WAYF cookie的指示，由此将其自身分配为相对于客户机针对后续的资源请求充当身份提供商(在处理后续的资源请求过程中，需要身份提供商的功能性来满足那些请求并对那些请求产生响应时)。假定数据中心“DPS-X”的分配相对于客户机是临时的，以如下方式创建WAYF cookie，即：包括限制将数据中心“DPS-X”分配给客户机作为其身份提供商的过期时戳。FULM组件于是将客户机重定向(步骤1210)到特定的登录资源，例如通过HTTP重定向消息。该登录资源的请求将继续登录操作。

客户机应用接收重定向消息，并且当在消息中检测到WAYFcookie时，例如在HTTP消息的“Set”头标中，则客户机应用在客户机设置或高速缓存WAYF cookie(步骤1212)。随后，客户机通过将对登录资源的请求发送到联盟实体来继续重定向操作(步骤1214)，这在图12所示的例子中是特定的登录web页面。

在图12所示的情形中，联系点服务器接收对登录资源的请求并处理该请求，可能在认证服务器的帮助下。在联盟实体和客户机/用户间执行认证操作(步骤1216)，由此生成安全性凭证或以其他方式准备允许客户机/用户访问受保护资源的客户机会话。联系点服务器于是将客户机重定向到原始请求的资源(步骤1218)。在示例的情形中，受保护资源是由在数据中心“DPS-X”支持的后端应用提供的资源。客户机接收重定向消息，并将请求发送到后端应用(步骤1220)。客户机/用户可随后参与使用受保护资源的各种事务。

在某个后续时间点，客户机通过发送对受保护资源的请求，尝试访问联盟实体的另一个受保护资源(步骤1222)。在示例情形中，受保护资源是由在数据中心“DPS-Y”支持的后端应用提供的资源。

由于客户机正在请求受保护资源，数据中心“DPS-Y”处的联系点服务器需要核实客户机/用户存在有效的安全性凭证。如果客户机/用户已经与数据中心“DPS-Y”建立了安全性凭证，则联系点服务器可允许将对受保护资源的请求发送到适当的资源。但是，如果联系点服务器不具有用户的安全性凭证或者凭证已经过期，则联系点服务器确定需要认证操作。联系点服务器例如以HTTP重定向消息的形式，将客户机应用(例如，浏览器)重定向到FULM组件(步骤1224)。响应于从客户机接收重定向消息，客户机发送HTTP Get消息到适当的服务(如由来自联盟实体的HTTP重定向消息中的URI所示)(步骤1226)。

当FULM组件接收请求时，其确定客户机已被重定向到请求特定的登录资源。FULM组件确定请求具有关联的WAYF cookie，例如通过确定请求伴有WAYF cookie，或者更具体地说，通过检测HTTPGet请求消息包括含有WAYF cookie的头部。此外，数据中心“DPS-Y”处的FULM组件确定WAYF cookie不是由其本身设置的，而是由数据中心“DPS-X”设置的(步骤1228)。给定有效的WAYF cookie，数据中心“DPS-X”已被分配为充当客户机的身份提供商。假定WAYFcookie是有效的且未过期，则数据中心“DPS-X”能够在其作为客户机的身份提供商的角色中与其他数据中心(如数据中心“DPS-Y”)交互，以根据需要为客户机执行联盟一次性登录操作或者其他联盟操作。因此，数据中心“DPS-Y”与数据中心“DPS-X”交互以执行一次性登录操作。

在数据中心“DPS-Y”处的FULM组件已经通过SSO操作确认了客户机的某种类型的安全性凭证后，FULM组件确定允许客户机访问客户机先前请求的受保护资源。FULM组件将重定向消息发送到客户机(步骤1232)。在示例性情况中，受保护资源是由在数据中心“DPS-Y”支持的后端应用提供的资源。客户机接收重定向消息并将请求发送到后端应用(步骤1234)。随后，客户机/用户可参与使用受保护资源的各种事务。

图12所示的情况描述了具有两个数据中心的联盟实体。但是，联盟实体的分布式计算环境可包括多个数据中心。本发明提供跨多个数据中心的身份提供商功能性的有效分布式提供。

在某个后续时间点时，客户机/用户的安全性凭证将随着WAYFcookie的有效性过期。如果客户机/用户稍后发送了对数据中心“DPS-Y”的受保护资源的另一个请求，则数据中心“DPS-Y”将接收先前设置的WAYF cookie以及客户机应用包括的到来的请求消息。但是，数据中心“DPS-Y”将检测WAYF cookie已过期并且是无效的。数据中心“DPS-Y”将确定将数据中心“DPS-X”分配为客户机的身份提供商也不再有效。因此，数据中心“DPS-Y”会将其本身分配为相对于客户机充当身份提供商，并且数据中心“DPS-Y”将为此生成并设置新的有效WAYF cookie，由此实质上覆盖旧的无效的WAYF cookie。

继续此后续情况，如果客户机/用户随后发送了请求来访问数据中心“DPS-X”处的受保护资源，则数据中心“DPS-X”将接收新有效的WAYF cookie以及该请求。数据中心“DPS-X”将检测WAYF cookie指示数据中心“DPS-Y”正相对于客户机充当身份提供商，并且数据中心“DPS-X”将遵从数据中心“DPS-Y”以执行相对于客户机的任何必要的身份提供商操作，如在数据中心“DPS-X”和数据中心“DPS-Y”间的另一个一次性登录操作，虽然两个数据中心具有相对于图12描述的情形的相反的角色。

结论

参照如上的本发明的详细描述，本发明的优点应当是明显的。本发明支持实施联盟实体作为分布式数据处理系统。分布式数据处理系统包括多个数据处理系统，每个均能够提供身份提供商的功能性，特别是以其中浮动身份提供商模型可用于支持跨分布式处理系统的身份提供商功能性的浮动分配的方式。

本发明是有利的，因为它支持分布式数据中心环境，这是可能支持数百万客户但又不能实施特定的现有数据管理技术的大型企业所要求的。此外，本发明不要求由分布式高速缓存所要求的先进数据管理技术。此外，使用本发明，请求联盟实体(如，服务提供商)无需知晓提供响应联盟实体(如，身份提供商)的功能性的多个数据中心的分布式本质或者存在。

重要的是注意，尽管在全功能数据处理系统的环境中描述了本发明，本领域技术人员能够理解，本发明的过程能够分布成计算机可读介质中的指令的形式以及各种其他形式，而无论实际用于执行分布的信号承载介质的特定类型。计算机可读介质的例子包括如EPROM、ROM、磁带、纸张、软盘、硬盘驱动器、RAM和CD-ROM以及传输类型介质，如数字和模拟通信链路。

方法被认为是导致期望结果的有条理的步骤序列。这些步骤需要物理量的物理处理。通常，但不一定必须，这些量采取能够被存储、传送、组合、比较或以其他方式处理的电或磁信号的形式。有时，特别是用于共同使用原因时，将这些信号称为比特、值、参数、项目、元素、对象、符号、字符、项、编号等是方便的。但是，应当注意，所有这些项或类似项将与适当的物理量相关联并且仅是应用于这些量的便利标记。

本发明的描述旨在示例本发明，而不理解为对所公开实施方式的穷举或限制。本领域技术人员能够想到许多修改和变形。实施方式被选择来解释本发明的原理及其实际应用和使本领域技术人员能够理解本发明，以便能够以在其他想到的使用中适用的各种修改来实施各种实施例。

Claims (12)

1.一种在联盟计算环境中处理事务的方法，该计算机实施的方法包括：

在第一联盟实体从第二联盟实体接收资源请求，其中第一联盟实体根据第一联盟实体和第二联盟实体间的信任关系响应对于第二联盟实体的联盟协议操作，其中第一联盟实体的服务由分布式数据处理系统中的一组数据处理系统提供，并且其中该组数据处理系统中的每个数据处理系统能够充当身份提供商；

通过该组数据处理系统中的第一数据处理系统的自分配过程，确立该第一数据处理系统来跨该组数据处理系统相对于第二联盟实体充当身份提供商；

跨该组数据处理系统，采用第一数据处理系统作为身份提供商来执行联盟协议操作，同时处理来自第二联盟实体的请求；

设置cookie，以确立第一数据处理系统对于该组数据处理系统相对于第二联盟实体充当身份提供商，其中cookie包括指示第一数据处理系统的身份的数据；以及

修改cookie，以除去指示第一数据处理系统的身份的数据，从而cookie指示第一联盟实体正充当身份提供商，而没有分配特定的数据处理系统来跨该组数据处理系统相对于第二联盟实体充当身份提供商。

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

确立该组数据处理系统中的第二数据处理系统在可配置的时段过期后，对于该组数据处理系统相对于第二联盟实体充当身份提供商；以及

对于来自第二联盟实体的请求，采用第二数据处理系统作为身份提供商来执行联盟协议操作。

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

在第二数据处理系统从第二联盟实体接收资源请求，其中资源请求伴有cookie；

从cookie提取指示第一数据处理系统的身份的数据；以及

在第二数据处理系统和第一数据处理系统间执行第二联盟实体的一次性登录操作。

4.根据权利要求1所述的方法，还包括：

生成cookie以包括过期值，从而第一数据处理系统被确立为在由过期值控制的有效时段中的身份提供商。

5.根据权利要求4所述的方法，还包括：

在第二数据处理系统从第二联盟实体接收资源请求，其中资源请求伴有cookie；

从cookie提取过期值；

修改cookie，以响应于确定过期值的时段已经过去，确立第二数据处理系统对于该组数据处理系统相对于第二联盟实体充当身份提供商，其中修改的cookie包括指示第二数据处理系统的身份的数据；以及

重置过期值。

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

在第二数据处理系统从第二联盟实体接收资源请求，其中资源请求伴有cookie；

确定cookie不指示分配特定的数据处理系统来跨该组数据处理系统相对于第二联盟实体充当身份提供商；以及

修改cookie，以指示分配第二数据处理系统来跨该组数据处理系统相对于第二联盟实体充当身份提供商。

7.一种在联盟计算环境中处理事务的设备，该设备包括：

在第一联盟实体从第二联盟实体接收资源请求的装置，其中第一联盟实体根据第一联盟实体和第二联盟实体间的信任关系响应对于第二联盟实体的联盟协议操作，其中第一联盟实体的服务由分布式数据处理系统中的一组数据处理系统提供，并且其中该组数据处理系统中的每个数据处理系统能够充当身份提供商；

通过该组数据处理系统中的第一数据处理系统的自分配过程，确立该第一数据处理系统来跨该组数据处理系统相对于第二联盟实体充当身份提供商的装置；

跨该组数据处理系统，采用第一数据处理系统作为身份提供商来执行联盟协议操作，同时处理来自第二联盟实体的请求的装置；

设置cookie，以确立第一数据处理系统对于该组数据处理系统相对于第二联盟实体充当身份提供商的装置，其中cookie包括指示第一数据处理系统的身份的数据；以及

修改cookie，以除去指示第一数据处理系统的身份的数据，从而cookie指示第一联盟实体正充当身份提供商，而没有分配特定的数据处理系统来跨该组数据处理系统相对于第二联盟实体充当身份提供商的装置。

8.根据权利要求7所述的设备，还包括：

确立该组数据处理系统中的第二数据处理系统在可配置的时段过期后，对于该组数据处理系统相对于第二联盟实体充当身份提供商的装置；以及

对于来自第二联盟实体的请求，采用第二数据处理系统作为身份提供商来执行联盟协议操作的装置。

9.根据权利要求7所述的设备，还包括：

在第二数据处理系统从第二联盟实体接收资源请求的装置，其中资源请求伴有cookie；

从cookie提取指示第一数据处理系统的身份的数据的装置；以及

在第二数据处理系统和第一数据处理系统间执行第二联盟实体的一次性登录操作的装置。

10.根据权利要求7所述的设备，还包括：

生成cookie以包括过期值，从而第一数据处理系统被确立为在由过期值控制的有效时段中的身份提供商的装置。

11.根据权利要求10所述的设备，还包括：

在第二数据处理系统从第二联盟实体接收资源请求的装置，其中资源请求伴有cookie；

从cookie提取过期值的装置；

修改cookie，以响应于确定过期值的时段已经过去，确立第二数据处理系统对于该组数据处理系统相对于第二联盟实体充当身份提供商的装置，其中修改的cookie包括指示第二数据处理系统的身份的数据；以及

重置过期值的装置。

12.根据权利要求7所述的设备，还包括：

在第二数据处理系统从第二联盟实体接收资源请求的装置，其中资源请求伴有cookie；

确定cookie不指示分配特定的数据处理系统来跨该组数据处理系统相对于第二联盟实体充当身份提供商的装置；以及

修改cookie，以指示分配第二数据处理系统来跨该组数据处理系统相对于第二联盟实体充当身份提供商的装置。

Images