CN100461667C - 与异类联合体环境中验证声明相关的拥有证明操作方法和设备 - Google Patents

Abstract

提供一种方法、设备、系统和计算机程序产品，其中联合域在联合体环境中交互作用。联合体内的域能够在其它联合域为用户启动联合单一注册操作。域内的联系点服务器依靠域内的信任代理管理域和联合体之间的信任关系。根据需要，信任代理解释来自其它联合域的声明。信任代理可与一个或多个信任中介具有信任关系，信任代理可依靠信任中介帮助解释声明。为了提高安全性，通过在用户启动单一注册操作之后执行的拥有证明质询，域还可要求用户重新证明他们的身份。

Description

与异类联合体环境中验证声明相关的拥有证明操作方法和设备

技术领域

本发明涉及一种改进的数据处理系统，特别涉及一种多计算机数据传送方法和设备。更具体地说，本发明以网络化计算机系统为目标。

背景技术

企业一般希望在各种网络，包括因特网内，以用户友好的方式向授权用户提供对受保护资源的安全访问。虽然提供安全的验证机制降低了未经许可访问受保护资源的风险，但是相同的验证机制会成为用户与受保护资源交互作用的障碍。用户通常需要从与一个应用程序交互作用跳跃到与另一应用程序交互作用的能力，而不考虑保护支持这些应用程序的各个特定系统的验证障碍。

随着用户变得更加成熟，他们希望计算机系统协调他们的操作，从而减轻用户的负担。这些期望也适用于验证过程。用户可假定一旦他或她已被某一计算机系统验证，那么该验证应在用户的整个工作会话中有效，或者至少在特定的一段时间内有效，而不考虑用户几乎不可见的各种计算机结构边界。企业通常试图在他们部署的系统的操作特征方面实现这些期望，不仅安抚用户，而且提高用户效率，不管用户效率是与雇员生产率相关还是与客户满意度相关。

更具体地，就当前的其中许多应用程序具有可通过公共浏览器访问的基于Web的用户界面的计算环境来说，用户期望更加用户友好，较少或者很少的障碍，以便从一个基于Web的应用程序转移到另一个Web应用程序。这种情况下，用户逐渐期望具有在不考虑保护各个特定域的验证障碍的情况下，从与一个因特网域的应用程序交互作用跳到与另一域的另一应用交互作用的能力。但是，即使许多系统通过易于使用的基于Web的接口，提供安全的验证，用户仍然不得不慎重处理妨碍用户跨越一组域访问的多个验证过程。在指定时间内使用户经历多个验证过程会显著影响用户的效率。

已使用各种技术来减轻对用户和计算机系统管理员的验证负担。这些技术一般被称为“单一注册”(SSO)过程，因为它们具有共同的目的：在用户完成一次注册操作，即被验证之后，随后不要求该用户执行另一验证操作。从而，目的是在特定的用户会话中，只要求用户完成一次验证过程。

当在指定企业内实现时，这种单一注册解决方案是成功的。但是，随着更多企业参与电子商务市场或者通过因特网连接的其它合作努力中，由多个验证过程或系统带来的障碍正在变得越来越常见。以前的企业之间的单一注册解决方案局限于其中在参与企业之间存在预先确定的商业协议的同类环境。这些商业协议部分被用于建立信任，以及限制和定义在企业之间，如何以安全的方式传送信息。这些商业协议还包括关于如何把用户身份从一个企业转换或映射到另一企业，以及如何在参与企业之间传送用于担保用户的信息的规则方面的技术协议。

换句话说，以前的单一注册解决方案允许根据预先达成或预先设定的协议，信任由不同企业产生的验证声明(以及在该声明中提供的用户的身份)。每个截然不同的企业知道如何产生和说明可被已交换类似协议的其它企业，例如电子商务市场内的企业理解的验证声明。这些同类环境紧密结合，因为存在企业已知的，用于在这些系统间映射用户身份的确定关系。由于用于建立单一注册环境的商业协议的缘故，这种紧密结合是可能的。虽然利用这些以前的单一注册解决方案，参与企业能够在同类环境中合作，但是考虑到需要或者期望互连多个同类环境，这些环境是限制性的，例如互连的电子商务市场。

虽然单一注册解决方案可向参与企业内的用户提供易于使用的优点，但是通过也适用于其它系统的技术，恶意用户会试图滥用这种环境内的资源。例如，通过所谓的中间人(man-in-the-middle)攻击，可截取单一注册信息。另外，被合法用户用于单一注册操作的客户计算机可在合法用户离开客户计算机之后，被恶意用户滥用。

于是，具有其中在缺少参与企业之间的预定商业和技术转换协议的情况下，企业可向用户提供单一注册经历的方法和系统应是有利的。特别有利的是减少来自试图滥用单一注册会话的恶意用户的安全风险。

发明内容

提供一种方法、设备、系统和计算机程序产品，其中联合域在联合体环境(federated environment)中交互作用。联合体内的域能够在其它联合域为用户启动联合单一注册操作。域内的联系点服务器依靠域内的信任代理(trust proxy)管理域和联合体之间的信任关系。根据需要，信任代理解释来自其它联合域的声明。信任代理可与一个或多个信任中介具有信任关系，信任代理可依靠信任中介帮助解释声明。为了提高安全性，通过在用户启动单一注册操作之后执行的拥有证明(proof-of-possession)质询，域还可要求用户重新证明他们的身份。

附图说明

附加权利要求中陈述了本发明特有的新特征。结合附图，参考下述详细说明，将更好地理解发明本身，其它目的及其优点：

图1A描述了数据处理系统的典型网络，每个所述数据处理系统可实现本发明；

图1B描述可在数据处理系统内使用的典型计算机结构，在所述数据处理系统中可实现本发明；

图1C是图解说明当客户机试图访问服务器的受保护资源时，可使用的典型验证过程的数据流程图；

图1D是图解说明其中可实现本发明的典型Web环境的网络图；

图1E是图解说明向用户要求多次验证操作的典型在线交易的方框图；

图2A是图解说明就用户相对于第一联合企业启动的交易来说，联合体环境的术语的方框图，作为响应，第一联合企业调用联合体环境内下游实体上的操作；

图2B是根据本发明的一个实施例，图解说明指定域的现有系统和本发明的一些联合体系统结构组件的综合的方框图；

图2C是根据本发明的一个实现，图解说明联合体系统结构的方框图；

图2D是根据本发明，图解说明利用信任代理和信任中介的联合域之间的一组例证信任关系的方框图；

图3A是图解说明位于发布域的，产生联合体环境内的声明的一般过程的流程图；

图3B是图解说明位于信赖域的，扯下(tearing down)声明的一般过程的流程图；

图3C是图解说明响应发布域的用户操作，把声明从发布域推送到信赖域的具体过程的流程图；

图3D是图解说明响应发布域主动截取对于信赖域的输出请求，把声明从发布域推送到信赖域的具体过程的流程图；

图3E是图解说明在试图满足信赖域从发出请求的用户接收的资源请求的同时，信赖域向发布域请求关于用户的任何所需声明的拖拉模式的流程图；

图4是图解说明支持联合单一注册操作的联合体环境的方框图；

图5是描述利用位于发布域和信赖域的信任代理之间的直接通信，发布方核实的拥有证明质询的调用流图；

图6是描述利用位于发布域和信赖域的信任代理之间的直接通信，信赖方核实的拥有证明质询的调用流图；

图7是描述发布方核实的拥有证明质询的调用流图，其间位于发布域和信赖域的信任代理通过信任中介通信；

图8是描述信赖方核实的拥有证明质询的调用流图，其间位于发布域和信赖域的信任代理通过信任中介通信。

具体实施方式

一般来说，可构成或与本发明相关的设备包括各种数据处理技术。于是，作为背景，在更详细地描述本发明之前，说明分布式数据处理系统内硬件和软件组件的典型组织。

现在参见附图，图1描述了数据处理系统的典型网络，每个数据处理系统可实现本发明。分布式数据处理系统100包含网络101，网络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，网络110包含无线通信链路。支持网络的电话机111通过无线链路112连接网络110，PDA113通过无线链路114连接网络110。电话机110和PDA113也可利用适当的技术，例如蓝牙TM无线技术，通过无线链路115在它们之间直接传送数据，产生所谓的个人区域网络或者个人ad-hoc网络。按照相同的方式，PDA 113可通过无线通信链路116向PDA 107传送数据。

还可在各种硬件平台和软件环境中实现本发明。图1A用作不同种类的计算环境的一个例子，而不是对本发明的结构限制。

现在参见图1B，图1B描述了如图1A中所示的其中可实现本发明的数据处理系统的典型计算机结构。数据处理系统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)、无线置标语言(WML)、以及各种其它格式和类型的文件的应用软件。还应注意到图1A中所示的分布式数据处理系统预期完全能够支持各种对等子网和对等服务。

现在参见图1C，数据流程图举例说明当客户机试图访问位于服务器的受保护资源时，可使用的典型验证过程。如图所示，位于客户机工作站150的用户试图通过在客户机工作站上执行的用户的Web浏览器，通过计算机网络访问位于服务器151上的受保护资源。受保护资源由只可被经验证和批准的用户访问的统一资源定位符(URL)，或者更一般地说，统一资源标识符(URI)识别。计算机网络可以是因特网、企业内部网或者其它网络，如图1A或图1B中所示，服务器可以是Web应用程序服务器(WAS)、服务器应用程序、Servlet进程等。

当用户请求受保护资源，例如域“ibm.com”内的Web页(步骤152)时，启动该进程。Web浏览器(或者相关应用程序或小程序)产生HTTP请求消息，所述HTTP请求消息被发送给驻留域“ibm.com”的Web服务器(步骤153)。服务器确定它不具有关于该客户机的现行会话(步骤154)，从而服务器通过向客户机发送某一类型的验证质询，要求用户执行验证进程(步骤155)。验证质询可以呈各种格式，例如超文本置标语言(HTML)形式。用户随后提供请求或要求的信息(步骤156)，例如用户标识符和相关口令，或者客户机可自动返回某些信息。

验证响应信息被发送给服务器(步骤157)，此时，服务器通过取回先前提交的注册信息，并匹配提供的验证信息和用户的保存信息，验证用户或客户机(步骤158)。假定验证成功，那么为经验证的用户或客户机建立现行会话。

服务器随后取回所请求的Web页，并向客户机发送HTTP响应消息(步骤159)。此时，通过点击超文本链接，用户可在浏览器内请求“ibm.com”内的另一页面(步骤160)，浏览器向服务器发送另一HTTP请求(步骤161)。此时，服务器认识到该用户已具有现行会话(步骤162)，服务器在另一HTTP响应消息中，把所请求的Web页送回客户机(步骤163)。虽然图1C描述了典型的现有进程，不过应注意可描述其它备选会话状态管理技术，例如使用cookie识别具有现行会话的用户，所述现行会话可包括使用和用于提供验证证据的cookie相同的cookie。

现在参见图1D，网络图举例说明了其中可实现本发明的典型Web环境。在该环境中，客户机171的浏览器170的用户想要访问DNS域173中web应用程序服务器172上，或者DNS域175中web应用程序服务器174上的受保护资源。

按照和图1C中所示相似的方式，用户可请求位于许多域之一的受保护资源。和只表示位于特定域的单一服务器的图1C相反，图1D中的每个域具有多个服务器。特别地，每个域可具有相关的验证服务器176和177。

本例中，在客户机171发出关于位于域173的受保护资源的请求时，web应用程序服务器172确定它不具有关于客户机171的现行会话，它请求验证服务器176执行关于客户机171的恰当验证操作。验证服务器176把验证操作的结果传送给web应用程序服务器172。如果用户(或者代表用户的浏览器170或客户机171)被成功验证，那么web应用程序服务器172建立关于客户机171的会话，并返回所请求的受保护资源。一般来说，一旦用户被验证服务器验证，那么可确定并在浏览器的cookie超高速缓存中保存一个cookie。图1D只是可在多个服务器之间共享一个域的处理资源，尤其是以便执行验证操作的一种方式的例子。

按照相似的方式，在客户机171发出关于域175的受保护资源的请求之后，验证服务器177执行关于客户机171的恰当验证操作，之后，web应用程序服务器174建立关于客户机171的会话，并返回所请求的受保护资源。从而，图1D图解说明客户机171可具有在不同域中的多个并存会话，但是为了建立这些并存会话，需要完成多个验证操作。

现在参见图1E，方框图描述了向用户要求多个验证操作的典型在线交易的例子。再次参见图1C和图1D，在获得对受控资源的访问之前，要求用户完成验证操作，如图1C中所示。虽然图1C中未示出，验证管理程序可部署在服务器151上，取回和使用验证用户所需的用户信息。如图1D中所示，用户可具有在不同域173和175内的多个当前会话，虽然图1D中未示出，代替验证服务器或者除了验证服务器之外，每个域可采用验证管理程序。按照类似的方式，图1E还描述了一组域，每个域可支持某一类型的验证管理程序。图1E图解说明了当访问要求完成关于每个域的验证操作的多个域时，用户可能遇到的一些问题。

用户190可向ISP域191注册，域191可支持验证用户，以便完成与域191的交易的验证管理程序192。ISP域191可以是提供因特网连接服务、电子邮件服务，可能还有其它电子商务服务的因特网服务提供者(ISP)。另一方面，ISP域191可以是用户190频繁访问的因特网入口。

类似地，域193、195和197代表典型的web服务提供者。政府域193支持验证用户，以便完成各种和政府相关的交易的验证管理程序194。银行业域195支持验证用户，以便完成与在线银行的交易的验证管理程序196。电子商务域197支持验证用户，以便完成在线购买的验证管理程序198。

如前所述，当用户试图通过访问位于不同域的资源，在因特网或万维网内从一个域转移到另一域时，用户会经历多个用户验证请求或要求，所述多个用户验证请求或要求会显著减缓用户越过一组域的进程。使用图1E作为例证的环境，用户190可卷入与电子商务域197的复杂在线交易中，其中用户试图购买局限于至少18岁，并且具有合法驾照、有效信用卡和美国银行账户的用户的在线服务。该在线交易可涉及域191、193、195和197。

一般来说，用户不会在参与特定在线交易的每个域内保持身份。本例中，用户190可能已向用户的ISP注册了他或她的身份，但是为了完成在线交易，还需要用户向域193、195和197验证。如果每个域不保持用户的身份，那么用户的在线交易会失败。即使用户可被每个域验证，也不能确保不同的域能够在它们之间传送信息，以便完成用户的交易。对于图1E中所示的用户190来说，不存在允许用户190向第一web站点，例如ISP191验证，随后向其它web服务提供者，例如域193、195和197传送验证权标，以便实现单一注册的现有环境。

在当前技术的在先简要描述下，剩余附图的描述涉及本发明可在其中工作的联合计算机环境。但是，在更详细论述本发明之前，先介绍一些术语。

术语

术语“实体”或“参与者”一般指的是代表组织、个人或者另一系统工作的组织、个人或系统。术语“域”暗示网络环境中的其它特性，但是术语“实体”、“参与者”和“域”可交替使用。例如，术语“域”可以指DNS(域名系统)域，或者更一般地，涉及包括表现为外部实体的逻辑单元的各种装置和应用程序的数据处理系统。

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

权标提供成功操作的直接证据，并由执行该操作的实体产生，例如在成功的验证操作之后，产生验证权标。Kerberos权标是可用在本发明中的验证权标的一个例子。在Kohl等的“The KerberosNetwork Authentication Service(V5)”(Internet EngineeringTask Force(IETF)Request for Comments(RFC)1510，09/1993)中可找到关于Kerberos的更多信息。

声明提供某一动作的间接证据。声明可提供身份、验证、属性、授权决定、或其它信息和/或操作的间接证据。验证声明提供不是验证服务方，但是听从验证服务方的实体的验证的间接证据。

安全声明置标语言(SAML)声明是可在本发明内使用的声明格式的一个例子。SAML由the Organization for the Advancement ofStructured Information Standards(OASIS)发布，该组织是非赢利性全球协会。在“Assertions and Protocol for the OASIS SecurityAssertion Markup Language(SAML)”，Committee Specification01，05/31/2002中如下描述SAML：

安全声明置标语言(SAML)是交换安全信息的XML结构。以关于主题的声明的形式表述安全信息，主题是在某一安全域中具有身份的实体(人或计算机)。主题的典型例子是由特定因特网DNS域中他或她的电子邮件地址识别的人。声明可传达和主题执行的验证行为、主题的属性、以及是否允许主题访问某些资源的验证判定相关的信息。声明可被表示成XML结构，并且具有嵌套结构，从而单个声明可包含关于验证、授权和属性的数个不同内部陈述。注意包含验证陈述的声明只描述先前发生的验证行为。声明由SAML管理机构，即验证管理机构、属性管理机构和策略判定点发布。SAML定义一种协议，借助该协议，客户机可向SAML管理机构请求声明，并从SAML管理机构获得响应。由XML请求和响应消息格式构成的这种协议可绑定在许多不同的底层通信和传送协议上；SAML目前对HTTP上的SOAP定义一种绑定。SAML管理机构可使用各种信息源，例如外部策略库和在请求中作为输入接收的声明来产生他们的响应。从而，虽然客户机始终消耗声明，但是SAM管理机构既是声明的生产者，又是声明的消费者。

SAML规范规定声明是提供发布者做出的一个或多个陈述的信息包。SAML允许发布者产生三种不同的声明陈述：验证，其中在特定时间借助特定手段验证指定主题；授权，其中批准或拒绝允许指定主题访问指定资源的请求；和属性，其中使指定主题和提供的属性相联系。如下进一步所述，当需要时，各种声明格式可被转换成其它声明格式。

验证是确认用户或代表用户提供的一组凭证的过程。通过核实用户知道的某事，用户具有的某物或者用户是某人，即关于用户的某些物理特征，完成验证。用户知道的某事可包括共享秘密，例如用户的口令，或者通过核实只有特定用户知道的某事，例如用户的加密密钥，完成用户知道的某事的核实。用户拥有的某物可包括智能卡或者硬件权标。关于用户的一些物理特征可包括生物统计输入，例如指纹或视网膜图。

验证凭证是在各种验证协议中使用的一组质询/响应信息。例如，用户姓名和口令组合是最常见形式的验证凭证。其它形式的验证凭证可包括各种形式的质询/响应信息，公共密钥基础结构(PKI)证书、智能卡、生物统计等。验证凭证不同于验证声明：验证凭证由用户借助验证服务器或服务，以验证协议序列的一部分的形式呈现，而验证声明是关于用户的验证凭证的成功提供和确认的陈述，当需要时，随后可在实体之间传送。

区别现有的单一注册解决方案

如上所述，现有的单一注册解决方案局限于其中在参与企业之间存在预定确定的商业协议的同类环境。这些商业协议建立信任，并定义在企业之间信息的安全传送。这些商业协议还包括关于如何把用户身份从一个企业转换或映射到另一企业，以及如何在参与企业之间传送用于担保用户的信息的规则方面的技术协议。

换句话说，以前的单一注册解决方案允许根据预先达成或预先设定的协议，信任由不同企业产生的验证声明(以及在该声明中提供的用户的身份)。每个截然不同的企业知道如何产生和说明可被已交换类似协议的其它企业，例如电子商务市场内的企业理解的验证声明。这些同类环境紧密结合，因为存在企业已知的，用于在这些系统间映射用户身份的确定关系。由于用于建立单一注册环境的商业协议的缘故，这种紧密结合是可能的。

本发明的联合体模型

在万维网的环境中，用户逐渐期望具有在极少考虑各个特定域之间的信息屏障的情况下，从与一个因特网域的应用程序交互作用跳到与另一域的另一应用交互作用的能力。用户不希望由于关于单一交易，不得不向多个域验证所带来的挫折。换句话说，用户期望组织应协作，但是用户通常希望域尊重他们的隐私。另外，用户宁愿限制永久保存私人信息的域。在快速发展的异类环境中，存在这些用户期望，在所述异类环境中，许多企业和组织正在发布竞争性验证技术。

和现有系统相反，本发明提供一种联合体模型，以便在特定企业之间缺少具体的、预先确定的商业和技术协议的情况下，允许企业向用户提供单一注册经历。换句话说，本发明支持联合异类环境。作为本发明目的的一个例子，再次参见图1E，用户190能够向域191验证，随后使域191向交易中涉及的每个下游域提供恰当的声明。这些下游域需要能够理解并信任验证声明和/或其它类型的声明，即使在域191和这些其它下游域之间不存在任何预先确定的声明格式。除了识别声明之外，下游域需要能够把包含在声明内的身份转换成代表特定域内的用户190的身份，即使不存在任何预先确定的身份映射关系。

本发明以联合体环境为目标。一般来说，企业具有它自己的用户注册处，并维持与它自己的一组用户的关系。每个企业一般具有自己的验证这些用户的手段。但是，本发明的联合体方案允许企业集体协作，从而通过企业在企业联合体中的参与，一个企业中的用户可影响与一组企业的关系。可准许用户访问位于任意联合体企业的资源，好象用户具有与每个企业的直接关系一样。不需要用户向关心的每个企业注册，并且不需要用户不断识别并验证他们自己。从而，在联合体环境中，验证方案为信息技术中，快速发展的异类环境内的单一注册体验创造条件。

本发明中，联合体是协作向用户提供单一注册、易于使用的体验的一组不同实体，例如企业、组织、协会等。本发明中，联合体环境不同于典型的单一注册环境，因为两个企业不必具有直接的、预先确定的定义如何传送及传送和用户有关的哪些信息的关系。在联合体环境中，实体提供服务，所述服务处理验证用户，接受其它实体提供的验证声明，例如验证权标，和提供某一形式的被担保用户身份向在本地实体内明白的用户身份的转换。

联合体减轻服务提供者的负担。服务提供者可依赖于它与联合体整体的信任关系；服务提供者不需要管理诸如用户口令信息之类的验证信息，因为它可依靠用户的验证主域完成的验证。

本发明还涉及一种联合身份管理系统，所述联合身份管理系统建立其中松散结合的验证、用户登记、用户简介管理和/或授权服务跨越安全域合作的基础。联合身份管理允许驻留在不同域中的服务安全地协作和合作，即使在这些不同域的底层安全机制和操作系统平台方面存在差异。一旦用户确定他们在联合体中的参与，那么就确定了单一注册体验。

主域、发布方和信赖方

如下更详细所述，本发明提供显著的用户好处。本发明允许用户在第一实体验证，下面把所述第一实体称为用户的主域或者验证主域。第一实体可充当发布方，发布供在第二实体使用的关于该用户的验证声明。在不必明确向第二实体验证的情况下，通过提供第一实体发布的验证声明，用户可访问位于不同的第二实体(称为信赖方)方的受保护资源。从发布方传送给信赖方的信息采取声明的形式，该声明可包含呈陈述形式的不同类型的信息。例如，声明可以是关于用户的经验证身份的陈述，或者可以是关于和特定用户相联系的用户属性信息的陈述。

现在参见图2A，方框图就用户相对于第一联合企业启动的交易，描述了联合体环境的术语，作为响应，第一联合企业调用位于联合体环境内下游实体上的操作。图2A表示对于指定的联合操作，术语会根据联合体内的实体的观点而不同。用户202通过关于企业204的受保护资源的请求，启动交易。如果用户202已被企业204验证，那么对于该联合会话来说，企业204是用户的主域。假定交易需要企业206的某一类操作，并且企业204向企业206传送声明，那么企业204是该特定操作的发布域，企业206是该操作的信赖域。假定交易需要其它操作，并且企业206向企业208传送声明，那么企业206是所请求操作的发布域，企业208是该操作的信赖域。

在本发明的联合体环境中，用户在该处进行验证的域被称为用户的(验证)主域。主域保持验证凭证。主域可以是用户的雇主，用户的ISP或者其它一些服务提供者。在联合体环境内可能存在可充分用户主域的多个企业，因为可能存在具有产生并确认用户的验证凭证的能力的多个企业。

从验证的观点来看，验证声明的发布方一般是用户的验证主域。用户的主域可以也可不保持用户的个人信息或简介信息。从而，从涉及个人可识别的信息、个性化信息或者其它用户属性的属性来看，属性声明的发布方可以是也可以不是用户的验证主域。为了避免任何混乱，不同的术语可被用于属性主域和验证主域，但是下面术语“主域”可被解释为指的是验证主域。

但是，在指定的联合会话的范围内，通常有且只有一个充当用户主域的域。一旦用户已向该域证实自己，那么在该会话的持续时间内，联合体中的所有其它域或企业被看作是信赖方。

假定本发明提供可在使对现有的非联合结构的影响降至最小的同时，增加到现有系统中的联合结构，由于主域也可参与到联合体环境中，因此不会改变在用户主域的验证。换句话说，即使主域被并入根据本发明实现的联合体环境中，在用户的主域执行验证操作时，用户也会具有相同的最终用户体验。不过应注意的是，不是指定企业的所有用户都必须参与该联合体环境。

此外，由于主域还可参与到联合体环境中，因此用户注册，例如用户账户的建立不会被改变。用户通过与联合体环境无关的注册过程，在某一域建立一个账户。换句话说，在主域的用户账户的建立不包括在联合体内有效的账户信息，例如身份转换信息的确定。如果存在能够验证用户的单一联合域，即联合体内有且只有一个用户已向其注册的域，那么该域将始终充当用户的主域，并且指导整个联合体环境内用户的移动。

如果在联合体环境内，用户具有多个可能的主域，那么用户可通过一个以上的入口点进入该联合体。换句话说，用户可在多个域具有账户，并且这些域不必具有关于其它域的信息，也不必具有和用户在其它域的身份有关的信息。

当用户在该处进行验证的域被称为主域时，发布域是发布供另一域，即信赖域使用的声明的联合体实体。发布域一般(不过不必要)是用户的主域。从而，情况通常是发布方已通过典型的验证协议验证了用户，如上所述。但是，发布方先前可能充当信赖方，从而它接收来自不同发布方的声明。换句话说，由于用户启动的交易可串联通过联合体环境内的一系列企业，因此接收方随后可充当下游交易的发布方。一般来说，具有代表用户发布验证声明的能力的任何域都可充当发布域。

信赖域是接收来自发布方的声明的域。信赖域能够接受、信任和理解代表用户的第三方，即发布域发布的声明。依赖方的任务一般是使用适当的验证机构解释验证声明。另外，信赖方有可能能够验证特定用户，即充当用户的主域，不过依赖方也可能不能借助常规方法验证特定用户。从而，信赖方是依靠用户提供的验证声明，向用户提供单一注册体验，而不是作为与用户的交互式会话的一部分，就用户的验证凭证提示用户的域或企业。

联合体系统结构—旧系统的联合前端

现在参见图2B，方框图描述了根据本发明的一个实施例，指定域的现有系统与本发明的一些联合体系统结构组件的结合。联合体环境包括向用户提供各种服务的联合实体。用户212与客户装置214交互作用，客户装置214可支持浏览器应用程序216和各种其它客户应用程序218。用户212与客户装置214、浏览器216或者充当用户和其它装置及服务之间的接口的任何其它软件截然不同。一些情况下，下述描述可区别在客户应用程序内动作的用户和正在代表用户动作的客户应用程序。不过，一般来说，请求者是可被假定为代表用户行动的中间人，例如客户应用程序、浏览器、SOPA客户机等。

浏览器应用程序216可以是包括许多模块，例如HTTP通信组件220和置标语言(ML)解释器的典型浏览器。浏览器应用程序还可支持可以需要也可不需要虚拟机运行时间环境的插件，例如web服务客户程序224，和/或可下载的支程序。web服务客户程序224可使用简单对象访问协议(SOAP)，它是定义分散的分布环境中结构化和类型化信息的交换的轻量协议。SOAP是一种基于XML的协议，由三部分组成：定义描述消息中的内容及如何处理所述内容的框架的包络；表述应用程序定义的数据类型的实例的一组编码规则；和代表远程程序调用和响应的协定。用户212可利用浏览器应用程序216访问基于web的服务，不过用户212也可通过客户装置214上的其它web服务客户应用程序访问web服务。下面的附图中表示的本发明的一些例子通过用户的浏览器，采用HTTP重定向在联合体环境中的实体间交换信息。但是，应注意的是也可通过各种通信协议执行本发明，本发明并不意味着局限于基于HTTP的通信。例如，当需要时，联合体环境中的实体可直接通信；消息不需要通过用户的浏览器被重定向。

可按照使联合体环境所需的组件和现有系统结合的方式实现本发明。图2B描述了把这些组件实现为现有系统的前端的一个实施例。联合域的现存组件可被看作是旧应用程序或者后端处理组件230，它包括和图2C中所示相类似的验证服务运行时间(ASR)服务器232。当域控制对应用程序服务器234的访问时，ASR服务器232负责验证用户，对应用程序234的访问可被认为是产生、取回或者以其它方式处理受保护的资源。域可继续使用旧的用户注册应用程序236关于对应用程序服务器234的访问注册用户。验证注册用户所需的信息保存在旧的用户注册处238中。

在加入联合体环境之后，域可在无联合组件的干扰的情况下继续操作。换句话说，域可被配置成使用户能够继续直接访问特定的应用程序服务器或者受保护资源，而不必经过联系点服务器或者实现这种联系点服务器功能性的其它组件；按照这种方式访问系统的用户会经历典型的验证流程和典型的访问。但是在这种做的过程中，直接访问旧系统的用户不能够建立为域的联系点服务器了解的联合会话。

通过使用联合前端处理240，域的原有功能可被并入联合体环境中，联合前端处理240包括联系点服务器242和信任代理服务器244(或者更简单地主，信任代理244)，信任代理244本身包括安全权标服务(STS)245，下面将参考图2C更详细地说明所有这些。联合体配置应用程序246允许管理用户配置联合前端组件，从而允许它们通过联合接口单元248与原有的后端组件交互作用。

位于指定企业的原有或现存验证服务可使用各种众所周知的验证方法或权标，例如用户姓名/口令或智能卡权标信息。但是，就本发明来说，通过联系点服务器的使用，可在联合体环境中使用原有的验证服务的功能性。用户可继续直接访问原有的验证服务器，而不必经过联系点服务器，不过按照这种方式访问系统的用户会经历典型的验证流程和典型的访问；直接访问原有验证系统的用户不能产生根据本发明，作为身份证据的联合验证声明。联合前端的任务之一是把在联系点服务器接收的联合验证权标转换成原有的验证服务理解的格式。从而，从而不必要求通过联系点服务器访问联合体环境的用户重新向原有的验证服务验证。最好，可借助联系点服务器和信任代理的组合，向原有的验证服务验证用户，以致看起来用户好象参与了验证会话。

联合体系统结构—联系点服务器、信任代理和信任中介 (broker)

现在参见图2C，根据本发明的实现，方框图描述了联合体系统结构。联合体环境包括联合企业或者向用户提供各种服务的类似实体。通过客户装置上的应用程序，用户可试图访问位于不同实体，例如企业250的资源。位于每个联合企业的联系点服务器，例如位于企业250的联系点(POC)服务器252是用户进入联合体环境的入口点。联系点服务器使对现有的非联合体系统结构内的现有组件的影响降至最小，因为联系点服务器处理许多联合体要求。联系点服务器提供会话管理、协议转换，可能还启动验证声明转换。例如，联系点服务器可把HTTP或HTTPS消息转换成SOAP，反之亦然。如下更详细所述，联系点服务器还可用于调用信任代理转换验证声明，例如从发布方接收的SAML权标可被转换成接收方明白的Kerberos权标。

信任代理或信任代理服务器，例如位于企业250的信任代理(TP)254建立并保持联合体中两个实体之间的信任关系。信任代理一般具有从发布方使用的格式到接收方明白的格式的验证权标格式转换能力(通过下面更详细说明的安全权标服务)。

同时，联系点服务器和信任代理的使用使实现联合体系统结构对现有的一组非联合系统的影响降至最小。从而，本发明的联合体系统结构要求每个联合实体，实现至少一个联系点服务器和至少一个信任代理，不论该实体是企业、域还是其它逻辑或物理实体。不过，本发明的联合体系统结构不必要求对现有的一组非联合系统的任何改变。最好，对于指定的联合实体，存在单一的信任代理，不过出于可用性的目的，可存在多个信任代理，或者对于联合实体内的各个更小实体，例如企业内的独立子公司，可存在多个信任代理。指定的实体有可能属于一个以上的联合体，不过这种情况不必需要多个信任代理，因为单个信任代理可管理多个联合体内的信任关系。

信任代理的一个任务是确定另一域和/或该域中的信任代理所需的权标类型。信任代理具有处理从发布方使用的格式到接收方明白的格式的验证权标格式转换的能力。信任代理254还负责关于企业250发生的任何用户身份转换或属性转换。但是，信任代理可向信任中介请求帮助，如下所述。为了把发布方已知的用户身份和属性变换成对接收方来说有意义的用户身份和属性，需要身份转换。这种转换可被位于发布域的信任代理或者被位于接收域的信任代理调用。

信任代理254可包括内在化的组件，表示为安全权标服务(STS)组件255，该组件提供权标转换，并调用验证服务运行时间(ASR)256确认和产生权标。安全权标服务提供权标实例和信任代理所需的确认服务。于是，安全权标服务包括相对于现有验证服务运行时间的接口，或者它把验证服务运行时间并于它自己的服务中。代替成为信任代理内部的一部分，安全权标服务组件也可实现成被信任代理调用的独立组件，或者可成为交易服务器内部的一部分，例如作为应用程序服务器的一部分。

例如，STS组件可接收发岂有此理Kerberos权标的请求。作为将为其产生权标的用户的验证信息的一部分，请求可包括二进制权标，二进制权标包含用户姓名和口令。STS组件将依据，例如LDAP运行时间(典型验证)确认用户姓名和口令，并调用Kerberos KDC(密钥分发中心)产生该用户的Kerberos票券。该权示被返回给信任代理，以便在企业内使用；但是，这种使用可包括使该权标具体化，以便传送给联合体中的另一域。

按照和参考图1D所述相似的方式，用户可能希望访问位于联合体环境内多个企业，例如企业250和企业260的资源。按照上面关于企业250描述的相似方式，企业260包含联系点服务器262，信任代理264，安全权标服务265，和验证服务运行时间266。虽然用户可直接启动与每个企业的单独交易，不过用户可启动与企业250的交易，所述交易串联通过联合体环境。企业250需要与联合体环境内的多个其它企业，例如企业260协作，以便完成特定交易，即使当用户启动该交易时，用户并不清楚这种必要性。企业260变成下游域，本发明允许企业250向企业260提供联合声明(如果需要)，以便继续用户的交易。

情况也可能是信任代理不知道如何解释相关联系点服务器收到的验证权标和/或如何转换指定用户身份和属性。这种情况下，信任代理必须选择调用位于信任中介组件，例如信任中介268的功能。信任中介与各个信任代理保持关系，从而在信任代理之间提供可传递的信任。使用信任中介允许联合体环境内的每个实体，例如企业250和260建立与信任中介的信任关系，而不是与联合体环境中的每个域建立多个单独的信任关系。例如，当企业260变成用户在企业250启动的交易的下游域时，位于企业250的信任代理254可确保通过请求信任中介268的帮助(如果需要)，位于企业260的信任代理264能够理解来自信任代理254的声明。虽然图2C描述了具有单个信任中介的联合体环境，不过联合体环境可具有多个信任中介。

应注意虽然图2C把联系点服务器252、信任代理254、安全权标服务组件255和验证服务运行时间256描述成不同的实体，不过不必在独立的装置上实现这些组件。例如，这些独立组件的功能可被实现成位于单一物理装置上的应用程序，或者结合在单一应用程序中。另外，图2C描述了一个企业的单个联系点服务器，单个信任代理，和单个安全权标服务器，不过一种备选结构可包括每个企业的多个联系点服务器，多个信任代理，和多个安全权标服务器。可以不同的形式，例如软件应用程序，目标程序，模块，软件库等实现联系点服务器、信任代理、安全权标服务和其它联合实体。

信任代理/STS能够接受并确认许多不同的验证凭证，包括诸如用户姓名和口令组合和Kerberos票券之类的传统凭证，和联合验证权标格式，包括第三方产生的联合验证权标格式。信任代理/STS允许在别处以验证证据的形式接受验证权标。验证权标由发布方产生，并被用于指示已向该发布方验证该用户。发布方产生验证权标，作为宣称经验证的用户身份的一种手段。

安全权标服务根据需要，调用验证服务运行时间。验证服务运行时间支持能够验证用户的验证服务。验证服务充当借助验证响应，指示验证尝试成功或失败的验证机构。信任代理/STS可使验证服务成为自己的一部分，例如其中存在不需要与现存的原有基础结构交互作用的web服务的全新安装的情形。另外，STS组件将调用外部验证服务，以便确认验证权标。例如，STS组件可“打开”包含用户姓名/口令的二进制权标，随后使用LDAP服务访问用户注册处，以便确认呈送的凭证。

当被诸如应用程序服务器之类的另一组件使用时，STS组件可被用于产生向原有的验证系统进行单一注册所需的权标。从而，STS组件可用于内部权标转换，即在企业内的权标转换，以及用于外部权标转换，即在联合体中的企业之间的权标转换。作为内部权标转换的一个例子，web应用程序服务器可通过IBM CICS(客户信息控制系统)交易网关与主机联系；CICS是为任务关键的应用程序提供企业级在线交易管理和连通性的一组应用程序服务器和连接器。web应用程序服务器可调用STS组件把Kerberos票券(由web应用程序服务器内部使用)转换成CICS交易网关所需的IBM 通行票。

可利用上面介绍的术语，例如“发布方”和“信赖方”说明图2C中所示的实体。作为确定并保持信任关系的一部分，发布方的信任代理可确定信赖方的信任代理需要/接受何种权标。从而，当从安全权标服务调用权标服务时，信任代理使用该信息。当要求发布域的信任代理为信赖方产生验证声明时，信任代理确定所需的权标类型，并从安全权标服务要求适当的权标。

当信赖域的信任代理收到来自发布方的验证声明时，信任代理知道期望何种声明，以及信赖域内的内部使用需要何种声明。信赖域的信任代理于是请求安全权标服务根据接收的验证声明中的权标，产生所需的内部应用权标。

信任代理和信任中介都具有把从发布方收到的声明转换成信赖方明白的格式的能力。信任中介具有为与其具有直接信任关系的每个信任代理解释声明格式的能力，从而允许信任中介提供发布方和信赖方之间的声明转换。任何一方可通过其本地信任代理，请求这种转换。从而，发布方的信任代理可在把声明发送给信赖方之前，请求声明的转换。同样地，信赖方的信任代理可请求从发布方收到的声明的转换。

声明转换包含用户身份转换、验证声明转换、属性声明转换、或者其它形式的声明转换。如前所述，声明转换由联合体内的信任组件，即信任代理和信任中介处理。信任代理可在发布域或者在信赖域本地完成转换，或者信任代理可向信任中介请求帮助。

假定发布方和信赖方已具有与信任中介的单独信任关系，那么如果需要，信任中介可动态产生，即促成(broker)发布方和信赖方之间的新的信任关系。在信任中介提供的初始信任关系促成操作之后，发布方和信赖方可直接保持该关系，从而对于未来的转换要求，不需调用信任中介。应注意的是可在三个可能的位置发生验证权标的转换：发布方的信任代理，信赖方的信任代理和信任中介。最好，发布方的信任代理产生信任中介明白的验证声明，以便发送给信赖方。信赖方随后请求把来自信任中介的这种权标转换成信赖方可识别的格式。可在传输之前，传输之后，或者在验证声明的传输前后发生权标转换。

联合体系统结构内的信任关系

在根据本发明实现的联合体环境内，存在两种必须管理的“信任域”：企业信任域和联合体信任域。这两种信任域之间的不同部分以管理与信任域的信任关系的商业协议和用于建立信任的技术为基础。企业信任域包含企业管理的那些组件；该信任域内的所有组件彼此信任。一般来说，不存在在企业内建立信任所需的商业协议，因为通过要求组件间相互验证的SSL会话，采用的技术产生企业内部固有的信任。参见图2B，原有应用程序和后端处理系统可代表企业信任域。

联合体信任域是跨越企业边界的那些信任域；从某一观点来看，联合体信任域可代表截然不同的企业信任域之间的信任关系。通过跨越企业边界的信任代理，建立联合体信任域。联合信任关系可涉及某一种类的自举过程，借助所述自举过程，在信任代理之间建立初始信任。这种自举过程的一部分可包括共用保密密钥和定义预期和/或许可的权标类型及标识符转换的规则的确定。一般来说，带外实现这种自举过程，因为该过程还包括管理企业在联合体中的参与，以及与这种参与相关的责任的商业协议的确定。

在联合企业模型中建立信任的机制有许多种。在联合体模型中，出于商业原因，需要联合体参与者之间信任的基本概念，以便提供在参与者之间传送的声明(包括权标和属性信息)有效的担保水平。如果不存在信任关系，那么信赖域不能依靠从发布域接收的声明；这些声明不能被信赖域用于确定如何解释从发布方接收的任何信息。

例如，大公司希望连接数千位全球客户，该公司可使用现有的解决方案。作为第一个例子，该公司可要求全球客户使用来自商业证书管理机构的数字证书建立互信。商业证书管理机构使该公司的服务器能够信任位于各个全球客户的服务器。作为第二个例子，该公司可利用Kerberos实现第三方信任；该公司及其全球客户可实现受信任的第三方Kerberos域服务，该服务实现基于共享秘密的信任。作为第三例子，该公司可利用专有的安全消息权标建立专用方案，其全球客户的服务器互信所述专有安全消息权标。

如果公司需要管理与少量全球客户的信任关系，那么这些方法中的任何一种都是可接受的，但是如果存在数以百计或数以千计的潜在联合伙伴，那么会变得难以管理。例如，虽然公司可强迫其较小的伙伴实现专用方法，但是该公司不可能能够对其较大的伙伴强加许多要求。

利用本发明，企业将采用通过信任代理，可能还有信任中介建立和保持的信任关系。本发明的联合体系统结构的一个优点是不会强加超出企业及其潜在联合伙伴的当前基本结构的额外要求。

但是，本发明不会使企业及其潜在联合伙伴免除确定参与联合体所需的商业和责任协议所需的预备工作。另外，参与者不能忽略信任关系的技术自举。本发明允许这种自举是灵活的，例如，第一联合伙伴可发布具有某些信息的Kerberos票券，而第二联合伙伴可发布具有某些信息的SAML验证声明。

本发明中，信任关系由联合体信任代理管理，联合体信任代理可包括根据两个信任代理间的预定关系，确认和转换从发布方接收的权标的安全权标服务。在联合企业不能与另一联合企业建立信任关系(和权标转换)的情形下，可调用信任中介。但是，联合企业仍然必须与信任中介建立关系。

现在参见图2D，方框图根据本发明，描述了使用信任代理和信任中介的联合域之间的一组例证信任关系。虽然图2C介绍了信任中介，不过图2D举例说明了本发明的联合体系统结构内可传递信任关系的重要性。

联合域271-273分别包含信任代理274-276。信任代理274与信任代理275具有直接信任关系277。信任中介280与信任代理275具有直接信任关系278，信任中介280与信任代理276具有直接信任关系279。信任中介280被用于代表一个联合体参与者，根据与其它联合体伙伴的可传递信任，确定信任关系。可传递信任的原理允许信任代理275和信任代理276通过信任中介280具有促成的信任关系281。信任代理275和276都不需知道如何转换或确认另一方的声明；可调用信任中介，以便把声明转换成在另一信任代理处有效、受信任和明白的声明。

通过利用ebXML(使用XML的电子商业)标准，可用XML表述相对于联合企业之间的信任关系，规定契约性义务和责任的商业协议。例如，可用ebXML文档表达直接信任关系；共享直接信任关系的每个联合域具有表述为ebXML文档的合同的副本。可在ebXML编排设计内规定联合体内各个实体的操作特性，并在ebXML注册处公布所述操作特性；希望参与特定联合体，例如操作信任代理或信任中介的任意企业需要遵守特定联合体关于该联合体内的所有信任代理或信任中介规定的公开要求。安全权标服务可按照转换来自其它域的权标的方式，关于操作细节解析这些ebXML文档。不过应注意的是，本发明也可采用其它标准和机制规定和实现联合体内的信任关系的方式相关的细节。

联合体系统结构内的声明处理

如上所述，用户在联合体内的经历部分受在域之间传送的和用户有关的声明控制。声明提供和用户的验证状态，属性信息及其它信息相关的信息。使用验证声明可使用户不必在用户访问的每个站点重新验证。在联合体环境中，获得从发布方到信赖方的声明的模式有两种：推送模式和拖拉模式。在推送模式下，用户的声明和用户的请求一起传给发布方。在拖拉模式下，在不具有任何消息的信赖方接收用户的请求，信赖方随后向发布方请求相关或者所需的声明。

已知在联合体环境内使用声明的这些模式，本发明的说明现在转向描述在本发明的联合体环境内产生和使用声明的一组过程的一组附图。图3A描述了位于发布域的，在联合体环境内产生声明的一般过程，而图3B描述了位于信赖域的，“扯下”声明，即通过抽取和分析声明的信息，将声明还原为其本质信息的一般过程。图3C和图3D通过描述推送模式的两个变形，表示了图3A中所示的一般过程的更具体过程，在推送模式中，在发布域内产生声明，随后把声明和用户的请求一起传送给信赖域。图3E描述了拖位模式，其中信赖域向发布域请求关于用户的任意所需声明，同时试图满足信赖域从发出请求的用户接收的资源请求。

现在参见图3A，流程图描述了位于发布域的，在联合体环境内产生声明的一般过程。当关于某一声明触发发布域的联系点服务器(步骤302)时，开始该过程。联系点服务器可从依赖域接收关于指定用户的特定声明请求，或者它可截取需要声明的已知信赖域的输出请求；下面分别参考图3C和3D更详细地说明了这些情形。响应关于某一声明被触发，发布域的联系点服务器向发布域的信任代理请求声明(步骤304)，发布域的信任代理产生所述声明(步骤306)；如果需要，发布域的信任代理可向信任中介请求帮助，以便产生所需的声明。在产生所述声明之后，发布域的信任代理随后把所述声明返回给发布域的联系点服务器(步骤308)，联系点服务器随后可按照适当的方式把所述声明注入输出数据流中(步骤310)，例如通过把所述声明插入输出的HTTP或SOAP消息中，从而完成该过程。

图3A描述了在不使用“本地皮夹(wallet)”的情况下，在发布域产生声明的过程。但是，本发明允许包含本地皮夹功能性。一般来说，本地皮夹是可充当用户属性信息或其它信息的保密数据库，以便简化交易的客户机方代码；客户机方代码还可参与推送和/或拖拉模式的声明传送。当本地皮夹积极参与协议时，它实现联系点服务器功能性关于产生和把声明插入协议流中的功能子集。利用本地皮夹并不便于本地皮夹实现在联系点服务器和信任代理之间发生的基于信任的交互作用。在需要其它信任关系的情况下，必须调用联系点服务器。

现在参见图3B，流程图描述了为了扯下声明，在信赖域的一般过程。当信赖域的联系点服务器收到带有相关声明的消息(步骤322)时，开始该过程，之后，它抽取所述声明，并把所述声明传送给信赖域的信任代理(步骤324)。信赖域的信任代理从声明抽取信息，包括从发布域接收的权标(步骤326)；信赖域的信任代理将调用安全权标服务来确认该权标，如果需要，把用户的本地有效权标。

作为步骤326的一部分，信任代理将确定声明的来源，即发布方。如果信任代理能够理解从该发布域接收的信任声明，那么信任代理将内部进行步骤328。如果信任代理不能理解/信任从发布域接收的声明，那么信任代理会向信任中介请求帮助。如果声明不能被确认，那么会产生恰当的错误响应。

假定声明被确认，那么信赖域的信任代理确定用户所需的本地信息(步骤330)。例如，本地信息可包括后端原有应用程序所需的验证凭证。信赖域的信任代理把所需信息返回给信赖域的联系点服务器(步骤332)，联系点服务器可建立用户的本地会话。

在联系点服务器建立用户的会话之后，用户表现为经验证的用户。联系点服务器可使用该会话信息继续管理该用户具有的与该域的任何交易，直到启动退出或超时事件为止。假定联系点服务器已具有用户的经验证的身份，那么如果需要，根据该特定用户的身份和与该特定用户相关的任何授权策略，联系点服务器可获得关于该请求的授权。联系点服务器随后把用户的请求和任何相关信息一起传送给被请求的后端应用程序或服务(步骤334)，从而完成该过程。

应注意的是在联系点服务器和信任代理之间传送的数据项和这些数据项的格式可变化。联系点服务器可把整个消息转发给信任代理，而不是从该消息抽取声明，并且只把所述声明转发给信任代理。例如，在信任代理处的处理可包括和关于SOAP消息的签名确认相似的步骤，所述签名确认需要整个SOAP包络。

现在参见图3C，流程图描述了响应位于发布域的用户操作，把声明从发布域推到信赖域的具体过程。当用户从某一Web页或者发布域内的类似资源访问信赖域的链接(步骤342)时，开始该过程，从而调用某一形式的CGI(公共网关接口)处理建立特定的声明。发布域识别信赖域需要声明的能力意味着与现有旧系统的紧密结合，在所述现有旧系统上实现本发明的联合体基础结构。它还意味着发布方和信赖方之间的紧密结合，从而发布方不必调用信任代理来建立所需的声明；在具有良好建立的信任关系的某些类型的联合实体间，这种紧密结合是合适的。

调用位于发布域的后端处理，以便建立所需的声明(步骤344)，这可包括调用位于本地信任代理的功能。随后确定用户的关于信赖域的请求，包括所需的声明(步骤346)，发布域把所述声明和用户的请求一道传送给信赖域(步骤348)，从而完成该过程。当信赖域接收该请求及其相关声明时，信赖域可按照图3B中所示的方式确认所述声明。

现在参见图3D，流程图描述了响应发布域积极截取关于信赖域的输出请求，把声明从发布域推送到信赖域的具体过程。当用户请求位于信赖域的受保护资源(步骤352)时，开始该过程。联系点服务器通过关于预定的统一资源标识符(URI)、某些种类的消息，某些种类的消息内容，或者按照其它方式，过滤输出的消息，截取输出的请求(步骤354)。发布域的联系点服务器随后向发布域的信任代理请求产生适当的声明(步骤356)，如果需要，发布域的信任代理在来自信任中介的帮助下，产生所述声明(步骤358)。发布域随后把用户的请求和产生的声明一起传送给信赖方(步骤360)，从而完成该过程。当信赖域接收该请求及其相关声明时，信赖域按照图3B中所示的方式确认所述声明。

现在参见图3E，流程图描述了信赖域向发布域请求关于用户的任何所需声明，同时试图满足信赖域从发出请求的用户接收的资源请求的拖拉模式。当信赖域收到关于受保护资源的用户请求(步骤372)时，开始该过程。和图3C或图3D中所示的例子相反，图3E中表示的例子描述了在缺少关于用户的任何所需声明的情况下，和在信赖域接收的用户请求相关的处理。这种情况下，发布域不具有截取或者处理用户的请求，以便把所需声明插入用户请求中的能力。例如，用户可能已按照输出请求不被发布域的联系点服务器截取的方式，输入统一资源定位符(URL)或使用资源的书签索引。从而，信赖域向发布域请求声明。

信赖域随后确定用户的主域(步骤374)，即相关发布域。在基于HTTP的实现中，用户可与信赖域具有预定的关系，所述预定关系导致永久cookie由位于用户的客户装置的信赖域设置。永久cookie可包含用户主域，即发布域的身份。在用户按照某一方式操纵web服务客户程序的SOAP实现中，位于信赖域的web服务已通过WSDL(Web服务描述语言)通告了服务要求，包括权标要求。这随后会要求用户的web服务客户程序/SOPA实现提供所需的权标类型。如果该要求未被满足，那么技术上，web服务会返回一个错误。在一些情况下，它可返回允许就验证信息提示用户的web服务客户程序的错误代码，从而可重复关于恰当权标的请求。

信赖域的联系点服务器利用信赖域的信任代理启动声明请求(步骤376)，信赖域的信任代理向发布域的信任代理请求关于用户的声明(步骤378)。如果实施例采用基于HTTP的通信，那么通过用户浏览器应用程序，借助重定向，信赖域的联系服务器可把从信赖域的信任代理到发布域的信任代理的声明请求传送给发布域的联系点服务器，发布域的联系点服务器把声明请求转发给发布域的信任代理。

如果实施例采用基于SOAP的实现，那么信赖域可向用户的web服务客户程序返回出错代码。该出错代码允许借助用户的web服务客户程序，就验证信息提示用户。web服务客户程序随后会产生所请求的权标。用户的web服务客户程序可直接调用信任代理，只要在UDDI(统一描述、发现和综合)中通告了信赖域的信任代理，允许用户的web服务客户程序找到该信任代理。一般来说，这种情形只对内部用户有效，在企业内的专用UDDI中通告信任代理，因为不可能在因特网上或者可在联合体外部访问的公共UDDI中通告信任代理。

发布域的信任代理按照和接收声明请求的方式对称(mirror)的方式产生所请求的声明(步骤380)，并且随后返回所请求的声明(步骤382)。在信赖域的信任代理接收所请求的声明(步骤384)之后，信赖域的信任代理从声明抽取信息(步骤386)，并且尝试解释和/或确认该声明(步骤388)；如果需要，信任代理可向信任中介请求帮助，以便转换声明。如果声明不能被确认，那么会产生适当的出错响应。假定声明被确认，那么信赖域的信任代理以供试图满足用户关于受保护资源的请求的后端服务使用所需的适当格式确定本地信息(步骤390)。例如，本地信息可包括后端原有应用程序所需的验证凭证。信赖域的信任代理把所需信息返回给信赖域的联系点服务器(步骤392)，所述联系点服务器随后建立该用户的本地会话，并把用户的请求和任何相关信息转发给被请求的后端应用程序或服务(步骤394)，从而完成该过程。

联合体系统结构内的单一注册

图2A-2D的描述集中于根据本发明的联合数据处理环境内的实体的操作特性，而图3A-3E的描述集中于在这些实体之间发生的一些过程。和这些说明相反，图4的描述集中于在向用户提供单一注册体验的同时，完成用户交易的目标。

换句话说，下面的描述讨论上面已论述的实体和过程，不过下面的描述更集中于就用户的会话内，用户可具有单一注册体验的方式而论，本发明的概观。会话可被定义为从(包括)初始用户验证，即登录到退出的一组交易。在会话内，用户的操作部分受就该会话向用户批准的特权控制。在联合体内，用户希望具有单一注册体验，在所述单一注册体验中，用户完成单个验证操作，并且在他们的会话的持续时间内，该验证操作满足需要，而与在该会话期间所访问的联合体伙伴无关。

在用户的会话过程中，用户可访问多个联合域，以便使用这些域提供的web服务。域可利用诸如UDDI和WSDL之类的标准规范，公布它们提供的服务的描述，UDDI和WSDL都使用XML作为共同的数据格式。用户通过同样遵守这些标准规范的应用程序，查找可用服务和服务提供者。SOAP提供传递以XML表述的请求和响应的范例。联合体环境内的实体可采用这些标准及其它许多标准。

为了简化单一注册体验，支持联合体环境的web服务还支持使用第三方产生的验证声明或安全权标提供用户的验证证据。这种声明还包含用户成功向发布方验证的某类证据以及该用户的标识符。从而，用户可向一个联合体伙伴提供传统的验证凭证，例如用户姓名和口令，随后向一个不同的联合体伙伴提供验证/发布方产生的SAM验证声明。

web服务环境中的验证是核实web服务请求的自称身份，从而企业可限制对授权客户机的访问。请求或调用web服务的用户理应几乎始终被验证，从而本发明的联合体环境内的验证需要和关于用户验证的web服务的现有要求没有任何不同。联合体环境还允许web服务或其它应用程序请求web服务，这些web服务也应被验证。

没有参与联合会话的用户的验证不受本发明的联合体系统结构的影响。例如，通过HTTP/S利用形式(form)验证机制验证，以便访问位于特定域的非联合资源的现有用户不会因在该域引入对联合体环境的支持而受到影响。验证部分由联系点服务器处理，联系点服务器现调用独立的信任代理组件。联系点服务器的使用使对现有域的基础结构的影响降至最小。例如，联系点服务器可被配置成通过将由位于该域的后端或原有应用程序和系统处理的所有非联合请求。

联系点服务器可选择调用基于HTTP的验证方法，例如基本验证，形式验证或者其它一些验证方法。通过识别用户以验证证据的形式提供的声明，例如SAML验证声明，联系点服务器还支持联合信任域，这里声明越过了企业信任域。联系点服务器可调用信任代理，信任代理再调用其安全权标服务，确认验证凭证/安全权标。

web服务或其它应用程序的验证包括和用户验证相同的过程。来自web服务的请求携带安全权标，安全权标包含验证声明，该安全权标应由信任代理/安全权标服务按照和用户提供的权标相同的方式被确认。来自web服务的请求应总是携带有该权标，因为web服务应已发现在UDDI中通告的，被请求服务需要何种验证声明/安全权标。

现在参见图4，方框图描述了支持联合单一注册操作的联合体环境。通过客户装置和适当的客户应用程序，例如浏览器，用户400希望访问企业/域410提供的web服务，企业/域410支持充当联合体环境内的联合域的数据处理系统。域410支持联系点服务器412和信任代理412；类似地，域420支持联系点服务器422和信任代理424，而域430支持联系点服务器432和信任代理434。信任代理依赖信任中介450的帮助，如上所述。其它域和信任代理可参与该联合体环境。图4描述了域410和域420之间的联合单一注册操作；在域410和域430之间可发生类似的操作。

用户相对于域410完成验证操作；该验证操作由联系点服务器412处理。当用户请求访问出于访问控制的目的或者出于个性化目的，需要经验证身份的某些资源时，触发验证操作。联系点服务器412可调用原有的验证服务，或者可调用信任代理414确认用户提供的验证凭证。在用户的联合会话的持续时间内，域410变成该用户的主域。

稍后，用户在联合体伙伴，例如也支持联合域的企业420启动交易，从而触发联合单一注册操作。例如，用户可在域420开始新的交易，或者用户的初始交易可级联成位于其它域的一个或多个其它交易。作为另一例子，用户可借助联系点服务器412，例如通过选择驻留在域410内的web页上的特殊链接，或者通过请求驻留在域410内，但是显示驻留在域420中的资源的入口页面，调用相对于域420中的资源的联合单一注册操作。联系点服务器412向信任代理414发送请求，产生被格式化成可被域420理解或信任的用户的联合单一注册权标。信任代理414把该权标返回给联系点服务器412，联系点服务器412把该权标发送给域中的联系点服务器422。域410充当在域420的用户的发布方，域420充分信赖方。用户的权标会和用户的请求一起传送给域420；可通过用户的浏览器，借助HTTP重定向，发送该权标，或者可通过代表在信任代理414提供的权标中识别的用户，(通过HTTP或SOAP-over-HTTP)直接调用联系点服务器422的请求，发送该权标。

联系点服务器422接收该请求以及联合单一注册权标，并调用信任代理424。信任代理424接收联合单一注册权标，确认该权标，并假定该权标有效并且可信，产生用户的本地有效权标。信任代理424把本地有效权标返回给联系点服务器422，联系点服务器422建立域422内该用户的会话。如果需要，联系点服务器422可在另一联合体伙伴启动联合单一注册。

在域420的权标确认由信任代理424处理，可能还借助来自安全权标服务的帮助。根据域410提供的权标的类型，安全权标服务可能需要访问位于域420的用户注册处。例如，域420可提供包含要依据域420的用户注册处确认的用户姓名和口令的二进制安全权标。从而，本例中，企业简单地确认来自联合体伙伴的安全权标。域410和420之间的信任关系确保域420能够理解和信任域410代表用户提供的安全权标。

联合单一注册不仅需要确认代表用户提供给信赖域的安全权标，而且需要根据包含在安全权标中的信息，确定信赖域的本地有效用户标识符。直接信任关系和建立这种关系所需的商业协议的一个结果是至少一方，发布域或信赖域或者这两者知道如何把发布域提供的信息转换成在依赖域有效的标识符。在上面的简短例子中，假定发布域，即域410能够向信赖域，即域420提供在域420有效的用户标识符。这种情形下，信赖域不需要调用任何身份映射功能。位于域420的信任代理424将为该用户产生“担保”该用户的安全权标。作为联合体的商业协议的一部分，预先确定接受的权标的类型，权标所需的签名以及其它要求。管理标识符转换的规则和算法也作为联合体的商业协议被预先确定。就两个参与者之间的直接信任关系来说，已为这两方确定了标识符转换算法，并且所述标识符算法和联合体中的其它任何方无关。

但是，发布域并不总是知道如何把用户从域410的本地标识符转换成域420的本地标识符。一些情况下，可能是信赖域知道如何完成这种变换，而在其它一些情况下，双方都不知道如何完成这种转换，这种情况下，需要调用第三方信任中介。换句话说，就促成的信任关系来说，发布域和信赖域彼此不具有直接信任关系。但是，它们与信任中介，例如信任中介450具有直接信任关系。标识符映射规则和算法被确定为该关系的一部分，信任中介将使用该信息帮助促成的信任关系所需的标识符转换。

域420在联系点服务器422接收域410发布的权标，联系点服务器422调用信任代理确认权标并执行身份映射。这种情况下，由于信任代理424不能把用户从域410的本地标识符变换成域420的本地标识符，因此信任代理424调用信任中介450，信任中介450确认该权标并执行标识符映射。在获得用户的本地标识符之后，信任代理424(可能还通过其安全权标服务)能够产生域420的后端应用程序需要的任何本地权标，例如为了简化从联系点服务到应用程序服务器的单一注册，需要Kerberos权标。在获得本地有效权标之后，如果需要，联系点服务器能够建立用户的本地会话。联系点服务器还处理用户请求的粗粒(coarse-grained)授权，并把批准的请求转发给域420内的适当应用程序服务器。

当用户退出或停止活动时，终止用户的会话。当用户退出与其主域的会话时，主域会通知所有信赖域，即主域已向其发布安全权标的那些域，并在这些域请求用户退出。如果这些信赖域中的任意域再充当同一用户的发布域，那么它们会按照级联的方式，把用户退出请求通知他们的全部信赖域。各个域的信任代理负责把用户的退出请求通知所有信赖域，作为该过程的一部分，信任代理可调用信任中介。

联合体系统结构内的拥有证明质询

正如其它任何分布式数据处理环境的情况一样，具有单一注册操作的联合体环境易受安全缺口的攻击。例如，当跨越联合体环境传送声明时，恶意用户有可能实现所谓的欺骗攻击。

作为另一例子，合法用户可执行与主域的验证操作，主域随后作为代表联合单一操作的合法用户的发布域，发布验证声明。合法用户可能离可客户装置，并认为一段时间之后，用户与主域的现行会话会被终止。但是，合法用户已使该客户装置易被非法方滥用，在合法用户的会话期满之前，恶意用户可使用该客户装置。之后，由于主域或者其它一些发布域在一段时间内，未与合法用户进行验证讨论，因此发布域不知道该客户装置正在代表恶意用户，而不是合法工作。

为了使发生这种情形的机会降至最小，并增强联合体环境内的安全性，最好在不需要改变整个联合体系统结构的情况下，在联合体环境内具有可选的额外安全等级。为此，发布方或者信赖方可直接向用户发出拥有证明质询，从而核实用户的身份，确保代表用户提供声明，验证声明或其它一些类型的声明的一方恰当且正确地代表合法用户。本质上，拥有证明需要用户证明该用户拥有只应被具有特定身份的用户合法拥有的某物，例如和用户姓名/口令组合，保密字，诸如智能卡之类硬件权标，生物统计标识符或者其它一些信息相关的知识。除了保持在用户主域的验证凭证之外，这些拥有证明凭证将被用户的主域和/或联合体内的信赖域保持。如果用户信息通过HTTP重定向从一个域传送到另一域，那么各个域会保持拥有证明凭证。如果通过SOAP而不是HTTP重定向，直接在域(信任代理到信任代理)之间传送用户信息，那么拥有证明凭证可被用户的主域保持。

剩余的附图表示了在前面论述的联合体系统结构内实现拥有证明质询的特征的不同情形。图5-8描述了表示联合体环境内实体之间信息的流动的调用流或数据流图；在每个实体，在应答接收的消息之后，响应消息的接收，执行一些处理。虽然例子表示通过用户的浏览器，利用HTTP重定向进行通信，不过当需要时，域也可直接通信。图5描述了利用位于发布域和信赖域的信任代理之间的直接通信，发布方核实的拥有证明质询。图6描述了利用位于发布域和信赖域的信任代理之间的直接通信，信赖域核实的拥有证明质询。图7描述了发布方核实的拥有证明质询，其间位于发布域和信赖域的信任代理通过信任中介通信。图8描述了信赖域核实的拥有证明质询，其间位于发布域和信赖域的信任代理通过信任中介通信。

现在参见图5，调用流图描述了利用位于发布域和信赖域的信任代理之间的直接通信，发布方核实的拥有证明质询。从发布域的联系点服务器借助用户的浏览器(步骤502)，利用HTTP重定向向信赖域的联系点服务器发送声明(步骤504)开始该过程。信赖域的联系点服务器把该声明转发给信赖域的信任代理以便确认(步骤506)。

此时，信赖域的信任代理在确认接收的声明，或者更具体地说，在代表用户执行任何进一步的操作之前，确定拥有证明质询应被用户完成。信赖域的信任代理向发布方的信任代理要求应被置入拥有证明质询中的信息(步骤508)。按照这种方式，发布域确定提供给用户或者向用户要求的信息。呼应该请求，发布域的信任代理把质询信息返回给信赖域的信任代理(步骤510)，信赖域的信任代理随后建立拥有证明质询，并将其返回给信赖域的联系点服务器(步骤512)。信赖域的联系点服务器把拥有证明质询发送给用户的浏览器(步骤514)，用户的浏览器向用户呈现所述质询(步骤516)。质询信息可采取适当的格式，例如可包括嵌入的支程序或脚本的web页。质询信息的内容要求只应被该用户拥有的一切，例如和用户姓名/口令组合，保密字，诸如智能卡之类硬件，生物统计标识符等有关的知识。另外，质询信息可被加密和/或数字签名，以保护质询信息的完整性。

在用户应答该质询(步骤518)之后，浏览器把用户对质询的响应返回给信赖域的联系点服务器(步骤520)，信赖域的联系点服务器把质询响应转发给信赖域的信任代理(步骤522)，信赖域的信任代理再把质询响应转发给发布域的信任代理以便进行确认(步骤524)。发布域不必是用户的主域；它可以是充当事实上是用户主域的发布域的一个信赖域(或者一个以上)的域。从而，如果拥有证明凭证由用户的主域保持，并且发布域不是用户的主域，那么发布域可再把请求转发给用户的主域。

总之，发布域的信任代理随后确认质询响应，随后把回答返回给信赖域的信任代理(步骤526)。这种情形下，发布域仍然是确定用户响应的有效性的唯一参与者；这样，所有验证和拥有证明凭证会由用户的主域保持，用户的主域充当用户的发布域。另外，质询响应也可被加密和/或数字签名(可能和开始传送的质询信息中的支程序或脚本配合)，以便保护质询响应的完整性。

假定用户的质询响应已被用户主域的信任代理或位于发布域的拥有证明确认信任代理成功确认，信赖域的信任代理随后向信赖域的联系点服务器服务器返回声明确认响应(步骤528)。虽然用户的质询响应已被成功确认，但是初始接收的声明不一定保证能够确认操作。假定声明被成功确认，那么在信赖域建立会话(步骤530)，之后结束该过程。随后可对与初始接收的声明相关的资源请求执行其它处理。如果用户的质询响应无效，那么信赖域可决定拒绝初始接收的声明，即使它可被成功确认。这样，联合体环境具有确定与声明相关的用户是否是与声明正确相关的合法用户的机制。

现在参见图6，调用流描述了利用位于发布域和信赖域的信任代理之间的直接通信，信赖域核实的拥有证明质询。从发布域的联系点服务器通过用户的浏览器(步骤602)，利用HTTP重定向向信赖域的联系点服务器发送声明(步骤604)开始该过程。信赖域的联系点服务器把该声明转发给信赖域的信任代理以便进行确认(步骤606)。

此时，在确认接收的声明之前，或者更具体地说，在代表用户执行任何进一步操作之前，信赖域的信任代理确定拥有证明质询应被用户完成。信赖域的信任代理向发布方的信任代理要求应被置入拥有证明质询中的信息(步骤608)。响应该请求，发布域的信任代理把质询信息返回给信赖域的信任代理(步骤610)，信赖域的信任代理随后建立拥有证明质询，并将其返回给信赖域的联系点服务器(步骤612)。信赖域的联系点服务器把拥有证明质询发送给用户的浏览器(步骤614)，浏览器向用户呈现所述质询(步骤616)。

在用户应答质询(步骤618)之后，浏览器把用户对质询的响应返回给信赖域的联系点服务器(步骤620)，信赖域的联系点服务器把质询响应转发给信赖域的信任代理(步骤622)，信赖域的信任代理随后确认质询响应。这种情形下，信赖域能够通过各种机制确定用户响应的有效性。例如，发布域可能已连同质询信息一起向信赖域提供了正确的质询响应；可通过加密保护质询响应信息，防止受到恶意用户的欺骗。

假定信赖域的信任代理已成功确认用户的质询响应，那么信赖域的信任代理把声明确认响应返回给信赖域的联系点服务器(步骤624)。虽然用户的质询响应已被成功确认，不过初始接收的声明不一定保证通过确认操作。假定声明被成功确认，那么在信赖域建立会话(步骤626)，之后结束该过程。随后可对与初始接收的声明相关的资源请求进行其它处理。如果用户的质询响应无效，那么信赖域可决定拒绝初始接收的声明，即使该声明可被成功确认。

现在参见图7，调用流图描述了发布方核实的拥有证明质询，其间位于发布域和信赖域的信任代理通过信任中介通信。从位于发布域的联系点服务器通过用户的浏览器(步骤702)，使用HTTP重定向向位于信赖域的联系点服务器发送声明(步骤704)开始该过程。信赖域的联系点服务器把该声明转发给信赖域的信任代理以便进行确认(步骤706)。

此时，在确认接收的声明之前，更具体地说，在代表用户进行任何进一步的操作之前，信赖域的信任代理确定用户应完成拥有证明质询。和图5及图6相反，信赖域的信任代理调用信任中介，请求应被置入拥有证明质询中的信息(步骤708)。信任中介随后向发布方的信任代理要求拥有证明质询信息(步骤710)。本实施例中，发布方通常理应是用户的主域。本实施例的优点在于使用信任中介；该过程避免了当在联合体内回溯多个发布域，直到到达发布域，即主域时发生的“链接”。

响应该请求，发布域的信任代理把质询信息返回给信任中介(步骤712)，信任中介随后把质询信息转发给信赖域的信任代理(步骤714)。信赖域的信任代理建立拥有证明质询，并将其返回给信赖域的联系点服务器(步骤716)，信赖域的联系点服务器把拥有证明质询发送给用户的浏览器(步骤718)，浏览器向用户呈现所述质询(步骤720)。

在用户应答所述质询(步骤722)之后，浏览器把用户对质询的响应返回给信赖域的联系点服务器(步骤724)，信赖域的联系点服务器把质询响应转发给信赖域的信任代理(步骤726)，信赖域的信任代理再把质询响应转发给信任中介，以便帮助启动确认操作(步骤728)。代理中介把质询响应转发给发布域的信任代理，以便进行确认(步骤730)。发布域的信任代理随后确认质询响应，并把回答返回给信任中介(步骤732)，信任中介把确认响应转发给信赖域的信任代理(步骤734)。按照和参考图5中的情形表示的相似方式，发布域仍然是确定用户响应的有效性的唯一参与者，但是这种情形下，信赖域向信任中介请求帮助。

假定发布域的信任代理成功确认了用户的质询响应，那么信赖域的信任代理向信赖域的联系点服务器返回声明确认响应(步骤736)。虽然用户的质询响应已被成功确认，不过初始接收的声明不一定保证通过确认操作。假定声明被成功确认，那么在信赖域建立会话(步骤738)，之后结束该过程。随后可对与初始接收的声明相关的资源请求进行其它处理。如果用户的质询响应无效，那么信赖域可决定拒绝初始接收的声明，即使该声明可被成功确认。

现在参见图8，调用流图描述了信赖域核实的拥有证明质询，其间位于发布域和信赖域的信任代理通过信任中介通信。从位于发布域的联系点服务器通过用户的浏览器(步骤802)，使用HTTP重定向向位于信赖域的联系点服务器发送声明(步骤804)开始该过程。信赖域的联系点服务器把该声明转发给信赖域的信任代理以便进行确认(步骤806)。

此时，在确认接收的声明之前，更具体地说，在代表用户进行任何进一步操作之前，信赖域的信任代理确定用户应完成拥有证明质询。信赖域的信任代理调用信任中介，请求应被置入拥有证明质询中的信息(步骤808)，信任中介再向发布方的信任代理要求获得质询信息(步骤810)。响应该请求，发布域的信任代理把质询信息返回给信任中介(步骤812)，信任中介随后把质询信息转发给信赖域的信任代理(步骤814)，信赖域的信任代理随后建立拥有证明质询，并将其返回给信赖域的联系点服务器(步骤816)。信赖域的联系点服务器把拥有证明质询发送给用户的浏览器(步骤818)，浏览器向用户呈现所述质询(步骤820)。

在用户应答所述质询(步骤822)之后，浏览器把用户对质询的响应返回给信赖域的联系点服务器(步骤824)，信赖域的联系点服务器把质询响应转发给信赖域的信任代理(步骤826)，信赖域的信任代理随后确认质询响应。

假定信赖域的信任代理成功确认了用户的质询响应，那么信赖域的信任代理随后向信赖域的联系点服务器返回声明确认响应(步骤828)。虽然用户的质询响应已被成功确认，不过初始接收的声明不一定保证通过确认操作。假定声明被成功确认，那么在信赖域建立会话(步骤830)，之后结束该过程。随后可对与初始接收的声明相关的资源请求进行其它处理。如果用户的质询响应无效，那么信赖域可决定拒绝初始接收的声明，即使该声明可被成功确认。

鉴于上面提供的本发明的详细说明，本发明的优点应是显而易见的。现有的技术方案把域安全服务组织成分级结构，要求域具有牢固的信任关系和内在兼容的技术。其它方法对验证声明强加统一格式，或者不便于验证声明的传送，有时传送据其建立本地声明的经验证身份。

在本发明的优点中，信任代理允许指定域中的现有安全服务与其它域建立信任关系，而不必预订相同的信任根源或者使用相同的信任建立技术。从而，本发明的联合体系统结构提供实体的松散结合。主域管理验证，并且每个域只管理它自己的注册用户的验证。每个域自由接受、拒绝或修改任意其它域的关于用户身份及属性的陈述。信赖域依靠发布域(归根结底，主域)的身份和属性声明，而每个域可实现任意验证协议，不需要修改指定域内的应用程序，即可实现先前不支持的协议，以便指定域参与联合体。联合体不需要特殊的信任模式；一组实体可形成遵守参与各方已建立的信任模式的联合体。只有在信任代理和/或信任中介，才可发生声明转换；联合体系统结构充当可在对现有旧系统影响极小的情况下实现的前端基础结构。

联合体允许用户按照单一注册方式，在指定联合体内的不同站点间无缝来回移动。由于在联合体参与者之间建立的信任关系的缘故，一个参与者能够验证用户，随后充当该用户的发布方。其它联合体伙伴变成信赖方，从而它们依靠发布方提供的关于用户的信息，而不直接涉及该用户。

通过借助在声明的初始传送之后执行的拥有证明质询，要求用户重新证明他们的身份，发布方和信赖方可提高联合体环境内的安全性。拥有证明并不替代验证质询/响应，而是提供额外的一层安全性。拥有证明质询还可被认为是“活性证明”质询；它是用户拥有一条或数条不能被设法劫持、截取或冒充合法用户会话的恶意用户知道的消息的测试。拥有证明质询不预防所谓的中间人攻击，除非已通过利用客户机方数字证书产生了安全会话。但是，拥有证明质询可防止其中某人非法伪称具有另一用户的身份(假定通过拥有证明质询的附加质询/响应测试，证实了该用户身份)的欺骗。如果用户不能通过拥有证明质询，那么信赖方可拒绝代表用户进行任何操作。

重要的是注意虽然在全功能数据处理系统的环境中描述了本发明，不过本领域的普通技术人员会认识到能够以计算机可读介质中的指令形式，以及各种其它形式分布本发明的处理，而不考虑实际用于实现所述分布的信号承载介质的特定类型。计算机可读介质的例子包括诸如EPROM、ROM、磁带、纸张、软盘、硬盘驱动器、RAM和CD-ROM之类介质，以及传输型介质，例如数字和模拟通信链路。

方法通常被设想为导致所需结果的前后一致的步骤序列。这些步骤需要物理量的物理处理。通常(不过不是必定)，这些物理量采取能够被存储、传送、组合、比较和以其它方式处理的电或磁信号的形式。有时主要是出于共同应用的原因，把这些信号称作位、数值、参数、项目、元素、对象、符号、字符、项、数字等是有利的。但是，应注意的是所有这些术语和类似术语与适当的物理量相关，并且只是适用于这些物理量的便利标记。

出于举例说明的目的给出了本发明的说明，但是所述说明并不是详尽的，或者局限于所公开的实施例。对本领域的普通技术人员来说，许多修改和变化是显而易见的。实施例用于说明本发明的原理及其实际应用，以及使本领域的普通技术人员能够理解本发明，以便实现具有适合于其它预期应用的各种修改的不同实施例。

Claims (24)

1.数据处理系统内的声明处理方法，所述方法包括：

在第二域中的第二信任代理从第一域内的第一信任代理接收与用户相关的声明，其中所述声明与来自客户机的访问第二域内的受控资源的请求相关；

质询客户机的用户，提供要求被与所述声明相关的用户拥有的信息；和

响应客户机的用户拥有要求被与所述声明相关的用户拥有的信息的确定，在第二信任代理确认声明。

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

从第二信任代理向第一信任代理发送质询信息请求；

在第二信任代理接收来自第一信任代理的质询信息；

在第二信任代理产生拥有证明质询，其中对拥有证明质询的有效响应包括要求被与所述声明相关的用户拥有的信息；和

向客户机发送所述拥有证明质询。

3.按照权利要求2所述的方法，还包括：

在第二信任代理确认对拥有证明质询的响应。

4.按照权利要求2所述的方法，还包括：

在第一信任代理确认对拥有证明质询的响应。

5.按照权利要求2所述的方法，还包括：

通过信任中介，在第一信任代理和第二信任代理之间传递拥有证明质询和对所述拥有证明质询的响应。

6.按照权利要求2所述的方法，还包括：

通过第三信任代理，在第一信任代理和第二信任代理之间传递拥有证明质询和对所述拥有证明质询的响应。

7.按照权利要求1所述的方法，还包括：

响应在第二信任代理的声明的成功确认，提供对受控资源的访问。

8.按照权利要求1所述的方法，还包括：

在接收对第二域中系统的受控资源的请求之前，在第一域内确定在第一信任代理产生关于该用户的声明；和

把所述声明和关于受控资源的请求一起从第一域推送给第二域。

9.按照权利要求1所述的方法，还包括：

在接收对第二域中系统的受控资源的请求之后，把所述声明从第二信任代理拉到第一信任代理。

10.按照权利要求1所述的方法，还包括：

建立第一信任代理和第二信任代理之间的信任关系。

11.按照权利要求1所述的方法，还包括：

通过信任中介，保持第一信任代理和第二信任代理之间的间接关系。

12.按照权利要求1所述的方法，其中声明是验证声明，授权声明或者属性声明。

13.数据处理系统内的声明处理设备，所述设备包括：

在第二域中的第二信任代理从第一域内的第一信任代理接收与用户相关的声明的装置，其中所述声明与来自客户机的访问第二域内的受控资源的请求相关；

质询客户机的用户，提供要求被与所述声明相关的用户拥有的信息的装置；和

响应客户机的用户拥有要求被与所述声明相关的用户拥有的信息的确定，在第二信任代理确认声明的装置。

14.按照权利要求13所述的设备，还包括：

从第二信任代理向第一信任代理发送质询信息请求的装置；

在第二信任代理接收来自第一信任代理的质询信息的装置；

在第二信任代理产生拥有证明质询的装置，其中对拥有证明质询的有效响应包括要求被与所述声明相关的用户拥有的信息；和

向客户机发送所述拥有证明质询的装置。

15.按照权利要求14所述的设备，还包括：

在第二信任代理确认对拥有证明质询的响应的装置。

16.按照权利要求14所述的设备，还包括：

在第一信任代理确认对拥有证明质询的响应的装置。

17.按照权利要求14所述的设备，还包括：

通过信任中介，在第一信任代理和第二信任代理之间传递拥有证明质询和对所述拥有证明质询的响应的装置。

18.按照权利要求14所述的设备，还包括：

通过第三信任代理，在第一信任代理和第二信任代理之间传递拥有证明质询和对所述拥有证明质询的响应的装置。

19.按照权利要求13所述的设备，还包括：

响应在第二信任代理的声明的成功确认，提供对受控资源的访问的装置。

20.按照权利要求13所述的设备，还包括：

在接收对第二域中系统的受控资源的请求之前，在第一域内确定在第一信任代理产生关于该用户的声明的装置；和

把所述声明和关于受控资源的请求一起从第一域推送给第二域的装置。

21.按照权利要求13所述的设备，还包括：

在接收对第二域中系统的受控资源的请求之后，把所述声明从第二信任代理拉到第一信任代理的装置。

22.按照权利要求13所述的设备，还包括：

建立第一信任代理和第二信任代理之间的信任关系的装置。

23.按照权利要求13所述的设备，还包括：

通过信任中介，保持第一信任代理和第二信任代理之间的间接关系的装置。

24.按照权利要求13所述的设备，其中声明是验证声明，授权声明或者属性声明。

Images