用于异构型联合环境中的本机认证协议的方法和系统的制作方法

专利名称：用于异构型联合环境中的本机认证协议的方法和系统的制作方法
技术领域：
本发明涉及改进的数据处理系统，并特别涉及用于多计算机数据传送的方法和装置。更特别地，本发明涉及网络化的计算机系统。
背景技术：
通常，企业期望跨越多种网络，包括因特网，以一种用户友好的方式向授权用户提供对受保护资源的安全访问。尽管提供安全认证机制降低了对受保护资源的未经授权的访问的风险，然而同样的安全认证机制可能会成为用户与受保护资源交互的障碍。用户通常会期望这样的能力，即从与一个应用的交互切换至与另一个应用的交互，而无需关心认证障碍，这些认证障碍用于保护支持这些应用的每一个特定系统。
由于用户变得更加成熟，他们期望计算机系统协调他们的动作，以便减轻加在用户身上的负担。这类期望也应用在认证过程上。用户会设想一旦他或她通过了某计算机系统的认证，那么这种认证就应当在该用户的工作会话期间内一直有效，或者至少在一个特定时间段内有效，而不管对于用户来说几乎不可见的各种计算机体系结构的边界。企业通常会试图在他们所部署的系统的操作特性中满足这样的期望，不仅可以安抚用户，而且可以提高用户的效率，不论这种效率是与雇员生产力还是与顾客满意度相关。
更明确地说，在当前的计算机环境中，许多应用具有基于Web的可通过常规浏览器访问的用户界面，就这样的计算机环境而言，用户期望得到更高的用户友好度，以及从一个基于Web的应用切换至另一个时较低的或较少出现的障碍。在这种情境中，用户会期望这样的能力，即从与一个因特网域上的一个应用的交互切换至与另一个域上的另一个应用的交互，而无需关心保护每一特定域的认证障碍。然而，即使许多系统通过易用的、基于Web的界面提供了安全认证，用户仍然要被迫对付多个认证过程，这些认证过程妨碍了用户跨越一组域的访问。在给定的时间范围中，使用户经历多个认证过程会极大地影响用户的效率。
多种技术被用来降低用户和计算机系统管理员的认证负担。这些技术通常被叫做“单次登录”(SSO)过程，因为它们有一个共同的目标在用户完成一次登录操作后，即通过认证后，用户随后就不需要再进行另一次认证操作了。因此，目标就是在一个特定的用户会话期间，用户仅需要完成一次认证过程。
当单次登录的解决方案在一家给定企业的内部实施时，该种方案是成功的。然而，当更多的企业参与电子商务市场或其他通过因特网连接的协作工作时，由多个认证过程或系统所带来的障碍正在变得越来越寻常。以前的企业之间的单次登录解决方案局限于同构型环境，在这种环境中，参与企业之间存在预先建立的业务协定。这些业务协定部分应用于建立信任，以及限制与规定怎样以一种安全的方式在企业间传输信息。这些业务协定也包括了关于这样的规则的技术协定，这些规则是关于怎样在一家企业和另一家企业之间转换或映射用户身份，以及怎样在参与企业之间传输用于为用户担保的信息。
换句话说，以前的单次登录解决方案允许一家企业基于事先商议好或事先配置好的协定信任由其他企业生成的认证声明(连同此声明中所提供的用户身份)。每家不同的企业都了解怎样创建和解释这样的认证声明，该声明可以被曾交换过类似协定的企业例如在同一电子商务市场内的企业所理解。由于存在着企业了解的一种确定性的关系可用来在系统之间映射用户身份，这些同构型环境是紧密结合的。由于存在用于建立单次登录环境的业务协定，这种紧密关系是可能的。
尽管参与企业可能在同构型环境中通过使用以前的单次登录解决方案来互相合作，但考虑到需要和期望互连多个同构型环境例如互连的电子商务市场，这种环境是有局限性的。因此，拥有这样的方法和系统是很有优势的，在该方法和系统中，在参与企业之间不存在预先建立的业务和技术转换协定的情况下，企业可以为用户提供类似的单次登录体验。

发明内容
提供了这样的一种方法、装置、系统和计算机程序产品，其中，联合(federated)域在一个联合环境中交互。该联合中的域可以为在其他的联合域上的用户启动联合的单次登录操作。在一个域中的接触点(point-of-contact)服务器依靠该域中的信任代理(proxy)来管理该域与该联合之间的信任关系。信任代理在必要时解释来自其他联合域的声明(assertion)。信任代理可与一个或多个信任中介(broker)建立信任关系，并且，信任代理可依靠信任中介的协助来解释声明。


在所附权利要求中提出了被认为是本发明的特征的新颖的特色。通过参考以下的详细说明并同时查看附图，能够最好地理解本发明本身、本发明的进一步目标和优势，其中，图1A描述了一个典型的数据处理系统的网络，其中每个系统均可实施本发明；图1B描述了一个典型的计算机体系结构，它可以应用于可实施本发明的数据处理系统中；图1C描述了一个数据流图，它说明了当客户端试图访问服务器上的受保护资源时可使用的一个典型认证过程；图1D描述了一个网络图，它说明了可实施本发明的一个典型的基于Web的环境；图1E描述了一个框图，它说明了一个典型的在线事务的示例，该事务可能需要用户实施多个认证操作；图2A描述了一个框图，它说明了针对一个事务的联合环境的术语，该事务由用户向第一家联合企业提出，作为响应，该企业在联合环境中的下游实体上调用动作；图2B描述了一个框图，它说明了在给定域内事先存在的系统与根据本发明的实施例的本发明的一些联合体系结构组件的集成；图2C描述了一个框图，它说明了根据本发明的一实施的联合体系结构；图2D描述了一个框图，它说明了根据本发明在使用信任代理和信任中介的各联合域之间的一组示例性的信任关系；图3A描述了一个流程图，它说明了在发布域中的一个普遍过程，此过程是为了在联合环境中创建一个声明；图3B描述了一个流程图，它说明了在依赖域中的一个普遍过程，此过程是为了拆开一个声明；图3C描述了一个流程图，它说明了一个特定的过程，此过程是为了从发布域向依赖域推一个声明，作为对发布域上的用户动作的响应；图3D描述了一个流程图，它说明了一个特定的过程，此过程是为了从发布域向依赖域推一个声明，作为对发布域主动截取一个发往依赖域的外传请求的响应；图3E描述了一个流程图，它说明了一个拉模型，在此模型中，当依赖域试图满足来自发送请求的用户的一个资源访问请求时，依赖域为用户从发布域请求获得任何需要的声明；和图4描述了一个框图，它说明了一个联合环境，该环境支持联合的单次登录操作。
具体实施例方式
一般而言，可包含本发明或者与本发明相关的设备包括了多种多样的数据处理技术。因此，在对本发明进行更详细的描述之前，作为背景，首先描述分布式数据处理系统内的硬件和软件组件的一个典型组织。
现在参考附图，图1A描述了一个典型的数据处理系统的网络，其中每一个数据处理系统均可实施本发明。分布式的数据处理系统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。支持网络的电话111通过无线链路112与网络110相连接，而个人数字助理113通过无线链路114与网络110相连接。电话111和个人数字助理113也可利用适当的技术例如蓝牙无线技术通过无线链路115在彼此之间直接传输数据，这样就可以建立起所谓的个人区域网或个人自组织(ad-hoc)网。通过类似方式，个人数字助理113与个人数字助理107可以通过无线通信链路116传输数据。
本发明可以实施于多种硬件平台上和软件环境中。图1A旨在作为异构型计算环境的一个示例，但不表明本发明在体系结构上的限制。
现在参考图1B，此图示描述了一个数据处理系统的典型的计算机体系结构，该数据处理系统例如为图1A中所示可实施本发明的数据处理系统。数据处理系统120包含了与内部系统总线123相连接的一个或多个中央处理器(CPU)122，内部系统总线123与随机存取存储器(RAM)124、只读存储器126和输入/输出适配器128相互连接，输入/输出适配器128支持各种输入/输出设备，如打印机130、盘单元132、或者其他未显示出的设备，如音频输出系统等。系统总线123也与通信适配器134连接，通信适配器134提供了对通信链路136的访问。用户接口适配器148与各种用户设备相连接，这些用户设备例如有键盘140和鼠标142，或其他未显示出的设备，如触摸屏、指示笔、麦克风等等。显示适配器144将系统总线123与显示设备146相连接。
本领域中的普通技术人员会认识到，取决于系统的实现，图1B中的硬件也可能不同。例如，该系统可能有一个或多个处理器，如一个基于IntelPentium的处理器和一个数字信号处理器(DSP)，以及一种或多种类型的易失性存储器和非易失性存储器。其他外围设施可以附加到图1B的硬件中或者代替图1B中描述的硬件。此处描述的示例并不意味着对于本发明的体系结构上的限制。
本发明除了能够实施于各种硬件平台上之外，还可以实施于各种软件环境之中。一个典型的操作系统可以用于控制每个数据处理系统内部的程序执行。例如，一个设备可以运行Unix操作系统，而另一个设备包含了一个简单的Java运行时环境。一个典型的计算机平台可包括浏览器，浏览器是众所周知的一种软件应用，用来访问各种格式的超文本文档，如图形文件、字处理软件、可扩展标记语言(XML)、超文本标记语言(HTML)、手持设备标记语言(HDML)、无线标记语言(WML)、以及其他各种格式和类型的文件。还应该注意到，在设想中，如图1A所示的分布式数据处理系统完全能够支持各种对等子网络和对等服务。
现在参考图1C，此数据流图说明了当客户端试图访问服务器上的受保护资源时的一个典型认证过程。如图所示，客户端工作站150的用户通过运行于该客户端工作站上的、用户的Web浏览器，寻求经由计算机网络访问在服务器151上的受保护资源。受保护资源由统一资源定位器(URL)，或更一般地说，由统一资源标识符(URI)所识别，只有被认证并授权的用户才能访问该统一资源定位器或统一资源标识符。该计算机网络可能是因特网、内联网或其他网络，如图1A或图1B所示，而服务器可能是Web应用服务器(WAS)、服务器应用、小服务程序进程，或诸如此类。
当用户请求访问受保护资源，如域“ibm.com”内的网页时(步骤152)，该过程就被启动。该Web浏览器(或关联的应用或小应用程序)生成一个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。
现在参考图1D，此网络图说明了可实现本发明的一个典型的基于Web的环境。在此环境中，在客户端171上的浏览器170的用户想要访问受保护资源，该受保护资源位于DNS域173内的Web应用服务器172上，或位于DNS域175内的Web应用服务器174上。
用与图1C所示类似的方式，用户可以从许多域中的一个域上请求访问受保护资源。图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注册于支持认证管理器192的ISP域191，认证管理器192对用户190进行认证，以便完成与域191有关的事务。ISP域191可以是一个因特网服务提供者(ISP)，它提供了因特网连接服务、电子邮件服务、以及其他可能的电子商务服务。或者，ISP域191可以是用户190经常访问的因特网门户。
类似的，域193、195和197代表了典型的Web服务提供者。政府域193支持认证管理器194，该认证管理器194为了完成各种与政府相关的事务而对用户进行认证。银行业务域195支持认证管理器196，该认证管理器196为了完成与在线银行的事务而对用户进行认证。电子商务域197支持认证管理器198，该认证管理器198为了完成在线购买而对用户进行认证。
如前所述，当用户通过访问不同域的资源以试图从因特网或Web内的一个域转移到另一个域时，用户会经历多个用户认证请求或要求，这会显著延缓用户跨越一系列域的进展。将图1E作为示例性环境，用户190可能参与与电子商务域197的一个复杂的在线事务，在该在线事务中，用户试图购买一种在线服务，此服务只限于提供给那些18岁以上、拥有有效驾照、有效信用卡以及美国银行帐户的用户。这个在线事务可能涉及域191、193、195和197。
典型的是，用户可能不会在参与了典型的在线事务的每个域内维护身份。在这个示例中，用户190可能已经在用户的ISP上注册了他或她的身份，但是为了完成在线事务，可能也要求该用户在域193、195和197中进行认证。如果不是每个域都为该用户维护身份，那么该用户的在线事务就会失败。即便该用户可以被每个域所认证，那也无法保证不同域能够在它们之间传输信息以完成该用户的事务。对于图1E所示的用户190来说，没有现有技术的环境允许用户190通过第一个Web站点如ISP 191的认证，并接着为实现单次登录而将一个认证权标(token)传输给其他Web服务提供者，例如域193、195和197。
在给出了上述的对一些当前技术的简要描述后，对其余附图的描述涉及本发明可在其中操作的联合计算机环境。不过，在更详细地讨论本发明之前，介绍一些术语。
术语术语“实体”和“方”通常指的是一个组织、一个个人或者一个系统，该系统代表一个组织、一个个人或另一个系统进行操作。术语“域”意味着网络环境中的其他特征，不过，术语“实体”、“方”和“域”可互换地使用。例如，术语“域”也可以指一个DNS(域名系统)域，或更一般的说，指一个数据处理系统，该系统包括了对于外部实体表现为一逻辑单元的各种设备和应用。
术语“请求”和“响应”应理解为包含数据格式化，该数据格式化适合于在特定操作中涉及的信息例如消息、通信协议信息或其他相关信息的传输。受保护资源是一种对其的访问受控制或受限制的资源(应用、对象、文档、页面、文件、可执行代码、或其他计算资源、通信类资源等等)。
权标提供了成功操作的直接证据，并由执行该操作的实体生成，例如，经过一次成功认证操作后生成的认证权标。Kerberos权标是可以应用在本发明中的认证权标的一个示例。在以下文献中可以找到关于Kerberos的更多信息Kohl等人所著的“The Kerberos Network AuthenticationService(V5)”，Internet Engineering Task Force(IETF)Request forComments(RFC)1510，09/1993。
声明为一些动作提供了间接的证据。声明可以为身份、认证、属性、授权决定、或其他信息和/或操作提供间接的证据。认证声明通过这样一个实体为认证提供间接的证据，该实体不是认证服务，而是监听该认证服务的实体。
安全性声明标记语言(SAML)的声明是可应用在本发明中的声明格式的一个示例。SAML已经被结构化信息标准促进组织(OASIS)颁布，OASIS是一个非盈利的全球社团。在“Assertions and Protocol for theOASIS Security Assertion Markup Language(SAML)”，CommitteeSpecification 01，05/31/2002中，关于SAML有如下的描述安全性声明标记语言(SAML)是一种用于交换安全信息的基于XML的框架。这种安全信息表示为关于主体的声明的形式，这里的主体是在某个安全域中具有身份的实体(人类或计算机)。主体的一个典型示例是人，由他或她在特定因特网DNS域中的电子邮件地址所识别。声明能够传达关于主体所执行的认证动作、主体的属性和关于是否允许该主体访问某些资源的认证决定的信息。声明表示为XML的构造，并具有嵌套结构，借此一个单独的声明可能包含关于认证、授权和属性的几个不同的内部陈述。应注意，包含了认证陈述的声明仅仅描述了以前发生的认证动作。声明由SAML管理机构即认证管理机构、属性管理机构和策略决定点所发布。SAML定义了一个协议，通过该协议，客户端可以请求SAML管理机构发出声明，并获得SAML管理机构的响应。这个协议由基于XML的请求和响应消息格式所组成，它可以绑定于许多不同的底层通信和传送协议；目前SAML定义了一个与HTTP上的SOAP的绑定。SAML管理机构可以使用各种信息源，例如外部策略存储和作为输入在请求中被接收的声明，以便建立响应。这样，尽管客户端总是使用声明，SAML管理机构既可以是声明的生成者也可以是声明的使用者。
该SAML规范规定了声明是一个信息包，该信息包提供由发布者生成的一个或多个陈述。SAML允许发布者生成三种不同类别的声明陈述认证，其中指定的主体在特定的时间通过特定的方法被认证；授权，其中允许指定的主体访问指定的资源的一个请求被同意或被拒绝；以及属性，其中指定的主体与提供的属性相关联。在下文的深入讨论中，在必要时各种声明的格式可以被转换成其他声明格式。
认证是验证一组由用户提供或代表用户提供的证书的过程。认证可以通过验证用户所知、用户所有、或用户所是，即关于用户的某物理特征来完成。用户所知可包括共享的秘密，如用户的口令，或者通过验证仅为特定用户所知的某事物，如用户的加密密钥。用户所有可包括智能卡或硬件权标。关于用户的某物理特征可包括生物测量输入，如指纹或视网膜图纹。
一个认证证书是用于各种认证协议的一组的质询/响应信息。例如，用户名和口令的组合是认证证书最常见的形式。其他认证证书的形式可包括各种形式的质询/响应信息、公钥基础设施(PKI)证书、智能卡、生物测量等等。认证证书与认证声明的区别在于认证证书由用户提交，作为与认证服务器或认证服务的认证协议序列的一部分，而认证声明是关于用户认证证书的成功提交和验证的陈述，随后在必要时认证声明在实体之间传输。
区别现有技术的单次登录解决方案如上所述，现有技术的单次登录解决方案限于同构型环境，在这种同构型环境中已经有在参与企业之间预先建立的业务协定。这些业务协定建立了企业之间的信任，并规定了企业之间的信息的安全传输。这些业务协定也包括关于这样的规则的技术协定，这些规则是关于怎样将用户身份从一家企业向另一家企业转换或映射，以及怎样在参与企业之间传输用于对用户进行担保的信息。
换句话说，以前的单次登录解决方案允许一家企业基于预先协商或预先配置的协定信任由另一家企业所生成的认证声明(连同声明中提供的用户身份)。每家不同的企业了解怎样创建和解释这样的认证声明，该认证声明可以被与其交换过类似协定的企业例如在同一电子商务市场里的企业所理解。由于存在企业知道的用来跨越这些系统映射用户身份的一种确定性的关系，这些同构型的环境是紧密结合的。由于存在着用于建立单次登录环境的业务协定，这种紧密关系是可能的。
本发明的联合模型在万维网的情景中，用户开始期望这样的能力，即从与一个因特网域上的应用的交互切换至与另一个域上的另一个应用的交互，而极少关心每一特定域之间的信息障碍。用户不想有由于不得不为了单个事务而进行多个域的认证所引起的挫折感。换句话说，用户期望各组织可以实现互操作，不过用户通常还需要域尊重他们的隐私。另外，用户可能更希望限制永久存储隐私信息的域。这些用户期望存在于一个快速发展的异构型环境中，在此环境中，许多企业和组织都在发布相竞争的认证技术。
与现有技术的系统相反，本发明提供了一个联合模型，该模型允许企业向用户提供单次登录体验，而无需特定企业之间特定的、预先建立的业务和技术协定。换句话说，本发明支持一种联合的异构型环境。作为本发明的目标的一个示例，再次参考图1E，用户190能够在域191中进行认证，并随后让域191向每个可能参与该事务的下游的域提供适当的声明。这些下游域要能够理解并信任验证声明和/或其他类型的声明，即使域191与其他下游域之间并没有预先建立的声明格式。除了识别该些声明之外，即便没有预先建立的身份映射关系，下游的域要能够将声明内所包含的身份转换为特定域内代表了用户190的身份。
本发明涉及一个联合环境。一般而言，企业有自己的用户注册表并维护与自己这些用户的关系。典型情况下，每家企业都有自己的对用户进行认证的方法。然而，本发明的联合模式允许企业以一种集体的方式进行合作，以便通过一家企业对企业联合的参与，一家企业的用户可以利用与一组企业的关系。用户被允许访问任何一个联合企业中的资源，就好像他们与每家企业均有直接的关系。用户不需要在每一个感兴趣的企业处注册，并且用户也不需要经常对他们自己进行识别和认证。因此，在这种联合环境内，认证模式允许在信息技术领域内快速发展的异构型环境中实现单次登录体验。
在本发明中，一个联合是这样的一组不同的实体，如企业、组织、机构等，这些实体相互合作以为用户提供单次登录的、便于使用的体验。在本发明中，联合环境与典型的单次登录环境不同，在联合环境中，两家企业无需具有直接的、预先建立的定义了怎样传输用户信息以及传输什么样的用户信息的关系。在联合环境内，实体提供服务，该些服务负责处理对用户进行认证、接受由其他实体提交的认证声明如认证权标、以及提供被担保的用户的身份向本地实体内可以理解的身份的某种形式的转换。
联合减轻了服务提供者的管理负担。服务提供者可以依靠它与总体上的联合的信任关系；服务提供者无需管理认证信息，如用户口令信息，因为它可以依靠用户的认证主域(home domain)完成的认证。
本发明也涉及了联合身份管理系统，该系统建立了一个基础，在此基础上，松散结合的认证、用户登记、用户简档管理和/或授权服务跨越安全域进行合作。联合身份管理允许在完全不同的安全的域上存在的服务安全地实现互相操作和合作，即便这些完全不同的域上的底层安全机制和操作系统平台存在差异。一旦用户在联合内建立了他们的参与，单次登录体验就建立起来了。
主域、发布方和依赖方如下面进行更详细地深入解释的，本发明提供了重要的用户利益。本发明允许用户在第一个实体处进行认证，在下文中该实体也被称为用户的主域或认证主域。该第一个实体可以担当发布方，它发布了用于在第二个实体上使用的对该用户的认证声明。接着该用户通过提交第一个实体发布的认证声明，而无需在第二个实体处显式地进行再次认证，就能够访问第二个、不同的实体上的受保护资源，这里的第二个实体被称为依赖方。从发布方传递给依赖方的信息采用一种声明的形式，且该声明包含了采取陈述形式的不同类型的信息。例如，一个声明可能是关于被认证的用户身份的陈述，或者它可能是与特定用户相关联的用户属性信息的陈述。
现在参考图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或任何其他担当了用户与其他设备和服务之间的接口的软件是不同的。在一些情况下，以下描述会界定出在客户端应用中显式地执行动作的用户和代表用户执行动作的客户端应用之间的区别。不过一般而言，请求者是可被假定为代表用户执行动作的中介，如基于客户端的应用、浏览器、SOAP客户端等等。
浏览器应用216可以是典型的浏览器，该浏览器包含了许多模块，例如HTTP通信组件220和标记语言(ML)解释器222。浏览器应用216也可支持插件，例如Web服务客户端224，和/或可下载的小应用程序，这些小应用程序可能需要、也可能不需要一个虚拟机运行时环境。Web服务客户端224可使用简单对象访问协议(SOAP)，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连接旧的后端组件。
给定企业的旧的或预先存在的认证服务可使用各种著名的认证方法或权标，例如用户名/口令或基于智能卡权标的信息。不过在本发明中，通过使用接触点服务器，旧的认证服务的功能可以用于联合环境中。用户可以继续直接访问旧的认证服务器，而无需通过接触点服务器，尽管用户以这种方式访问系统会经历典型的认证流程和典型的访问；直接访问旧的认证系统的用户将无法根据本发明生成联合认证声明以作为身份证明。联合前端的任务之一是将接触点服务器接收到的联合认证权标转换成为旧的认证服务能够理解的一种格式。因此，通过接触点服务器访问联合环境的用户就无需向旧的认证服务的再次认证。优选地，通过接触点服务器和信任代理的结合向旧的认证服务进行用户认证，从而看上去就好像用户正在参加认证会话。
联合体系结构——接触点服务器、信任代理和信任中介现在参考图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 权证(ticket)。这个权标将被返回到信任代理，以在企业内部使用；然而，这种使用可能包括将该权标外部化，以便传输到该联合内的其他域。
以针对图1D所描述的类似方式，用户可期望访问在联合环境内的多个企业如企业250和企业260两者的资源。以在上文中针对企业250所描述的方式，企业260包含接触点服务器262、信任代理264、安全权标服务265和认证服务运行时266。尽管用户可以直接启动与每个企业的单独的事务，该用户也可启动与企业250的、级联地通过联合环境的事务。企业250可能需要与联合环境内的其他多家企业如企业260合作，以完成特定的事务，即使当用户启动事务时可能还不知道这样的必要性。企业260作为下游域参与其中，而且，本发明允许企业250在必要时向企业260提交一个联合声明以促进用户的事务。
也许有这样的情况，信任代理不知道怎样解释由关联的接触点服务器接收的认证权标，和/或怎样转换给定用户的身份和属性。在这种情况下，该信任代理可选择调用信任中介组件例如信任中介268的功能。信任中介维护与各个信任代理的关系，并由此提供了信任代理之间可传递的信任。使用信任中介允许联合环境内的每个实体，例如企业250和260，建立与信任中介的信任关系，而无需建立与联合环境中的每个域的多个单独的信任关系。例如，当企业260作为被企业250的用户所启动的事务的下游域参与时，企业250处的信任代理254能够确信企业260处的信任代理264通过在必要时调用信任中介268的协助，可以理解来自信任代理254的声明。尽管图2C描述了有一单个信任中介的联合环境，但是一个联合环境可以有多个信任中介。
应该注意到，尽管图2C描述了作为不同实体的接触点服务器252、信任代理254、安全权标服务组件255和认证服务运行时256，但是这些组件不是必须在分离的设备上实现。例如，对于这些分离的组件的功能来说，有可能将它们实现为在一单个物理设备上执行的应用，或者可以将它们结合成一单个应用。此外，图2C描述了用于一家企业的单个接触点服务器、单个信任代理和单个安全权标服务器，不过可替代的配置可包括用于每家企业的多个接触点服务器、多个信任代理和多个安全权标服务。接触点服务器、信任代理、安全权标服务以及其他联合的实体能够以多种方式实现，这些方式如软件应用、对象、模块、软件库等等。
一个信任代理/STS可能有能力接受并验证许多不同的认证证书，包括传统的证书，如用户名和口令的结合和Kerberos权证，以及联合的认证权标格式，该种格式包括由第三方生成的认证权标。信任代理/STS可允许接受认证权标作为在别处的认证的证明。该认证权标由发布方生成，并用于指明用户已经通过了发布方的认证。发布方生成认证权标，作为一种声明用户的已通过认证的身份的方法。
安全权标服务在必要时调用认证服务运行时。认证服务运行时支持有能力对用户进行认证的认证服务。认证服务担当了认证管理机构，该认证管理机构通过认证响应提供了成功或失败的认证尝试的指示。信任代理/STS可以使认证的服务内部化，例如这种情况，其中有一个不需要与现存的旧的基础设施相交互的、Web服务的全新安装。否则，STS组件将调用外部的认证服务来验证认证权标。例如，STS组件可以“解开”一个含有用户名/口令的二进制权标，并随后使用LDAP服务访问用户注册表来验证提交的证书。
当STS组件被其他组件如应用服务器使用时，STS组件可以被用于生成单次登录到旧的认证系统所需的权标。因此，STS组件可以用于权标的转换，该权标的转换可以为了内部目标，也就是在企业内部，也可以为了外部目标，也就是在联合内跨越各个企业。作为内部目标的一个示例，Web应用服务器可以通过IBM CICS(客户信息控制系统)事务网关与主机相连接；CICS是应用服务器和连接器的一个族，提供了企业级别的用于使命关键性的应用的在线事务管理以及连接性。Web应用服务器可调用STS组件来把Kerberos权证(如被该Web应用服务器内部使用的)转换为CICS的事务网关所需的IBM RACF的通过权证(passticket)。
图2C所示的实体可以用上面介绍过的术语如“发布方”和“依赖方”来解释。作为建立和维护信任关系的一部分，发布方的信任代理可以确定依赖方的信任代理需要/接受什么样的权标类型。那么，当从安全权标服务调用权标服务时，信任代理就使用这个信息。当发布域的信任代理需要为依赖方生成认证声明时，该信任代理确定所需的权标类型，并从安全权标服务请求适当的权标。
当依赖域的信任代理从发布方接收到认证声明时，该信任代理知道它所期望的声明的类型，以及在依赖域内部使用所需要的声明的类型。于是，依赖域的信任代理请求安全权标服务基于接收到的认证声明中的权标，生成所需的内部使用的权标。
信任代理和信任中介都有能力把从发布方接收到的声明转换为依赖方可以理解的格式。信任中介有能力为每个有直接的信任关系的信任代理解释声明格式，从而允许该信任中介在发布方和依赖方之间提供声明的转换。任一方均可通过它本地的信任代理请求这种转换。因此，发布方的信任代理可以在声明被发送到依赖方之前请求对声明进行转换。同样的，依赖方的信任代理可以请求对从发布方接收到的声明进行转换。
对声明的转换包含了用户身份转换、认证声明转换、属性声明转换、或其他形式的声明转换。重申以上观点，对声明的转换由联合内部的信任组件，即信任代理和信任中介，来处理。信任代理可以在发布域或者依赖域实施本地转换，或者信任代理也可以调用来自信任中介的协助。
假定发布方和依赖方已经具有与信任中介的单独的信任关系，该信任中介在必要时能够动态地建立即中介安排发布方和依赖方之间的新的信任关系。在信任中介提供了初始的信任关系中介安排操作之后，发布方和依赖方就可以直接维护此关系，这样就无需为未来转换请求调用信任中介了。应该注意到，认证权标的转换可以在三个可能的地点发生发布方的信任代理、依赖方的信任代理和信任中介。优选地，发布方的信任代理生成可以被信任中介所理解的认证声明，并且信任中介将该认证声明发送到依赖方。接着依赖方请求将来自信任中介的该权标转换为可被依赖方识别的格式。权标的转换可以发生在认证声明的传输之前、或传输之后、或发生在传输前与后。
联合体系结构内部的信任关系在依照本发明实施的联合环境内部，有两种“信任域”必须被管理企业信任域和联合信任域。这两种信任域的不同点部分地基于管理与信任域的信任关系的业务协定以及建立信任所用的技术。企业信任域包含了由企业所管理的组件；该信任域内的所有组件互相信任。一般而言，在企业内建立信任是不需要业务协定的，因为所部署的技术在企业内建立了固有的信任，如通过要求组件之间相互认证的SSL会话。参考图2B，旧的应用和后端的处理系统可以代表企业的信任域。
联合信任域是那些跨越了企业边界的域；从一个视角看，联合信任域表示不同企业信任域之间的信任关系。联合信任域通过跨越企业边界的信任代理来建立。联合信任关系包括某种引导过程，通过该引导过程在信任代理之间建立初始的信任。部分该引导过程可包括共享密钥和规则的建立，这里的规则定义了期望的和/或允许的权标类型以及标识符的转换。一般而言，这种引导过程是带外(out-of-band)执行的，因为这种引导过程也包括了业务协定的建立，该些业务协定管理企业对联合的参与以及与这种参与相关联的责任。
有多种机制用来在联合业务模型中建立信任。在一个联合模型中，出于业务原因，需要提供在联合的参与者之间有信任的基本概念，以便提供一种程度的确信，确信在参与者之间传输的声明(包括权标和属性信息)是有效的。如果信任关系不存在，那么依赖域就不能依靠从发布域接收的声明；依赖域无法使用这种声明来决定怎样解释从发布域接收的任何信息。
例如，一家大公司可能想要与几千名全球客户建立联系，并且该企业可以使用现有技术的解决方案。作为第一个示例，该公司可以请求全球客户使用来自一家商业证书管理机构的数字证书来建立相互的信任。该商业证书管理机构使得该公司的服务器信任位于每个全球用户处的信任服务器。作为第二个示例，该公司可以使用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编排(choreography)内规定并发布在ebXML注册表里；希望参与一个特定联合例如以便操作信任代理或信任中介的任何企业均需要符合已发布的要求，这些要求是该特定联合为联合内所有的信任代理或信任中介规定的。安全权标服务可以解析这些ebXML文档，以获得关于来自其他域的权标将被转换的方式的操作细节。不过需要注意的是，对于怎样实现联合内的信任关系的方式，本发明可以使用其他标准和机制来规定关于此方式的细节。
联合体系结构内的声明处理如上所述，联合内的用户体验部分地由关于用户或为了用户而被跨域传输的声明所决定。声明提供了关于用户认证状态的信息、属性信息以及其他信息。通过应用认证声明可以使用户无需在访问每个站点时重新进行认证。在联合环境内部存在两种模型可以使依赖方从发布方得到声明推模型和拉模型。在推模型中，用户声明与用户对发布方的请求一同传播。在拉模型中，在依赖方只接收用户的请求，而没有任何其他信息，接着依赖方向发布方请求相关的或所需的声明。
给定在联合环境内使用声明的这些模型后，现在本发明的描述转向为一组图，该组图描述了在本发明的联合环境内部创建和使用声明的一组过程。图3A描述了在发布域中的一个普遍过程，此过程是为了在联合环境中创建一个声明，而图3B描述了在依赖域中的一个普遍过程，此过程是为了“拆开”一个声明，也就是说，通过提取和分析声明的信息，将声明分解为它的基本信息。图3C和图3D通过描述推模型的两个变种显示了图3A所示的普遍过程的更详细过程，在推模型中，声明在发布域中生成，并接着与用户请求一起被传输到依赖域。图3E描述了一个拉模型，在此模型中，当依赖域试图满足由依赖域从发请求的用户处接收到的一个资源请求时，依赖域请求从发布域获得用户的任何所要求的声明。
现在参考图3A，此流程图说明了在发布域中的一个普遍过程，此过程是为了在联合环境中创建一个声明。当发布域的接触点服务器就一个声明所触发时，此过程即开始(步骤302)。接触点服务器可以接收一个来自依赖域的用于给定用户的特定声明的请求，或者它也可以截取一个发向已知依赖域的要求声明的外出请求；这些情形分别通过图3C和图3D进行了如下更详细的描述。响应于就一个声明而被触发，发布域的接触点服务器请求从发布域的信任代理获得该声明(步骤304)，该信任代理生成该声明(步骤306)；在必要时，发布域的信任代理会请求信任中介的协助来生成要求的声明。在生成声明后，发布域的信任代理接着将该声明返回发布域的接触点服务器(步骤308)，接着发布域的接触点服务器以适当的方式将声明插入到外传的数据流中(步骤310)，例如，将声明插入到外传的HTTP或SOAP消息中，从而完成该过程。
图3A说明了在发布域创建声明的过程，该过程中无需使用“本地钱包”(local wallet)。不过，本发明可以包括本地钱包的功能。一般而言，本地钱包是客户端一方的代码，为了便利于事务，它担当了用户属性信息或其他信息的安全数据存储；客户端一方的代码也可参与到声明传输的推模型和/或拉模型中。当本地钱包主动地参与到协议中时，在生成声明以及将声明插入协议流的这一方面，本地钱包实现了接触点服务器的一部分功能。使用本地钱包不允许本地钱包实施发生在接触点服务器与信任代理之间的基于信任的交互。在需要附加的信任代理的情况时，必须调用接触点服务器。
现在参考图3B，此流程图说明了在依赖域中的一个普遍过程，此过程是为了拆开一个声明。当依赖域的接触点服务器接收到一个消息及其相关联的声明时(步骤322)，该过程开始，然后接触点服务器提取该声明并将该声明转发给依赖域的信任代理(步骤324)。依赖域的信任代理从声明中提取信息，该信息包括从发布域接收到的安全权标(步骤326)；依赖域的信任代理会调用安全权标服务来验证这个权标，如果合适，就向用户返回一个本地有效的权标(步骤328)。
作为步骤326的一部分，信任代理将确定声明的来源，即发布方。如果信任代理能够理解从该发布域接收的信任声明，那么信任代理会在内部执行步骤328。如果信任代理无法理解/信任从该发布方接收的信任声明，那么信任代理会调用来自信任中介的协助。如果声明不能被验证，那么就会生成相应的错误响应。
假设声明被验证，那么依赖域的信任代理为该用户建立所需的本地信息(步骤330)。例如，本地信息可能包括后端的旧应用所需的认证证书。依赖域的信任代理将所需的信息返回依赖域的接触点服务器(步骤332)，该接触点服务器为用户建立一个本地会话。
在接触点服务器为用户建立会话后，该用户成为已通过认证的用户。接触点服务器可使用此会话信息来进一步管理用户与域之间的任何事务，直到注销或超时事件出现为止。给定了接触点服务器拥有用户的被认证的身份，那么在必要时，基于此特定用户的身份和与此特定用户相关联的任何授权策略，接触点服务器会为这个请求获得授权。接触点服务器接着将该用户的请求以及任何相关信息转发给所请求的后端应用或服务(步骤334)，从而完成该过程。
应该注意到，在接触点服务器和信任代理之间传输的数据项以及这些数据项的格式可能不同。不是从消息中提取声明并仅仅将声明转发给信任代理，接触点服务器可将整个消息转发给信任代理。例如，在信任代理上的处理过程可包括诸如在SOAP消息上的签名验证这样的步骤，该步骤需要整个SOAP包封。
现在参考图3C，此流程图说明了一个特定的过程，此过程是为了从发布域向依赖域推一个声明，作为对发布域上的用户动作的响应。当用户从发布域内的Web页面或类似资源上访问一个指向依赖域的链接时(步骤342)，该过程开始，从而调用某种形式的CGI(通用网关接口)型处理来建立一个特定的声明。发布域有能力识别依赖域对声明的需求，这意味着与这样的现存的旧系统的紧密集成，在该旧系统上本发明的联合基础设施被实施。这也意味着发布方和依赖方之间的紧密耦合，以至于发布方不需要调用信任代理来建立所需的会话；在某些类型的已经很好地建立了信任关系的联合实体之间，这种紧密的耦合可能是适合的。
在发布域的后端处理过程被调用以建立所需的声明(步骤344)，该过程可包括调用本地信任代理的功能。接下来，对依赖域的用户请求，包括所需的声明，被建立起来(步骤346)，并且发布域将该声明以及用户请求传输到依赖域(步骤348)，从而完成该过程。当依赖域接收到该请求及其相关联的声明时，会接着以图3B所示的方式对声明进行验证。
现在参考图3D，此流程图说明了一个特定的过程，此过程是为了从发布域向依赖域推一个声明，作为对发布域主动截取一个发往依赖域的外传请求的响应。当用户请求依赖域上的受保护资源时(步骤352)，该过程开始。接触点服务器截取了外传的请求(步骤354)，例如，通过过滤外传的消息中的预先确定的统一资源标识符(URI)、消息的某些类型、消息内容的某些类型，或通过其他的一些方式。接着发布域的接触点服务器请求从发布域的信任代理生成一个适当的声明(356)，该信任代理在必要时通过信任中介的协助生成声明(步骤358)。发布域接着将用户请求和生成的声明传输到依赖方(步骤360)，从而完成该过程。当依赖域接收到请求及其相关联的声明时，依赖域会以图3B所示的方式验证该声明。
现在参考图3E，此流程图说明了一个拉模型，在此模型中，当依赖域试图满足从发请求的用户处收到的一个资源请求时，依赖域为用户从发布域请求任何需要的声明。当依赖域接收到用户对于受保护资源的请求时(步骤372)，该过程开始。与图3C或图3D所示的示例相反，图3E中所示的示例描述了和依赖域接收的用户请求相关联的处理过程，而不存在关于用户的任何所需声明。在这种情况下，发布域无法截取或以其他方式处理用户的请求以便将所需的声明插入该用户请求。例如，用户可能已经以这样的方式输入了一个统一资源定位器(URL)或使用了一个被标记为书签的对资源的引用，以至于外传的请求未被发布域的接触点服务器截取。因此，依赖域向发布域请求声明。
接着依赖域确定用户的主域(步骤374)，也即相关的发布域。在基于HTTP的实现中，用户可能已经预先建立了与依赖域的关系，这导致了依赖域在用户的客户端设备上设置永久的cookie。这个永久的cookie会包含用户主域即发布域的身份。在基于SOAP的实现中，用户以某种方式操作一个Web服务客户端，依赖域的Web服务会通过WSDL(Web服务描述语言)通告(advertise)服务需求，包括权标需求。这就会需要用户的Web服务客户端/SOAP实现来提供所需的权标类型。如果该需求没有满足，那么从技术上讲Web服务会返回一个错误。在一些情况下，它会返回一个错误代码，该错误代码会允许在用户的Web服务客户端提示输入认证信息，以便该请求可以适当的权标被重复。
依赖域的接触点服务器向依赖域的信任代理启动一个对声明的请求(步骤376)，依赖域的信任代理为用户从发布域的信任代理请求一个声明(步骤378)。如果该实施例使用基于HTTP的通信，那么依赖域的信任代理向发布域的信任代理提出的声明请求会被依赖域的接触点服务器所传输，通过用户的浏览器应用重定向到发布域的接触点服务器，发布域的接触点服务器将声明请求转发给发布域的信任代理。
如果该实施例使用基于SOAP的实现，那么依赖方会向用户的Web服务客户端返回一个错误代码。此错误代码允许Web服务客户端对用户提示输入认证信息。Web服务客户端接着会生成所请求的权标。用户的Web服务客户端可直接调用信任代理，如果依赖域的信任代理已被通告于UDDI(统一描述、发现与集成)注册表中，从而允许用户的Web服务客户端找到信任代理。一般而言，该情形只对内部用户有效，其中信任代理只在企业内部的专用UDDI中被通告，因为信任代理不太可能被通告于因特网上的公开UDDI中或可普遍地从联合外部访问到。
发布域的信任代理生成所请求的声明(步骤380)，并将其以这样的一种方式返回(步骤382)，该种方式反映了接收声明请求时所采用的方式。在依赖域的信任代理接收到所请求的声明之后(步骤384)，依赖域的信任代理从声明中提取信息(步骤386)并尝试解释和/或验证该声明(步骤388)；信任代理在必要时会调用信任中介的协助来转换该声明。如果该声明无法被验证，会生成一个适当的错误响应。假设该声明被验证，那么依赖域的信任代理以适当的格式建立本地信息，该种格式是为后端服务的使用所需要的，此后端服务将试图满足用户对受保护资源的请求(步骤390)。例如，本地信息可包括后端的旧的应用所需的认证证书。依赖域的信任代理将所需信息返回到依赖域的接触点服务器(步骤392)，接着该接触点服务器为用户建立一个本地会话并将用户请求和任何相关的信息转发给所请求的后端应用或服务(步骤394)，从而完成该过程。
联合体系结构内的单次登录图2A-2D的描述集中于根据本发明的联合数据处理环境内实体的操作特征，而图3A-3E的描述集中于在那些实体之间发生的一些过程。与这些描述相反，参考图4对本发明的描述集中在为用户完成事务并同时为用户提供单次登录体验的目标上。
换句话说，下文的描述讨论了在上文已经讨论过的实体和过程，不过以下的描述更多的集中于本发明的这样的概览，该概览是关于用户在用户会话中可以具有单次登录体验的方式。一次会话可以被定义为从(并包括)初始的用户认证即登录开始到注销的一系列事务。在一次会话中，用户的动作将部分地被为该会话授权给用户的特权所管理。在一个联合内，用户期望具有单次登录体验，其中用户仅完成一单次认证操作，并且该认证操作在会话的持续阶段是足够的，而不管在该会话中被访问的联合伙伴。
在用户会话期间，用户会访问许多的联合域以使用那些域提供的Web服务。域可使用标准的规范如UDDI和WSDL来公布它们所提供的服务的描述，UDDI和WSDL二者都使用XML作为共同的数据格式。用户通过也遵循这些标准规范的应用来发现可用的服务及服务提供者。SOAP提供了用于对于以XML表示的请求和响应进行通信的一个范式(paradigm)。联合环境内的实体可以除其他标准之外使用这些标准。
为了便利于单次登录体验，支持联合环境的Web服务也将支持使用由第三方生成的认证声明或安全权标，以提供对用户的认证的证明。这种声明将包含用户在发布方进行的成功认证的某种证据，以及该用户的标识符。因此，用户可以向一个联合伙伴提交传统的认证证书，如用户名及口令，并随后向不同的联合伙伴提供由认证/发布方所生成的SAML认证声明。
Web服务环境中的认证是检验Web服务请求所声称的身份的一种行为，以便于企业可以将访问限制于被授权客户端。请求或调用Web服务的用户几乎总是被认证，因此在本发明的联合环境内部进行认证的需求与当前的Web服务的用户认证需求并无任何差别。联合环境也允许Web服务或其他应用请求Web服务，并且这些Web服务也会被认证。
未参与到联合会话中的用户的认证不会受到本发明的联合体系结构的影响。例如，现存的用户通过HTTP/S上的基于表单的认证机制进行认证，以访问特定域上的非联合资源，那么该用户不会被该域上引入对联合环境的支持所影响。认证部分地由接触点服务器处理，接触点服务器转而可调用单独的信任代理组件。接触点服务器的使用最大程度地降低了对现存的域的基础设施的影响。例如，接触点服务器可被配置为使所有的非联合请求通过，以由域上的后端的或旧的应用和系统所处理。
接触点服务器可以选择调用基于HTTP的认证方法，如基本认证、基于表单的认证、或某种其他的认证方法。接触点服务器也支持联合信任域，这是通过识别由用户提交的作为认证证明的声明，如SAML认证声明，其中该声明跨越了企业信任域。接触点服务器可以调用信任代理，信任代理会转而调用它的安全权标服务来验证认证证书/安全权标。
Web服务或其他应用的认证包含了与用户认证相同的过程。来自Web服务的请求携带了包含认证声明的安全权标，并且信任代理/安全权标服务会以与用户提交权标相同的方式验证该安全权标。来自Web服务的请求应一直携带着这个权标，因为Web服务会发现在UDDI中通告的所请求的服务需要什么样的认证声明/安全权标。
现在参考图4，此框图说明了一个联合环境，该环境支持联合的单次登录操作。通过客户端设备和适当的客户端应用，如浏览器，用户400期望访问由企业/域410提供的Web服务，该企业/域支持在联合环境内担当了联合域的数据处理系统。域410支持接触点服务器412和信任代理414，类似地，域420支持接触点服务器422和信任代理424，而域430支持接触点服务器432和信任代理434。如上所述，信任代理依靠信任中介450提供协助。附加的域和信任代理也可参与到联合环境中。图4描述了域410和域420之间的联合单次登录操作；类似的操作也可以发生在域410和域430之间。
用户完成了对域410的认证操作；该认证操作由接触点服务器412所处理。当用户请求访问一些需要被认证的身份的资源，例如为了访问控制的目的或为了个性化的目的时，该认证操作被触发。接触点服务器412可以调用旧的认证服务，或者它也可以调用信任代理414来验证用户所提交的认证证书。域410在用户的联合会话期间成为用户的主域。
在之后的某个时间点，用户在联合伙伴例如也支持联合域的企业420处启动一个事务，从而触发一个联合单次登录操作。例如，用户可在域420上启动一个新的事务，或者用户最初的事务会级联传递为其他域上的一个或多个附加事务。作为另一示例，用户可以通过接触点服务器412调用对域420中的资源的联合单次登录操作，例如，通过选择域410中寄放的Web页面上的特殊链接，或者通过请求在域410中寄放的、但显示域420中寄放的资源的入口页面。接触点服务器412向信任代理414发送请求以便为用户生成一个联合单次登录权标，此权标被格式化以被域420理解或信任。信任代理414将此权标返回接触点服务器412，接触点服务器412再将此权标发送到域内的接触点服务器422。域410担当了对域420上的用户的发布方，而域420担当了依赖方。用户的权标会与用户请求一起传输到域420；此权标可以通过用户的浏览器使用HTTP重定向来发送，或者可以通过代表在信任代理414提供的权标中被识别的用户，直接调用对接触点服务器422(在HTTP上或在HTTP上的SOAP上)的请求来发送。
接触点服务器422接收了请求以及联合单次登录权标，并且调用信任代理424。信任代理424接收联合单次登陆权标，验证该权标，并且为用户生成本地有效的权标，假设该权标为有效的和被信任的话。信任代理424将本地有效的权标返回接触点服务器422，接触点服务器422在域420内为用户建立会话。如果必要，接触点服务器422可以在另一个联合的伙伴处启动联合单次登录。
在域420上的权标验证由信任代理424处理，也许还有来自安全权标服务的协助。取决于域410提交的权标类型，安全权标服务会需要访问域420上的用户注册表。例如，域420会提供一个包含了用户名和口令的二进制安全权标，该权标将会对照域420上的用户注册表被验证。因此，在这个示例中，一家企业简单地验证来自联合伙伴的安全权标。域410和域420之间的信任关系确保了域420能够理解并信任由域410代表该用户提交的安全权标。
联合单次登录不仅需要验证代表用户提交给依赖域的安全权标，还需要基于安全权标所包含信息确定在依赖域上本地有效的用户标识符。直接信任关系和为建立这种关系所需的业务协定的一个结果是，至少一方，或者发布域、或者依赖域、或者两者，会了解怎样将发布域提供的信息转换成为依赖域上有效的标识符。在以上简单的示例中，假设发布域即域410能够向依赖域即域420提供在域420上有效的用户标识符。在此情形中，依赖域无需调用任何身份映射功能。域420上的信任代理424会为用户生成一个可以为该用户“担保”的安全权标。被接受的权标类型、权标上所需的签名和其他要求都作为联合业务协定的一部分而预先建立了。管理标识符的转换的规则和算法也作为联合的业务协定的一部分而预先建立了。在两个参与者之间存在直接信任关系的情况下，标识符的转换算法会为该双方建立，并且不与联合内的其他任何方相关。
然而，这种情况并不经常出现发布域了解怎样把用户从域410的本地标识符映射为域420的本地标识符。在一些情况下，可能是依赖域了解怎样进行映射，而在其他情况下，双方都不了解怎样进行转换，在这些情况下，就需要调用第三方信任中介。换句话说，在存在中介安排的信任关系时，发布域和依赖域不具有彼此之间的直接信任关系。不过它们具有与信任中介如信任中介450的直接信任关系。标识符映射的规则和算法会被作为这种关系的一部分而建立，并且信任中介会使用该信息来协助进行中介安排的信任关系所需的标识符转换。
域420在接触点服务器422上接收到由域410发布的权标，该接触点服务器422调用信任代理424来验证权标和执行身份映射。在此情况下，由于信任代理424无法将用户从域410的本地标识符映射到域420的本地标识符，信任代理424调用信任中介450来验证权标和执行身份映射。在获得用户的本地标识符之后，信任代理424可能会通过它的安全权标服务生成域420上的后端应用所需的任何本地权标，例如，可能需要一个Kerberos权标来促进从接触点服务器到应用服务器的单次登录。在获得本地有效的权标后，如果需要，接触点服务器可以为用户建立本地会话。接触点服务器也可处理用户请求的粗粒度授权并将已授权的请求转发给域420内适当的应用服务器。
当用户注销或退出时，用户会话即终止。当用户注销了与主域的会话时，主域会通知所有的依赖域，即它曾经向其发布安全权标的域，并在这些域上调用用户注销操作。如果这些依赖域中的任何一个域转而曾为同一用户担当过主域，那么它们也会以级联的方式通知它们所有的依赖域该用户的注销请求。每个域的信任代理负责将用户的注销请求通知所有的依赖域，并且作为此过程的一部分，信任代理会调用信任中介。
考虑到以上提供的发明的具体描述，本发明的优势非常明显。现有技术的解决方案将域的安全服务组织成为层次系统，该层次系统需要域具有严格的信任关系和固有兼容的技术。其他方法则把统一的格式强加在认证声明上，或者不允许认证声明的传输，有时会传输一个已认证的身份，以便通过该身份来建立本地声明。
本发明的优势之一在于，信任代理允许给定域中事先存在的安全服务与其他域建立信任关系，而无需注册到同一个信任根或使用同一种建立信任的技术。因此，本发明的联合体系结构提供了实体间松散的耦合关系。主域管理认证，而每个域仅管理它自己的注册用户的认证。每个域自由地接受、拒绝、或修改其他任何域的关于用户身份和属性的陈述。依赖域依靠发布域(最终为主域)的身份和属性的声明，不过每个域可以实施任何认证协议，并且给定域内的应用不需要被修改即可运行之前不支持的协议，以使该域可以参与到联合中。联合无需特定的信任模型；一组实体可组成一个联合，该联合符合参与实体可能已经建立的信任模型。声明的转换只发生于信任代理和/或信任中介中；联合体系结构担当了前端的基础结构，此结构的实施只会对现存的旧系统带来最小限度的影响。
联合允许用户以单次登录的方式无缝地遍历给定联合内的不同站点。由于在联合参与者之间建立的信任关系，一个参与者能够认证用户，并接着担当该用户的发布方。其他的联合的伙伴成为依赖方，由此它们便依靠发布方提供的关于用户的信息，而无需直接与用户发生牵连。
需要非常注意的是，尽管本发明在文中是在完全运行的数据处理系统的情境中被描述的，本领域的普通技术人员会理解本发明的过程能够用计算机可读媒体中的指令的方式以及其他多种方式来分发，而不用关心实际用来进行分发的信号承载媒体的特定类型。计算机可读媒体的示例包括可擦可编程只读存储器、只读存储器、磁带、纸、软盘、硬盘驱动器、随机存取存储器、光盘只读存储器等媒体，以及传输型的媒体，如数字和模拟通信链路。
方法通常被认为是达到期望结果的各步骤的前后一致的序列。这些步骤需要物理量的物理操纵。通常来说，尽管不是必要的，这些物理量采用电信号或磁信号的形式，这些信号能够被存储、传输、组合、比较、以及以其他方式被操作。主要是为了常见用法的原因，称这些信号为比特、值、参数、项目、元素、对象、符号、字符、项、数字等等，常常是便利的。不过应该注意到，所有这些术语和类似术语与适当的物理量相关联，并仅仅是应用于这些物理量的方便的标记。
出于说明的目的，提供了本发明的描述，但这并不意味着该描述是详尽的或仅限于公开的实施例。对于本领域的普通技术人员来说，许多修改和变化是显而易见的。实施例只是选取出来用于解释本发明及其实际应用的原理，并使本领域的其他普通技术人员能够理解本发明，以便实施带有各种修改的各种实施例，以适应于其他预期的应用。
权利要求
1.一种用于在数据处理系统内对用户进行认证的方法，该方法包括在第一个域内的第一个信任代理上，为用户生成认证声明；在第二个域内的一系统中接收来自用户操作的客户端的访问第二个域内的受控制资源的请求；从第一个域向第二个域内的第二个信任代理发送该认证声明；以及在第二个域内的该第二个信任代理上验证该认证声明。
2.权利要求1所述的方法，还包括响应于在第二个信任代理上对认证声明的成功验证，提供对受控制资源的访问。
3.权利要求1所述的方法，还包括在第二个域内的该系统上接收到对该受控制资源的请求之前，在第一个域内确定在第一个信任代理上为用户生成认证声明；以及从第一个域向第二个域推认证声明以及对受控制资源的请求。
4.权利要求1所述的方法，还包括在第二个域内的该系统上接收到对该受控制资源的请求之后，由第二个信任代理从第一个信任代理拉认证声明。
5.权利要求1所述的方法，还包括在第一个信任代理和第二个信任代理之间建立信任关系。
6.权利要求1所述的方法，还包括通过信任中介维护在第一个信任代理和第二个信任代理之间的间接关系。
7.一种用于在数据处理系统内对用户进行认证的装置，该装置包括用于在第一个域内的第一个信任代理上为用户生成认证声明的装置；用于在第二个域内的一系统上接收来自用户操作的客户端的访问第二个域内的受控制资源的请求的装置；用于从第一个域向第二个域内的第二个信任代理发送认证声明的装置；以及用于在第二个域内的第二个信任代理上验证该认证声明的装置。
8.权利要求7所述的装置，还包括为响应在第二个信任代理上对认证声明的成功验证，提供对受控制资源的访问的装置。
9.权利要求7所述的装置，还包括用于在第二个域内的该系统上接收到对受控制资源的请求之前，在第一个域内确定在第一个信任代理上为用户生成认证声明的装置；以及用于从第一个域向第二个域推认证声明以及对受控制资源的请求的装置。
10.权利要求7所述的装置，还包括用于在第二个域内的该系统上接收到对受控制资源的请求之后，由第二个信任代理从第一个信任代理中拉认证声明的装置。
11.权利要求7所述的装置，还包括用于在第一个信任代理和第二个信任代理之间建立信任关系的装置。
12.权利要求7所述的装置，还包括用于通过信任中介维护在第一个信任代理和第二个信任代理之间的间接关系的装置。
13.一种计算机可读媒体上的计算机程序产品，用于在数据处理系统中对用户进行认证，该计算机程序产品包括用于在第一个域内的第一个信任代理上为用户生成认证声明的装置；用于在第二个域内的一系统上接收来自用户操作的客户端的访问第二个域内的受控制资源的请求的装置；用于从第一个域向第二个域内的第二个信任代理发送认证声明的装置；以及用于在第二个域内的第二个信任代理上验证该认证声明的装置。
14.权利要求13所述的计算机程序产品，还包括用于响应于在第二个信任代理上对认证声明的成功验证，提供对受控制资源的访问的装置。
15.权利要求13所述的计算机程序产品，还包括用于在第二个域内的该系统上接收到对该受控制资源的请求之前，在第一个域内确定在第一个信任代理上为用户生成认证声明的装置；以及用于从第一个域向第二个域推认证声明以及对受控制资源的请求的装置。
16.权利要求13所述的计算机程序产品，还包括用于在第二个域内的该系统上接收到对该受控制资源的请求之后，由第二个信任代理从第一个信任代理中拉认证声明的装置。
17.权利要求13所述的计算机程序产品，还包括用于在第一个信任代理和第二个信任代理之间建立信任关系的装置。
18.权利要求13所述的计算机程序产品，还包括用于通过信任中介维护在第一个信任代理和第二个信任代理之间的间接关系的装置。
全文摘要
提供了一种方法，在该方法中，在联合环境内各联合域相交互。联合内的域可以在其他联合域上为用户启动联合的单次登录操作。域内的接触点服务器依赖该域内的信任代理来管理该域和联合之间的信任关系。在必要时信任代理对来自其他联合域的声明进行解释。信任代理可具有与一个或多个信任中介的信任关系，并且信任代理可依靠信任中介来协助解释声明。
文档编号H04L29/06GK1726690SQ200380106533
公开日2006年1月25日 申请日期2003年11月27日 优先权日2002年12月31日
发明者G·R·布莱克利三世, H·M·欣顿, A·J·纳达林 申请人:国际商业机器公司