专利名称：在不同类联合环境中用于验证的方法和系统的利记博彩app
技术领域：
本发明涉及一种改进的数据处理系统，具体说，是涉及一种用于多计算机数据传输的方法和系统。更具体说，本发明针对联网的计算机系统。
背景技术：
企业一般需要为核准的用户提供保密的接入，以便按用户友好的方式，保护各种网络资源，包括互联网。虽然，为保护资源，设置保密验证机构，降低了非核准接入的风险，但同一个验证机构可能成为用户与受保护资源的交互作用的壁垒。用户一般需要从一种应用程序的交互作用跳到另一种应用程序的交互作用的能力，无须考虑支持那些应用程序的每一特定系统的验证壁垒。
当用户遇到更复杂的情况时，他们希望计算机系统能协调他们的行动，以便降低加于用户的负担。这种期望同样适用于验证过程。用户可以假定，一旦他或她已经被一些计算机系统验证，那么该验证应对该用户的整个工作对话有效，或至少在某一特定的时段有效，无须考虑对用户几乎是不可见的各种计算机体系结构边界。
企业一般试图在他们配置的各系统的操作特征中，满足这些期望，不仅为了抚慰用户，也为了增加用户的效率，不论该用户效率是涉及雇员的生产率或顾客的满意度。
更具体说，在当前的计算环境中，许多应用程序都有基于Web的用户接口，可以通过普通浏览器接入，用户期望通过更友好且低的或不频繁遇到的壁垒，从一个基于Web的应用程序移至另一个基于Web的应用程序。在这方面，用户正期望着具有这样的能力，能从一个互连网域上一个应用程序的交互作用，跳到另一个域上另一个应用程序的交互作用，无须考虑保护每一特定域的验证壁垒。即使许多系统提供了通过方便用户的、基于Web接口的保密验证，但是用户依然可能不得不慎重处理许多验证过程，这些验证过程妨碍用户在一组域上的接入。让用户在给定的时间帧内经历许多验证过程，可能极大地影响用户的效率。
已经使用了各种技术来降低用户和计算机系统管理者的验证负担。这些技术一般称为“single-sign-on(单次开始指令)”(SSO)过程，因为它们有共同的目的在用户已经完成一次开始指令操作之后，就是说，已被验证之后，该用户随后不要求进行另一次验证操作。因此，该目标是在特定的用户对话中，要求用户仅完成一次验证过程。
该单次开始指令方案在给定企业中实施时，已经获得成功。但是，随着更多企业加入由互连网连接的电子商务市场或其他合作的努力，多次验证过程或系统存在的壁垒，变得越来越常见。前面企业间的单次开始指令方案，限制在同类的环境，在同类环境中，参加的企业间有预先建立的商务协定。这些商务协定，部分用于在参加的企业间建立信托，并限制和规定如何以保密方式传递信息。这些商务协定还包括技术协定规则，规定如何把用户标识从一个企业到另一个企业的转换、或映射，以及在参加的企业间如何传送用于证明用户的信息。
换而言之，前面的单次开始指令方案，能使一个企业信托于不同企业根据预先协商或预先构建的协定而产生的某一验证断言(连同在该断言中提供的用户标识)。每一不同的企业知道如何建立并解释验证断言，该验证断言能为已经交换类似协定的其他企业，例如在电子商务市场内的企业所理解。这些同类的环境是紧密耦合的，因为存在各企业熟悉的确定性的关系，以便在这些系统上映射用户标识。这种紧密耦合是可能的，因为存在用于建立该单次开始指令环境的商务协定。
虽然各参加的企业可以通过使用这些前述单次开始指令方案，在同类环境中合作，但有鉴于必须或需要把多个同类环境互连，例如把各电子商务市场互连，所以这些环境是受限制的。因此，如果有某些方法和系统，能在各参加的企业间不设预定的商务和技术转换协定的情况下，各企业向用户提供类似于单次开始指令的经历，那是很有利的。
发明内容
本发明给出一种方法、设备、系统、和计算机程序产品，其中，联合的各域在联合环境中交互作用。联合体内的各域能够为别的联合域的用户，启动联合的单次开始指令操作。在某一域内的接点服务器，信赖该域内的信托代理所管理的该域和联合体间的信托关系。信托代理在需要时，解释来自其他联合域的断言。信托代理可以与一个或多个信托经纪人建立信托关系，并且，信托代理在解释断言时，可以信赖某个信托经纪人的帮助。
表征本发明的新颖的特性，在所附的权利要求书中说明。本发明本身、更多的目的、和优点，在结合附图阅读随后的详细说明后，将得到最佳的了解，附图有图1A画出数据处理系统的典型网络，每一系统都可以实施本发明；图1B画出可以用于数据处理系统内的典型计算机体系结构，在该计算机体系结构中可以实施本发明；图1C画出的数据流图解，表明在客户试图接入服务器受保护的资源时，可以使用的典型验证过程；图1D画出的网络简图，表明典型的基于Web的环境，可以在该环境中实施本发明；图1E画出的方框图，表明典型的联机业务例子，它可能要求对用户执行多次验证操作；图2A画出的方框图，说明联合环境对用户启动的业务的术语，该业务是用户向第一联合企业启动的，作为响应，该第一企业在联合环境内的下游实体采取调用行动；
图2B是按照本发明的一个实施例画出的方框图，表明把给定域上先前已有的各系统、与本发明一些联合的体系结构部件合并；图2C是按照本发明的一个实施例画出的方框图，表明一种联合体系结构；图2D是按照本发明画出的方框图，表明各联合域间示例性的一组信托关系，这些域使用多个信托代理和一个信托经纪人；图3A画出的流程图，表明在发出域建立联合环境内的断言的普遍化过程；图3B画出的流程图，表明在信赖域撕下断言的普遍化过程；图3C画出的流程图，表明响应发出域用户的行动，把断言从发出域推向信赖域的专用过程；图3D画出的流程图，表明响应发出域主动截接送至信赖域的请求，把断言从发出域推向信赖域的专用过程；图3E画出的流程图，表明信赖域为用户向发出域请求任何要求的断言的拉模型，同时信赖域试图满足从请求的用户收到的对资源的请求；和图4画出的方框图，表明支持联合的单次开始指令操作的联合环境。
具体实施例方式
一般说，可能组成或涉及本发明的装置，包括广泛的各种数据处理技术。因此，作为背景，在更详细地说明本发明之前，需要说明分布式数据处理系统中通常的硬件与软件成分的组织。
现在参考各图，图1A画出数据处理系统的一种典型网络，每一个数据处理系统都可以实施本发明。分布式数据处理系统100包括网络101，网络101是一种媒体，可以为各种装置与分布式数据处理系统100内连接在一起的计算机间，提供通信链路。网络101可以包括永久的连接，如线路或光纤光缆，也可以是通过电话或无线通信建立的临时连接。在图示的例子中，服务器102和服务器103与网络101连同存储单元104连接。此外，客户105-107也与网络101连接。客户105-107及服务器102-103可以代表各种计算装置，如主机、个人计算机、个人数字助理(PDA)等等。分布式数据处理系统100可以包括另外的服务器、客户、路由器、其他装置、和对等体系结构，这些都没有在图上画出。
在画出的例子中，分布式数据处理系统100可以包括以网络101代表用各种协议彼此通信的全球范围的网络和网关集合的互连网，这些协议如LDAP(Light-weight Directory Access Protocol(轻型目录接入协议))、TCP/IP(Transport Control Protocol/Internet Protocol(传送控制协议/互连网协议))、HTTP(Hyper Text Transport Protocol(超文本传送协议))等等。当然，分布式数据处理系统100还可以包括许多不同类型的网络，例如，内部网、局域网(LAN)、或广域网(WAN)。例如，服务器102直接支持客户109和网络110，后者结合了无线通信链路。网络启动电话111通过无线链路112，与网络110连接，而PDA113通过无线链路114，与网络110连接。电话111与PDA 113还能够使用适当的技术，如BluetoothTM(蓝牙)无线技术，通过无线链路115，在它们之间直接传送数据，以建立所谓个人区域网络或个人特定网络。按类似的方式，PDA 113能够通过无线通信链路116，向PDA107传送数据。
本发明可以在各种硬件平台和软件环境上实施。图1A希望作为不同类计算环境的一个例子，但不是对本发明体系结构的限制。
现在参考图1B，这是个简图，画出本发明可以在其中实施的图1A所示数据处理系统的典型计算机体系结构。数据处理系统120包括一个或多个中央处理单元(CPU)122，与内部系统总线123连接，总线123又与随机存取存储器(RAM)124、只读存储器126、和输入/输出适配器128互连，适配器128支持各种I/O装置，如打印机130、软盘单元132、或其他未画出的装置，如音频输出系统等等。系统总线123还与向通信链路136提供接入的通信适配器134连接。用户接口适配器148与各种用户装置连接，如键盘140和鼠标142，或其他未画出的装置，如触摸屏、摄像头、微音器等等。显示适配器144把系统总线123连接至显示装置146。
本领域一般人员知道，图1B中的硬件可以随系统的设置改变。例如系统可以有一个或多个处理器，诸如基于Intel(R)Pentium(R)的处理器和数字信号处理器(DSP)，以及一种或多种类型易失的或非易失的存储器。除去或取代图1B所画的硬件，也可以使用其他外围装置。画出的例子并不意味对本发明体系结构的限制。
本发明除了能在各种硬件平台上实施之外，也可以在各种软件环境中实施。可以用典型的操作系统来控制每一数据处理系统内程序的执行。例如，一个装置可以运行Unix(R)操作系统，而另一个装置可以包含一简单Java(R)运行期环境。代表性的计算机平台可以包括浏览器，这是熟知的软件应用程序，用于以各种不同格式接入超文本文件，例如图形文件、字处理文件、Extensible Markup Language(XML，可扩展审定语言)、Hypertext Markup Language(HTML，超文本审定语言)、Handheld Device Markup Language(HDML，便携装置审定语言)、Wireless Markup Language(WML，无线审定语言)、以及各种文件格式和类型。还应指出，要考虑到示于图1A的分布式数据处理系统，能充分支持各种对等子网和对等服务。
现在参考图1C，图上画出的数据流图，表明当客户试图接入服务器上受保护的资源时的典型验证过程。如图所示，客户工作站150上的用户，在计算机网络上，通过在客户工作站上运行用户的Web浏览器，寻找接入服务器151上受保护的资源。受保护的资源由UniformResource Locator(URL，统一资源定位器)，或更一般地说，由Uniform Resource Identifier(URI，统一资源标识符)标识，它只能由被验证和被核准的用户接入。计算机网络可以是互连网、内部网、或其他网络，如图1A或图1B所示，而服务器可以是Web应用程序服务器(WAS)、服务器应用程序、小服务程序(servlet)过程，诸如此类。
当用户请求受保护的资源时，如域“ibm.com”内某一Web页时，过程启动(步骤152)。Web浏览器(或有关的应用程序或小应用程序(applet))产生HTTP请求消息，发送至主持该域“ibm.com”的Web服务器(步骤153)。该服务器确定它对该用户不具有有效的对话(步骤154)，于是该服务器通过向该客户发送某些类型的验证询问，要求该用户执行验证过程(步骤155)。验证询问可以有各种不同格式，例如Hypertext Markup Language(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可以在不同域中有多个同时进行的对话，但仍要求客户171完成多个验证操作，以建立那些同时进行的对话。
现在参考图1E，图上画出的方框图，表明可能要求用户执行多次验证操作的联机业务的典型例子。再参考图1C和图1D，如图1C所示，在获得接入受控资源之前，可能要求用户完成一次验证操作。虽然图1C没有画出，但可以在服务器151上配置验证管理器，用于检索并采用为验证用户而要求的用户信息。如图1D所示，用户可以在不同域173和175中有多个当前的对话，虽然在图1D中没有把这些域画出，但每一域可以采用验证管理器，取代验证服务器或添加到验证服务器上。按类似的方式，图1E也画出一组域，每一域都支持某些类型的验证管理器。图1E画出用户在接入多个域时可能遭遇的一些困难，就是要求用户对每一域完成一次验证。
用户190在ISP域191注册，域191支持验证管理器192，为了完成用户190对域191的业务的目的，该验证管理器192验证用户190。ISP域191可以是互连网服务提供商(ISP)，提供互连网连接服务、电子邮件服务、还可能有其他电子商务服务。另外，ISP域191可以是用户190经常接入的互连网入口。
同样，域193、195、和197代表典型的web服务提供商。政务域193支持验证管理器194，为了完成各种有关政务的业务，该验证管理器194验证各用户。金融域195支持验证管理器196，为了完成与联机银行的业务，该验证管理器196验证各用户。电子商务域197支持验证管理器198，为了完成联机采购，该验证管理器198验证各用户。
如前面所指出，当用户通过接入不同域上的资源，试图在互连网或全球网上从一个域移到另一个域时，用户可能遭遇多次用户验证请求或要求，这样会极大地令用户在一组域上前进的速度变慢。用图1E作为示例性环境，用户190可能与电子商务域197卷入复杂的联机业务，其中，用户正试图采购联机的服务，该服务限制用户至少18岁且有有效的驾驶证、有效的贷记卡、及U.S.银行存折。该联机业务可能涉及域191、193、195、和197。
通常的情况是，用户可能不会在每一参与某一典型联机业务的域内，保持一个标识。在本例中，用户190可能已经把他或她的标识向该用户的ISP注册，但要完成联机业务，对域193、195、和197，该用户可能还被要求验证。如果每一域没有保持该用户的标识，那么，该用户的联机业务可能失败。即使该用户能够被每一域验证，但不保证不同的域能够为完成该用户的业务而在它们之间传送信息。对图1E中的用户190，没有现有技术环境能使用户190验证进入第一网站(web site)，如ISP 191，且之后为单次开始指令的目的，把验证令牌传送至其他web服务提供商，如域193、195、和197。
前面给出一些当前技术的简要说明，余下各图的说明，涉及本发明可以运行的联合的计算机环境。但是，在更详细讨论本发明之前，介绍一些术语。
术语词“实体”或“一方一般指以某一组织、某一个体、或某一系统的名义运行的某一组织、某一个体、或另一个系统。词“域”的意思，含有网络环境中另外的特征之意，但词“实体”“一方”和“域”可以交换使用。例如，“域”还可以指DNS(Domain NameSystem，域名系统)域，或更普遍地说，指包括各种装置和应用程序的数据处理系统，它在外部实体看来却像一逻辑单元。
词“请求”和“响应”应理解为包括数据格式化，使之适合在特定操作中信息的传送，这些特定操作中的信息如消息、通信协议信息、或其他有关的信息。受保护的资源是一种资源(应用程序、对象、文档、页、文件、可执行的代码、或其他计算的资源、通信类型资源、等等)，对该种资源的接入是受控制或限制的。
令牌提供成功操作的直接证据并由执行该操作的实体产生，例如，验证令牌是在成功的验证操作之后产生。Kerberos令牌是可以用于本发明的验证令牌的一个例子。关于Kerberos令牌的更详细信息，可在Kohl等人的“The Kerberos Network Authentication Service(V5)”，Internet Engineering Task Force(IETF)Request for Comments(RFC)1510，09/1993中找到。
断言提供一些行动的间接证据。断言可以提供标识、验证、属性、特许判定、或其他信息和/或操作的间接证据。验证断言不是由验证服务实体，而是由监听验证服务的实体提供的间接证据。
Security Assertion Markup Language(SAML，安全断言审定语言)断言是一种可以在本发明中使用的可能断言格式例子。SAML已经由Organization for the Advancement of Structured InformationStandards(OASIS)公布，它是非盈利性的全球团体。在CommitteeSpecification 01，05/31/2002的“Assertions and Protocol for the OASISSecurity Assertion Markup Language(SAML)”(“用于OASIS安全断言审定语言(SAML)的断言和协议”)中，对SAML的说明如下Security Assertion Markup Language(SAML)是一种基于XML的框架，用于交换安全信息。该种安全信息以关于主题的断言的形式表达，这里的主题是在一些安全域中具有标识的实体(或者是人或者是计算机)。主题的典型例子是人，由在某一特定互连网DNS域中他的或她的电子邮件地址标识。断言能够传送关于由主题执行的验证行动的信息、关于主题属性的信息、和关于是否允许主题接入某些资源的特许判定的信息。断言是作为XML结构表达的，且有嵌套结构，因而单个断言可以包含若干不同的关于验证、特许、和属性的内部语句。应该注意，包含验证语句的断言，仅描述以前发生的验证行动。断言由SAML管理机构发布，即验证的管理机构、属性的管理机构、和决策中心(points)发布。SAML定义一协议，通过该协议，客户可以向SAML管理机构请求断言，并从SAML管理机构获得回答。由基于XML的请求和回答消息格式构成的该协议，能够被限制在许多不同的基本通信和传输协议上；SAML普遍地定义一种在HTTP上到SOAP的绑定。SAML管理机构在建立它们的回答中，能够使用各种信息源，如外部政策存储器和在请求中作为输入而接收的断言。因此，虽然客户经常使用断言，但SAML管理机构既可以是断言的生产者，也可以是断言的使用者。
SAML的说明书指出，断言是一包信息，它提供一种或多种由发布者作出的语句。SAML允许发布者作出三种不同类型的断言语句验证，在验证中，指定的主题被特定的装置在特定的时间验证；特许，在特许中，允许指定的主题接入指定的资源的请求已经批准或拒绝；最后是属性，在属性中，把该指定的主题与提供的属性关联起来。下面还要讨论，在必要时，可以把各种断言格式转换为其他的断言格式。
验证，是对用户或以用户名义提供的一组凭证加以确认的过程。验证是通过证实用户知道的某些事情、用户拥有的某些事情、或用户是以什么来完成的，也就是通过证实关于用户的某些物理特征来完成的。用户知道的某些事情，可以包括共享的机密，诸如用户的口令，或通过证实只有特定用户知道的某些事情，诸如用户的密钥。用户拥有的某些事情，可以包括智能卡或硬件令牌。关于用户的某些物理特征，可以包括生物计量输入，诸如指纹或视网膜图。
验证凭证是一组在各种验证协议中使用的询问/回答的信息。例如，用户名与口令的组合，是最熟知的验证凭证形式。其他验证凭证的形式，可以包括各种形式的询问/回答信息、公共密钥基础结构(PKI)证书、智能卡、或生物计量，等等。验证凭证与验证断言有差别验证凭证由用户用验证服务器或服务，作为验证协议序列的一部分递交，而验证断言是关于用户的验证凭证成功递交及确认的语句，随后在必要时通过实体间传递。
有别于现有技术的单次开始指令方案如上面所指出，现有技术的单次开始指令方案，限制在同类的环境，在同类环境中，参加的企业间有预先建立的商务协定。这些商务协定在参加的企业间建立信托，并定义企业间信息的保密传送。这些商务协定还包括技术协定规则，规定如何把用户标识从一个企业到另一个企业的转换、或映射，以及在参加的企业间如何传送用于证明用户的信息。
换而言之，前面的单次开始指令方案，能使一个企业信托于不同企业根据预先协商或预先构建的协定而产生的某一验证断言(连同在该断言中提供的用户标识)。每一不同的企业知道如何建立并解释验证断言，该验证断言能为已经交换类似协定的其他企业，例如在电子商务市场内的企业所理解。这些同类的环境是紧密耦合的，因为存在各企业熟悉的确定性的关系，以便在这些系统上映射用户标识。这种紧密耦合是可能的，因为存在用于建立该单次开始指令环境的商务协定。
本发明的联合体模型在World Wide Web(全球网)的情形下，用户正在期望着能从一个互连网域的应用程序的交互作用，跳到另一个域上另一个应用程序，几乎不必考虑各特定域间的信息壁垒。用户不希望为单个业务而必须接受多个域的验证带来的挫折。换句话说，用户希望各机构彼此合作，但用户一般需要各域尊重他们的隐私。此外，用户宁可限制各域长久地存储隐私信息。用户的这些期望存在于快速进展的不同类联合环境中，在该环境中，许多企业和机构正在宣布有竞争力的验证技术。
与现有技术的系统相反，本发明提供一种联合体模型，能使各特定企业之间不设专用的、预先建立的商务和技术协定的情况下，各企业向用户提供单次开始指令的经历。换句话说，本发明支持联合的、不同类环境。作为本发明目标的一个例子，再次参考图1E，用户190能验证进入域191，然后让域191向可能涉及业务的各下游域，提供适当的断言。即使域191与这些其他下游域之间没有预先建立的断言格式，但这些下游域必须能理解并信托于验证断言和/或其他类型的断言。即使没有预先建立标识变换关系，但下游域除了识别断言之外，必须能把包含在断言内的标识转换为特定域中代表用户190的标识。
本发明针对一种联合环境。一般说来，企业有它自己用户的注册表，并保持与它自己一组用户的关系。每一企业通常有它自己验证这些用户的手段。但是，本发明的联合模式，能使企业以集体方式合作，使在一个企业内的各用户，通过企业加入企业的联合体，而与一组企业建立优势关系。用户可以获准接入联合企业任一个的资源，仿佛他们与每一企业都有直接的关系。不要求用户在关心的每一商务上注册，且不总是要求用户标识和验证他们自己。因此，在这样的联合环境内，一次验证模式能在信息技术迅速进展的不同类环境中，实现单次开始指令的经历。
本发明中，联合体是一组不同的实体，例如企业、机构、协会等等，共同合作，以便向用户提供单次开始指令的、易于使用的经历。本发明中，联合环境与通常的单次开始指令环境的差别在于，两个企业无需有直接的、预先建立的关系，这种关系规定如何传送及传送什么用户信息。在联合环境中，各实体提供的服务有，验证用户、接受例如由其他实体递交的验证令牌等断言、和提供一些标识转换形式，以便把证明用户的标识变换为本地实体能理解的标识。
联合体能使服务提供商的管理负担变轻。服务提供商可以作为一个整体地信赖它与联合体间的信托关系；服务提供商不必管理验证信息，如用户口令信息，因为它能信赖用户验证的原籍域完成的验证。
本发明还涉及一种联合的标识管理系统，在该联合标识管理系统建立的基础上，松弛耦合的验证、用户登记、用户简历管理和/或特许服务，在各安全域上合作。即使在这些完全不同的域上，基本的安全机构和操作系统平台不同，但联合标识管理能使各完全不同的安全域中驻留的服务，安全地彼此协作和合作。一旦用户加入了联合体，即建立了单次开始指令经历。
原籍域、发出方、和信赖方下面还要作更详细的讲解，本发明向用户提供显著的利益。本发明能使用户在第一实体上验证，该第一实体本文下面也称之为用户的原籍域或验证的原籍域。该第一实体可以起发出方的作用，它发出关于用户的验证断言，供第二实体使用。然后，用户能接入第二个、性质不同的实体上受保护的资源，该第二个、性质不同的实体，因为递交第一实体发出的验证断言，不必在第二实体明显地重新验证，所以称为信赖方。从发出方传递至信赖方的信息，是按断言的形式来传递，而该断言可以包括语句形式的不同类型信息。例如，断言可以是关于用户验证标识的语句，或可以是与特定用户有关的用户属性信息的语句。
现在参考图2A，这是方框图，表明联合环境对用户向第一联合企业启动业务的术语，该第一企业作为响应，在联合环境中的下游实体执行调用行动。图2A表明，术语可以不同，随联合体内的实体对某一给定联合操作的观点而定。用户202通过请求企业204上某种受保护的资源，启动某一业务。如果用户202已经被企业204验证，那么，对该联合对话而言，企业204就是该用户的原籍域。假设该业务要求企业206执行某些类型的操作，且企业204已把断言传送至企业206，那么，对该特定操作而言，企业204是发出域，又对该特定操作而言，企业204是信赖域。假设该业务要求更多的操作，且企业206已把断言传送至企业208，那么，企业206是该要求的操作的发出域，而企业208是该操作的信赖域。
在本发明的联合环境中，用户在其上验证的域被称为用户的(验证)原籍域。原籍域保持验证凭证。原籍域可以是用户的雇主、用户的ISP、或某些别的服务的提供商。在联合环境内，可以有多个企业起到用户原籍域的作用，因为可以有多个企业有能力产生并确认某一用户的验证凭证。
从验证的观点看，验证断言的发出方，一般是用户的验证原籍域。用户的原籍域可以为该用户，也可以不为该用户保持个人信息或简历信息。因此，从涉及个人可标识的信息的属性观点看，个人化的信息，或其他用户属性，属性断言的发出方可以是，也可以不是用户的验证原籍域。为避免任何混淆，可以对属性原籍域和验证原籍域采用分开的术语，但“原籍域”一词，在本文下面可以解释为验证原籍域。
但是，在给定的联合对话范围内，通常是一个且只有一个域起用户原籍域的作用。用户一旦已经在该域被验证，所有在该联合体内其他域或企业，在该对话时期内都按信赖方处理。
假定本发明提供的联合的基础结构，可以添加到现有的系统，同时对现有的、非联合的基础结构影响最小，那么，在用户原籍域上的验证，不因原籍域还可以加入联合环境中而改变。换而言之，即使该原籍域可以并入按本发明实施的联合环境，但用户在用户的原籍域执行验证操作的时候，可以有相同的终端用户的经历。虽然应指出，不是所有给定企业的用户都必须加入联合环境。
还有，用户注册，如用户帐号的建立，不因原籍域还可以加入联合环境之内而改变。用户在原籍域通过与联合环境无关的注册过程，建立帐号。换而言之，用户帐号在原籍域的建立，不包括在联合体上有效帐号信息的建立，例如标识转换信息。如果有单个联合的域能验证一用户，即，联合体内有一个且只有一个用户已经向之注册的域，那么该域将经常起该用户原籍域的作用，并引导用户在整个联合环境中的移动。
任何用户在联合环境内有多个可能的原籍域，那么，用户可以通过多于一个入口点进入联合体。换而言之，用户可以在多个域上有帐号，且这些域不必拥有其他域的信息，也不必拥有用户在其他域的标识。
虽然用户在其上验证的域被称为原籍域，而发出域是发出断言的联合体的实体，供另一个域，即信赖域使用。发出域通常是，但不必须是用户的原籍域。因此，如上所说，发出方已经通过通常的验证协议验证用户的情形是常有的。但是，情形也可能是，发出方早先已经作为信赖方，因而它从不同的发出方接收断言。换句话说，因为用户启动的业务可以通过一系列联合环境内企业的级联，接收方可以随后作为下游业务的发出方。一般说，任何域有能力以用户名义发出验证断言，都能作为发出域。
信赖域是从发出方接收断言的域。信赖域能接收、信托、并理解以用户名义的第三方即发出域发出的断言。使用适当的验证权限来解释验证断言，通常是信赖方的工作。此外，信赖方能验证一特定用户，即作为用户的原籍域，是可能的，但信赖方不能通过常规方法验证一特定用户，同样是可能的。因此，信赖方是这样的一个域或一个企业，它信赖用户提交的验证断言，并且向用户提供单次开始指令经历，而不是把提示用户提供用户验证凭证作为与用户对话的一部分。
联合的体系结构—作为传统系统的联合前端现在参考图2B，这是按照本发明的一个实施例画出的方框图，表明在给定域把先前已有的各系统，与本发明一些联合的体系结构部件的合并。联合环境包括为用户提供各种服务的联合的实体。用户212与客户装置214交互作用，后者支持浏览器应用程序216及各种其他客户应用程序218。用户212不同于客户装置214、浏览器216、或任何作为用户与其他装置及服务之间接口的软件。在某些情形下，下面的说明，可以使客户应用程序内明显作用的用户，区别于以用户名义正在作用的客户程序。然而，一般说，请求者是中间人，诸如基于客户的应用程序、浏览器、SOAP客户、等等，可以假定它们是以用户名义起作用的。
浏览器应用程序216可以是包括许多模块的典型浏览器，诸如HTTP通信部件220及审定语言(ML)解释器222。浏览器应用程序216还可以支持插入程序(plug-ins)，诸如web服务客户224，和/或可下载的小应用程序(applets)，这些插入的应用程序可以要求，也可以不要求虚机器运行期环境。Web服务客户224可以使用Simple ObjectAccess Protocol(SOAP，简单目标接入协议)，该协议是轻型协议，用于定义分散化的、分布式的环境中，结构性的和打印式的信息交换。SOAP是基于XML的协议，包括三部分定义框架的包封，说明消息中有什么消息和如何处理该消息；一组编码规则，用于表达应用程序规定的数据类型的实例(instance)；及对表达远程程序呼叫和响应的约定。用户212可以用浏览器应用程序216接入基于web的服务，但用户212也可以通过客户装置214上的其他web服务客户，接入web服务。下面各图所示本发明的一些例子，采用经用户浏览器的HTTP再引导，在联合环境的各实体间交换信息。但是，应当指出，本发明可以在各种通信协议上实施，所以不意味着仅限于基于HTTP的通信。例如，在需要时，联合环境中各实体可以直接通信；不要求把信息通过用户浏览器的再引导。
本发明可以把联合环境要求的部件与先前已有的系统合并而实现。图2B画出一个用这些部件作为先前已有系统的前端的实施例。在联合域中先前已有的部件，可以考虑作为传统的应用程序或后端处理部件230，它按类似于图2C所示的方式包括验证服务运行期(ASR)服务器232。当该域控制接入应用程序服务器234时，ASR服务器232负责验证用户，可以认为ASR服务器232是用于产生、检索、或其他保护资源的过程。该域可以继续使用传统的用户注册应用程序236来让用户注册，以便接入应用程序服务器234。验证注册用户需用的信息，存储在传统的用户注册表238中。
在与联合环境结合之后，该域可以不用联合部件的介入而继续运行。换句话说，该域的结构能使用户继续直接接入特定应用程序服务器或其他受保护资源，无需经由接点服务器或其他实施该接点服务器功能的部件；按此方式接入系统的用户，将经历典型的验证流程和典型的接入。但是，这样做时，直接接入传统系统的用户，不能把该域熟悉的联合对话建立在该域的接点服务器上。
该域的传统功能，可以通过使用联合的前端处理240，并入联合环境，该前端处理240包括接点服务器242和信托代理服务器244(或更简单地说，信托代理244)，信托代理244本身包括Security TokenService(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(Key Distribution Center，密钥分配中心)来为该用户产生Kerberos证。该令牌被发回信托代理，供企业内使用；但是，这一使用可以包括使令牌外部化，以便传送至联合体内另一个域。
按对图1D说明类似的方式，用户可能希望接入联合环境中多个企业的资源，如企业250和企业260两个企业的资源。按上面对企业250说明类似的方式，企业260包括接点服务器262、信托代理264、安全令牌服务265、和验证服务运行期266。虽然用户可以直接启动与每一企业的分开的业务，但该用户可以启动与企业250的业务，让企业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部件“unpack(拆开)”包含用户名/口令的二进制令牌，然后使用LDAP服务接入用户注册表，以证实提交的凭证。
当STS部件被另一个部件，如某一应用程序服务器使用时，能用STS部件产生向传统验证系统要求单次开始指令的令牌。因此，STS部件能为内部的目的，即在企业内，用于令牌的转换，以及为外部的目的，即在联合体中各企业上，用于令牌的转换。作为一个内部目的的例子，Web应用程序服务器可以通过IBM CICS(Customer InformationControl System，顾客信息控制系统)业务网关，与主机对接；CICS是一族应用程序服务器和连接器，提供企业级的联机业务管理与关键任务应用程序(mission-critical application)的连通性。Web应用程序服务器可以调用STS部件，把Kerberos证(由Web应用程序服务器在内部使用)转换为CICS业务网关要求的IBM RACF(R)通行证。
示于图2C的各实体，可以用上面介绍的术语解释，如“发出方”和“信赖方”。发出方的信托代理，作为建立和保持信托关系的一部分，能确定何种令牌类型是信赖方的代理要求/接受的。因此，信托代理在向安全令牌服务调用令牌服务时，要使用该种信息。当要求发出域的信托代理为信赖方产生验证断言时，该信托代理确定要求的令牌类型，并向安全令牌服务请求适当的令牌。
当信赖域的信托代理从发出方接收验证断言时，该信托代理知道它期望的是何种类型的断言，和它需要供信赖域内部使用的是何种类型的断言。信赖域的信托代理因而请求安全令牌服务根据接收的验证断言中的令牌，产生要求的、内部使用的令牌。
信托代理和信托经纪人两方，都有能力把从发出方接收的断言，转换为信赖方理解的格式。信托经纪人有能力为每一与它有直接信托关系的信托代理，解释断言的格式，从而能使信托经纪人在发出方和信赖方之间提供断言转换。该转换能够由该两方的任一方，通过它的本地信托代理提出请求。因此，发出方的信托代理，能够在断言发送至信赖方之前，请求把断言转换。同样，信赖方的信托代理能够请求把从发出方接收的断言进行转换。
断言转换包括用户标识转换、验证断言转换、属性断言转换、或其他断言形式的转换。联合体内的信托部件，即，信托代理和信托经纪人，不断重复上述要点，处理断言的转换。在发出域或在信赖域的信托代理，可以在本地执行该转换，或者，信托代理可以调用信托经纪人的帮助。
假定一发出方和一信赖方已经各自与一信托经纪人建立信托关系，那么，如有必要，该信托经纪人能够动态地在各发出方和各信赖方之间建立，即作为经纪人来安排，新的信托关系。在信托经纪人提供的经纪人安排操作建立初始信托关系之后，发出方和信赖方可以直接保持该关系，于是，不必为将来的转换要求而调用信托经纪人。应当指出，验证令牌的转换能发生在3个可能的地方发出方的信托代理、信赖方的信托代理、和信托经纪人。最好是，发出方的信托代理产生能由信托经纪人理解的验证断言，发送至信赖方。然后，信赖方请求信托经纪人把该令牌转换为信赖方能识别的格式。令牌转换可能发生在该验证断言传输之前、在传输之后、或既在传输之前也在传输之后。
联合体系结构内的信托关系在按本发明实施的联合环境内，有两种“信托域”必须管理企业信托域和联合体信托域。该两种信托域之间的差别，部分基于调节与信托域的信托关系的商务协定，和用于建立信托的技术。企业信托域包含由企业管理的那些部件；所有在该信托域内的部件彼此信托。一般说，企业内不要求用商务协定来建立信托，因为调度技术在企业内建立内在的信托，例如通过在各部件间要求互相验证的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(Electronic Business using XML，使用XML的电子商务)标准，以XML表达。例如，直接信托关系可以按ebXML文件表达；共享直接信托关系的每一联合域，存在以ebXML文件表达的合同副本。联合体内各种实体的运行特征，可以在ebXML编排法内详细说明，并在ebXML注册表内公开；任何希望参加特定联合体的企业，如使用信托代理或信托经纪人，必须确认由该特定联合体公布详细说明的、对该联合体内所有信托代理或信托经纪人的要求。安全令牌服务为了操作上的细节，按转换其他域来的令牌的方式，对这些ebXML文件进行句法分析。然而，应当指出，本发明可以采用其他标准和机构，来说明联合体内信托关系实施的方式的细节。
联合的体系结构内的断言处理如上面所指出，用户在联合体内的经历，部分受关于用户的断言或对跨越各域传递的用户的断言所调节。断言提供关于用户验证状态的信息、属性信息、和其他信息。使用验证断言能够在用户访问的任何位置上，消除对用户再验证的必要。在联合环境中，有两种模型可以获得从发出方送至信赖方的断言推模型和拉模型。在推模型中，用户的断言随用户的请求传送至发出方。在拉模型中，在信赖方接收用户的请求，不带任何信息，然后，信赖方向发出方请求相关的或要求的断言。
已经给出这些在联合环境中使用断言的模型，现在本发明的说明转向一组图，这些图说明在本发明的联合环境中建立和使用断言的一组过程。图3A画出在发出域建立联合环境中的断言的一种普遍化过程，而图3B画出在信赖域“撕下”断言的普遍化过程，即，通过析取和分析断言的信息，把断言缩减为它的基本信息的普遍化过程。图3C和3D通过画出推模型的两个变量，为图3A所示的普遍化过程，画出更为详细的过程，在该推模型中，断言在发出域中产生，然后随用户的请求传送至信赖域。图3E画出拉模型，其中，信赖域为用户向发出域请求任何要求的断言，同时信赖域试图满足从请求的用户收到的对资源的请求。
现在参考图3A，这是流程图，表明发出域为建立联合环境内的断言的普遍化过程。该过程在发出域接点服务器被断言触发时开始(步骤302)。接点服务器可以为给定用户的特定断言，从信赖域接收请求，也可以截接发向已知信赖域的要求断言的请求；这些情况下面还要分别对图3C和图3D作更详细说明。对断言的触发的响应，发出域的接点服务器向该发出域的信托代理请求断言(步骤304)，于是信托代理产生断言(步骤306)；如有必要，发出域的信托代理可以请求信托经纪人的帮助，以产生要求的断言。产生断言后，发出域的信托代理随后把断言发回发出域的接点服务器(步骤308)，然后，接点服务器把断言按适当方式注入输出的数据流(步骤310)，比如通过把断言插入送出的HTTP或SOAP消息，从而完成该过程。
图3A画出的在发出域建立断言的过程，没有用到“本地工具箱但是，本发明还能包括本地工具箱功能。一般说，本地工具箱是客户侧的代码，它的作用是供用户属性信息或其他信息的保密数据存储，以利于业务处理；客户侧的代码还可以加入断言传递的推和/或拉模型。当本地工具箱主动加入该协议时，它在产生断言和把断言插入协议流方面，实现接点服务器功能的一种子功能。使用本地工具箱不能让该本地工具箱实现基于信托的、发生在接点服务器与信托代理之间的交互作用。在要求额外的信托关系的情形，必须调用接点服务器。
现在参考图3B，这是流程图，表明在信赖域撕下一断言的普遍化过程。该过程在信赖域的接点服务器收到带有有关断言的消息时开始(步骤322)，之后，它析取断言并把断言转发至信赖域的信托代理(步骤324)。信赖域的信托代理从该断言析取信息，包括从发出域接收的令牌(步骤326)；信赖域的信托代理将调用安全令牌服务来证实该令牌，如果合适，则把本地证实的该用户的令牌发回(步骤328)。
作为步骤326的一部分，信托代理将确定断言的源，即发出方。如果信托代理能理解从该发出域接收的信托断言，信托代理将在内部执行步骤328。如果信托代理不能理解从该发出域接收的信托断言，信托代理可以调用信托经纪人的帮助。如果该断言不能被证实，则产生适当的错误响应。
假定断言被证实，那么信赖域的信托代理为用户建立要求的本地信息(步骤330)。例如，该本地信息可以包括后端传统应用程序要求的验证凭证。信赖域的信托代理把要求的信息，发回信赖域的接点服务器(步骤332)，由该服务器为用户建立本地对话。
在服务器为用户建立本地对话之后，该用户仿佛是已被验证的用户。接点服务器能用该对话信息，进一步调节用户涉及该域的任何业务，直至启动了注销或时间已到。假如接点服务器有该用户已验证的标识，则该接点服务器可以在必要时，根据该特定用户的标识和与该特定用户有关的任何特许政策，为该请求获得特许。然后，接点服务器把用户的请求及任何相关信息，转发至被请求的后端应用程序或服务(步骤334)，从而完成该过程。
应当指出，在接点服务器与信托代理之间传送的数据项，和这些数据项的格式，是可以变化的。代替从消息析取断言和只把断言转发至信托代理，接点服务器可以把整个消息转发至信托代理。例如，在信托代理上的处理，可以包括类似在SOAP消息上签名证实的步骤，这一步骤可能需要整个SOAP包封。
现在参考图3C，这是个流程图，表明响应发出域用户的作用，把断言从发出域推向信赖域的专用过程。该过程当用户从发出域内的Web页或类似的资源，接入通向信赖域的链路时开始(步骤342)，开始的过程据此调用某些形式的CGI式(Common Gateway Interface，公共网关接口)处理，以便建立特定的对话。发出域识别信赖域需要断言的能力，表明与现有传统系统的紧密结合，而本发明联合体系结构是在现有传统系统上实施的。它还表明发出方与信赖方之间的紧密耦合，使得发出方不必调用信托代理来建立要求的断言；在某些类型的已经建立良好信托关系的联合实体之间，这种紧密耦合是合适的。
调用信赖域上的后端处理来建立要求的断言(步骤344)，该后端处理可以包括本地信托代理的调用功能。然后，建立用户向信赖域的请求，包括要求的断言(步骤346)，然后，发出域把该断言随同用户的请求，传送至信赖域(步骤348)，从而完成该过程。当信赖域接收该请求及与它有关的断言时，信赖域随后将按图3B所示方式，证实该断言。
现在参考图3D，这是个流程图，表明响应发出域主动截接送出至信赖域的请求，把断言从发出域推向信赖域的专用过程。该过程当用户请求信赖域上受保护的资源时开始(步骤352)。接点服务器例如通过过滤向预定的Uniform Resource Identifiers(URI的，统一资源标识符)送出的消息、某些类型的消息、某些类型的消息内容、或某些其他方式，截接送出的请求(步骤354)。然后，发出域的接点服务器请求发出域的信托代理产生适当的断言(步骤356)，如有必要，该信托代理在信托经纪人的帮助下产生断言(步骤358)。然后，发出域把用户的请求连同产生的断言，传送至信赖方(步骤360)，从而完成该过程。当信赖域收到该请求及与它有关的断言，信赖域随后将按图3B所示方式，证实该断言。
现在参考图3E，这是个流程图，表明信赖域为用户向发出域请求任何要求断言的拉模型，同时信赖域试图满足从请求的用户收到的对资源的请求。该过程当信赖域收到用户请求受保护的资源时开始(步骤372)。与图3C或图3D所示例子相反，图3E所示例子说明的处理，与信赖域收到的用户的请求有关，该请求没有任何关于用户要求的断言。在此情形下，发出域不具备截接或其他处理用户请求的能力，不能在用户的请求中插入要求的断言。例如，该用户可能已经进入UniformResource Locator(URL，统一资源定位器)，或已经对资源使用了书签标记，使送出的请求不能被发出域的接点服务器截接。为此，信赖域向发出域请求断言。
然后，信赖域确定用户的原籍域(步骤374)，即相关的发出域。在基于HTTP的设置中，在用户的客户装置上设置了持久cookie的信赖域，用户已经与该信赖域预先建立了关系。该持久的cookie包含用户的原籍域即发出域的标识。在基于SOAP的设置中，用户以某些方式正在操作web服务客户时，信赖域上的web服务可能已通过WSDL(WebServices Description Language，Web服务说明语言)被通告了服务要求，包括令牌要求。这种情况可能要求用户的web服务客户/SOAP设置提供要求的令牌类型。如果不满足这一要求，那么，web服务将在技术上发回一错误。在某些情形中，是发回一错误代码，该代码能提示用户的web服务客户输入验证信息，所以该请求能以适当的令牌重复。
信赖域的接点服务器用信赖域的信托代理，启动断言请求(步骤376)，该断言请求向发出域的信托代理为该用户请求断言(步骤378)。如果该实施例采用基于HTTP的通信，那么，从信赖域信托代理到发出域信托代理的断言请求，可以由信赖域的接点服务器，经过再引导，通过用户的浏览器应用程序，到达发出域上的接点服务器，发出域的接点服务器把断言请求转发至发出域的信托代理。
如果该实施例采用基于SOAP的通信，那么，信赖方可能把错误代码发回用户的web服务客户。该错误代码能通过用户的web服务客户向用户提示输入验证信息。然后，web服务客户产生请求的令牌。只要已经在UDDI(Universal Description、Discovery、and Integration)注册表中通告了信赖域的信托代理，允许用户的web服务客户查找信托代理，那么，用户的web服务客户可以直接调用该信托代理。一般说，这种情形只对互连网用户有效，在互连网上，信托代理是在企业内的隐蔽UDDI中通告的，因为把信托代理在互连网的公共UDDI上通告，或在联合体外普遍都能接入，是不太可能的。
发出域的信托代理，按与接收该断言方式相反的方式，产生请求的断言(步骤380)，然后发回请求的断言(步骤382)。信赖域的信托代理收到请求的断言之后(步骤384)，信赖域的信托代理从该断言析取信息(步骤386)并试图解释和/或证实该断言(步骤388)；如有必要，该信托代理可以调用信托经纪人的帮助，以便转换该断言。如果该断言不能被证实，那么将产生适当的错误响应。假定断言被证实，那么，信赖域的信托代理以适当格式建立本地信息，要求该适当的格式能被后端服务使用，以便尝试满足用户对受保护资源的请求(步骤390)。例如，本地信息可以包括后端传统应用程序要求的验证凭证。信赖域的信托代理把要求的信息发回信赖域的接点服务器(步骤392)，然后，信赖域的接点服务器为该用户建立本地对话，并把用户的请求连同任何相关信息，转发至被请求的后端应用程序或服务(步骤392)，从而完成该过程。
良好体系结构内的单次开始指令图2A-2D的说明，聚焦在按照本发明的联合数据处理环境内实体的运行特征上，而图3A-3E的说明，则聚焦在那些实体之间发生的某些过程上。与这些说明相反，参照图4对本发明的说明，聚焦在为用户完成业务的目标上，同时向用户提供单次开始指令经历。
换而言之，本文下面的说明，是讨论已经在上面讨论过的实体和过程，虽然下面的说明，更多地聚焦在纵览本发明能让用户在他的对话中有单次开始指令经历方面。对话能够定义为一组业务，从(包括)启动用户的验证即注册，到注销。在对话中，用户的行动将部分地受为该对话授予用户的特权的调节。在联合体内，用户期望有单次开始指令的经历，在这种经历中，用户完成单次验证操作，而该验证操作足以在他们的对话时间中持续作用，不受在该对话时间访问的联合体伙伴的影响。
在用户对话时，用户可以访问许多联合的域，使用这些域提供的web服务。这些域能够用标准的说明书，如UDDI和WSDL，两者都用XML作为公共数据格式，公布它们提供的服务的说明。用户通过也附于这些标准说明书的应用程序，查找可用的服务和服务提供商。SOAP提供传送以XML表达的请求和响应的范例。联合环境中各实体，尤其可以采用这些标准。
为有利于单次开始指令经历，支持联合环境的web服务，也将支持使用第三方产生的验证断言或安全令牌来提供用户验证的证明。该断言包含某些类型的用户被发出方成功验证的证据，以及该用户的标识符。因此，用户可以向一个联合体伙伴提交传统的验证凭证，如用户名和口令，然后，向不同的联合体伙伴提供SAML验证断言，该SAML验证断言由验证操作/发出方产生。
web服务环境中的验证，是证明web服务请求所要求的标识的行动，使企业能够限制向核准客户的接入。请求或调用web服务的用户，几乎常常是被验证了的，所以，在本发明的联合环境内对验证的需要，与当前web服务对用户验证的要求，没有任何不同。联合环境也允许web服务请求web服务，或其他应用程序请求web服务，而这些web服务也应被验证。
没有加入联合对话的用户的验证，不因本发明的体系结构而受影响。例如，在HTTP/S上用基于形式(forms-based)的验证机构验证，接入特定域上非联合资源的已有用户，不因该域引入对联合环境的支持而受影响。验证部分地由接点服务器处理，接点服务器又可能调用独立的信托代理部件。接点服务器的使用，使对现有域的基础结构的影响，降至最小。例如，可以配置接点服务器，使所有后端或传统应用程序和该域上的系统将要处理的非联合请求通过。
接点服务器可以选择调用基于HTTP的验证方法，如基本验证、基于形式的验证、或某些其他验证方法。接点服务器还通过识别用户作为验证证明而递交的断言，如SAML验证断言，来支持联合的信托域，其中，该断言已经在各企业信托域间穿过。接点服务器可以调用信托代理，信托代理又可以调用它的安全令牌服务，以证实验证凭证/安全令牌。
web服务或其他应用程序的验证，包括和用户验证相同的过程。来自web服务的请求，载运着包含验证断言的安全令牌，而该安全令牌应由信托代理/安全令牌服务，按与用户递交的令牌相同的方式加以证实。来自web服务的请求，经常随该请求载运着该令牌，因为web服务已经发现，在UDDI的通告中，被请求的服务要求何种验证断言/安全令牌。
现在参考图4，这是方框图，画出支持联合的单次开始指令操作的联合环境。用户400通过客户装置和适当的客户应用程序，如浏览器，希望接入由企业/域410提供的web服务，该企业/域410支持起联合环境内联合域作用的数据处理系统。域410支持接点服务器412和信托代理414；同样，域420支持接点服务器422和信托代理424，而域430支持接点服务器432和信托代理434。如上所述，信托代理信赖信托经纪人450的帮助。附加的域和信托代理，可以加入该联合环境。图4说明域410和域420之间的联合单次开始指令操作；类似的操作可以在域410和域430之间发生。
用户对域410完成验证操作；该验证操作由接点服务器412处理。该验证操作在用户请求接入某些要求验证标识的资源时被触发，例如，为了接入控制的目的，或为了标注姓名的目的，要求验证标识。接点服务器412可以调用传统的验证服务，或者，调用信托代理414来证实用户递交的验证凭证。在用户的联合对话这一段时间，域410成为该用户的原籍域。
在随后的某些时间，用户在联合体伙伴上，例如也支持联合域的企业420上，启动某一业务，从而触发联合的单次开始指令操作。例如，用户可以在域420上启动一新的业务，或者，该用户原先的业务可能级联为一项或多项其他域的附加业务。作为另一个例子，该用户可以经过接点服务器412，例如通过选择在域410内作主的web页上专门的链路，或通过请求在域410内作主的入口页，但该入口页显示由域420作主的资源，据此向域410内的资源调用联合的单次开始指令操作。接点服务器412向信托代理414发送请求，请求为用户产生联合的单次开始指令令牌，该联合的单次开始指令令牌被格式化，能使域420理解或信托。信托代理414把该令牌发回接点服务器412，后者把该令牌发送至域内的接点服务器422。对域420的用户，域410起发出方的作用，域420起信赖方的作用。用户的令牌随用户的请求传送至域420；该令牌可以用HTTP再引导，经过用户的浏览器发送，或者，可以以信托代理414提供的令牌中标识的用户名义，通过直接调用接点服务器422的请求(在HTTP上或HTTP上的SOAP)，发送该令牌。
接点服务器422接收与联合的单次开始指令令牌一起的请求，并调用信托代理424。信托代理424接收该联合的单次开始指令令牌、证实该令牌、和假定该令牌有效并被信托，于是为该用户产生本地有效的令牌。信托代理424把该本地有效的令牌发回接点服务器422，后者在域420内为该用户建立对话。如有必要，接点服务器422能够在另一个联合伙伴上启动联合的单次开始指令。
在域420上，由信托代理424处理令牌的证实，可能要借助安全令牌服务的帮助。根据域410递交的令牌类型，安全令牌服务可能需要接入域420上的用户注册表。例如，域420可以提供二进制令牌，该令牌包含需要被域420上用户注册表证实的用户名及口令。因此，在本例中，企业简单地证实来自联合伙伴的安全令牌。域410与域420间的信托关系，保证域420能理解并信托域410以用户名义递交的安全令牌。
联合的单次开始指令，不仅要求证实以用户名义递交信赖域的安全令牌，而且还要根据包含在安全令牌中的信息，确定信赖域上本地证实的用户标识符。直接信托关系和要求建立该关系的业务协定的一个结果，在于至少发出域或信赖域的一方，或两方，应了解如何把发出域提供的信息，转换为信赖域上有效的标识符。在上述简要的例子中，假定发出域即域410，能够把在域420中有效的标识符提供给该信赖域，即域420。在这种情形下，信赖域不必调用任何标识映射功能。域420上的信托代理424将为该用户产生安全令牌，该令牌将“证明”该用户。接受的令牌类型、要求在令牌上的签名、以及其他要求，全部作为联合体的业务协定的一部分，预先建立。调节标识符转换的规则和算法，也作为联合体的业务协定的一部分，预先建立。在两个加入者之间有直接信托关系的情形，标识符转换算法对该双方应已经建立，且不应与该联合体中任何其他方相关联。
但是，下面的情形是不常有的，即发出域了解如何把用户从域410的本地标识符映射成域420的本地标识符。在一些情形中，信赖域了解如何实施这种映射，而在别的情形下，两方的任一方都不了解如何实施这种转换，此时，需要调用第三方信托经纪人。换而言之，在由经纪人安排信托关系的情形，发出和信赖域彼此没有直接信托关系。但是，它们可以与信托经纪人，如信托经纪人450有直接的信托关系。标识符映射规则和算法，应作为这种关系的一部分已经建立，同时，在经纪人安排的信托关系要求帮助标识符转换时，信托经纪人将使用这一信息。
域420接收域420的接点服务器422发出的令牌，接点服务器422调用信托代理424来证实该令牌并执行标识映射。在这种情形中，因为信托代理424不能把该用户从域410的本地标识符映射至域420的本地标识符，信托代理424调用信托经纪人450，信托经纪人450证实该令牌并执行标识符映射。对该用户获得本地标识符之后，信托代理424可能通过它的安全令牌服务，产生域420的后端应用程序要求的任何本地令牌，例如，为有利于从接点服务器到应用程序服务器的单次开始指令，可能要求Kerberos令牌。在获得本地有效令牌后，如有要求，该接点服务器能为用户建立本地对话。该接点服务器还将处理用户请求的粗粒特许，还把该核准的请求转发至域420内适当的应用程序服务器。
当用户注销或结束指令时，用户的对话终止。当用户注销与他们的原籍域的对话时，原籍域随后通知所有信赖域，就是原籍域曾经向之发出安全令牌的那些域，并在这些域上调用用户注销。如果任何一个这些信赖域又对同一用户作为发出域，那么，它们还按级联方式，把用户注销请求通知所有它们的信赖域。每一域上的信托代理负责把用户注销请求通知所有信赖域，并且，作为该过程的一部分，信托代理可以调用信托经纪人。
借助本发明上面提供的详细说明，本发明的优点是明显的。现有技术的方案，是把域的安全服务组织成多个层次，该方案要求各域有牢固的信托关系和固有的可兼容技术。其他的途径则把统一的格式强加在验证断言上，或者不允许验证断言的传递，有时则传递已验证标识，从该验证标识来建立本地断言。
在本发明的各优点中，信托代理能使给定域中已有的安全服务，与其它域建立信托关系，无需同意同一信托根或使用同一信托建立技术。因此，本发明的联合体系结构，提供一种松弛的实体耦合。原籍域管理验证，而每一域管理只在它本身注册的用户的验证。每一域自由地接受、拒绝、或修改任何其他域关于用户标识和属性的语句。信赖域信赖发出域(最终是原籍域)关于标识和属性的断言，又，每一域能够实施任何验证协议，而为了让给定域域加入联合体，不必修改该域内的应用程序使之实现先前不支持的协议。联合体不要求特定的信托模型；一组实体能够形成一联合体，该联合体承认加入的实体早已建立的信托模型。断言转换只出现在信托代理和/或信托经纪人上；联合体的体系结构的作用，是作为能对现有传统系统影响最小的前端基础结构。
联合体能使用户按单次开始指令方式，无缝隙地横越给定联合体内不同的位置。因为联合体加入者之间建立的信托关系，一个加入者能验证一用户，然后作为该用户的发出方。其他联合体伙伴成为信赖方，因而它们信赖发出方提供的关于用户的信息，不直接牵连用户。
重要的是要指出，虽然本发明已就完全有效的数据处理系统作了说明，但本领域的普通熟练人员应当明白，本发明的过程能以指令形式分布于计算机可读媒体和各种其他形式中，不管实际用于完成此分布的、承载信号的媒体的特定类型如何。计算机可读媒体的例子，包括的媒体如EPROM、ROM、磁带、纸、软盘、硬盘驱动器、RAM、和CD-ROM，以及传输型媒体，如数字的和模拟的通信链路。
方法，一般想象为导致预定结果的、自洽的步骤序列。这些步骤要求物理量的物理操纵。通常，虽然不是必需，这些量取电信号的或磁信号的形式，能存储、传送、组合、比较、及别的处理。在时间上把这些信号称为比特、数值、参量、项、单元、对象、符号、字符、术语(terms)、数字等等，是方便的，主要是便于公共使用。但是，应当指出，所有这些术语和类似的术语，是与适当的物理量相联系的，且仅仅是方便于标记这些量。
已经给出的本发明说明，为的是演示的目的，而不企图穷举或限制已公开的实施例。许多修改和变化，对本领域的普通熟练人员是显而易见的。选择这些实施例，是为了阐明本发明的原理及它的实际应用，和使本领域的其他普通熟练人员能了解本发明，以便用各种修改来实施各种实施例，使之适合于其他经过考虑的使用。
权利要求
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/06GK1514569SQ200310123199
公开日2004年7月21日 申请日期2003年12月23日 优先权日2002年12月31日
发明者乔治·R·布莱克利三世, 黑泽尔·M·辛顿, 安索尼·J·纳达林, 阿扎穆·A·韦斯利, A 韦斯利, J 纳达林, M 辛顿, 乔治 R 布莱克利三世 申请人:国际商业机器公司