统一身份认证服务 - 关于单点登陆

Web Service Case Study: 统一身份认证服务

本文是Web Service Case Study系列文章的第四篇。在这篇文章中，我将围绕一个多应用环境下统一认证服务组件的架构展开讨论，探讨如何利用Web服务所带来的好处，实现跨平台跨应用的统一身份识别和权限认证。同时将其拓展到多种应用模式中去，包括Internet公用服务、行业电子商务环境统一认证以及企业内部应用集成等。

以下描述中使用的地名、机构名和系统名称纯属虚构，但是是从具体应用中抽象出来的。

General Business是一家生产和销售多种家用电器的跨国企业。General Business一直注重利用新兴的计算机技术来改善和加强公司的自动化管理。多年来，尾随各种技术的发展，General Business应业务的需要，实施和部署了企业资源规划(ERP)、客户关系管理(CRM)、供应链管理(SCM)以及企业门户(Enterprise Portal)等多种商业应用，这些商业应用分别解决了企业在不同方面的需求，起到了相当的商业成效。然而，随着业务和技术的发展，以自包含的"�/盒" 系统各自存在、各自为政的自治系统的状况无法再维持下去了，商业管理需要整合各个系统的信息，实现跨越所有系统的整合管理，同时将企业内的管理信息流与企业外的管理信息流相结合以实现高反应效率的企业间的电子商务。这一需求就需要由EAI和B2Bi的技术来实施并满足。

General Business的IT部门已经决定使用Web Services技术架构作为其整个企业集团内部进行EAI和B2Bi的基础框架技术。然而，在设计实施的时候，他们发现，尽管Web Services技术在实现不同系统不同平台之间的对接方面能够大大简化代码，但是，每个应用系统都有其自身的用户系统和认证方式，程序员在为某个应用系统编写接入其它应用系统的程序代码的时候，常常为了用户认证大伤脑筋：1) 让最终用户频繁登录? 似乎是一个让用户很难接受的解决方案。2) 在代码中内置用户名和密码? 代码需要随用户和密码的变化经常维护，同时在很多场合下，用户名和密码对于程序员来说可能是不可见的。

如何解决这一问题呢？经过讨论，General Business决定开发一个统一身份认证服务，以解决这一应用集成中碰到的用户认证的问题。这个服务需要达到以下功能和目标：

支持Web Services技术框架，使得在对各个应用系统实施基于Web Services的应用集成(EAI/B2Bi)的时候能够使用这个统一身份认证服务进行身份认证。

方便使用，能够尽可能地利用现有系统的身份认证模块以及现有的用户设置和权限设置，尽量保护现有的投资，减少重新的用户设置和权限设置的费用，同时避免对现有系统进行大规模的修改。

具有良好的扩展性和可集成性，不仅能支持现有的应用系统及其现有的用户系统，当有新的企业应用被部署或开发的时候，这个统一身份认证服务可以作为它的身份认证模块的形式工作，也就是说，新的企业应用可以不自带用户系统，可以通过集成该服务的形式来实现等价的功能。

应当具备灵活和方便的使用模式，使用者可以通过多种方式自由地使用该统一身份认证服务。

根据这个统一身份认证服务的目标和初步的功能定义，我们将这个服务设计如下：



该服务主要需要具备三项功能：

用户注册：用户在统一身份认证服务中注册帐号，以后这个帐号可以在所有使用统一身份认证服务的应用系统中使用。

帐号关联：如果用户之前已经在相关的应用系统中拥有帐号，同时也已经设置了相应的权限，那么用户能够将这些应用系统的帐号与统一身份认证服务的帐号进行关联，使得用户登录统一身份认证服务之后，就能够自动使用相关的应用系统用户来访问应用系统。

用户认证：为应用系统提供用户身份认证，兼顾两个应用方式：

应用系统使用统一身份认证服务作为它的用户系统，用户与应用系统进行交互，进行登录操作，应用系统将用户提供的用户名/密码等转发给统一身份认证服务以检验其是否通过授权。

用户首先登录统一身份认证服务，并获取权限令牌，以后可以使用这个权限令牌访问其他的应用系统，应用系统接收该权限令牌时应当与统一身份认证服务进行交互，以检验访问的合法性。

按照以上的功能描述，我们可以认为统一身份认证服务中需要考虑的实体可以使用下图来表示：



用户(User)：即统一身份认证服务的用户；

帐号(Account)：应用系统的帐号，与统一身份认证服务的用户相关联，一个用户可以关联多个帐号；

应用系统(Application)：使用统一身份认证服务的应用系统；

会话(Session)：当用户登录统一身份认证服务后，即创建了一个活跃的会话，并获得会话的认证令牌，在这个会话中，用户可以使用会话的认证令牌访问各种应用系统。

用户注册(包括用户更新注册信息)的流程可以使用下图来表示。其中主要包含了两个流程：新用户注册和用户更新注册信息。



新用户注册：

用户向统一身份认证服务发出新用户注册请求

服务查询用户注册库，如果该用户可以注册(没有同名ID等违背约束条件的情况发生)，那么将该用户的信息保存到用户注册库中。

当保存完毕后，统一身份认证服务响应用户，注册完成。

用户更新注册信息：

用户向统一身份认证服务发出用户注册信息更新请求。

服务查询用户注册库，如果该用户信息可以更新(有该ID存在，同时提供的密码也是正确的等等)，那么将该用户的信息将在用户注册库中更新。

当保存完毕后，统一身份认证服务响应用户，更新完成。

帐号关联操作可以使用下图来表示。图中仅包含一个登记新的帐号关联的操作，相关的修改、删除操作被省略了，有兴趣的读者可以自行给出。



登记新的帐号关联：

用户向统一身份认证服务发出帐号关联注册请求，用户提供了应用系统的标识A，同时提供了可以在该应用系统中使用的用户信息(可能包含用户名和密码等)。

服务首先向该应用系统A征询，用户信息是否合法。如果合法则响应服务。

如果收到合法响应，那么服务就将这个帐号关联注册信息保存到用户注册库中，以后该用户登录统一身份认证服务之后，就能够使用相应的应用系统A。

当注册库完成保存操作后，统一身份认证服务响应用户，注册完成。

统一身份认证服务的一个基本应用模式是以应用系统的身份认证组件的形式工作，在这个应用模式下，主导地位的是应用系统。在这种情况下，应用系统自身没有用户系统，因此本模式下涉及的帐号一定是统一身份认证服务的用户帐号。



流程描述如下：(仅描述正常流程)

用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等)登陆应用系统A

应用系统A，将用户名和密码连同自己的标识(应用系统A的标识)一起转发给统一认证服务，要求统一认证服务完成登录操作。

统一认证服务核查自己的应用系统注册库(使用UDDI Registry，我将在后面解释为什么使用UDDI Registry)看看应用系统A是否已经是统一认证服务的用户系统。同时在用户注册库中核查由应用系统A转发过来的用户名和密码。

待核查完毕后，统一认证服务响应应用系统A，登录完成。

应用系统A创建一个系统会话(Session，系统A自己的机制)，并将应用系统A自己的权限令牌返回给用户，以后用户端可以通过这个权限令牌持续访问应用系统A，直至登出系统或是会话超时。

统一认证模式是以统一身份认证服务为核心的服务使用模式。用户登录统一身份认证服务后，即可使用所有支持统一身份认证服务的应用系统。



流程描述如下：(仅描述正常流程)

用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等)登陆统一认证服务；

统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户；

用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统；

该应用系统将访问认证令牌传入统一身份认证服务，认证访问认证令牌的有效性；

统一身份认证服务确认认证令牌的有效性；

应用系统接收访问，并返回访问结果，如果需要提高访问效率的话，应用系统可选择返回其自身的认证令牌已使得用户之后可以使用这个私有令牌持续访问。

此外，关于访问认证令牌的失效，有两个策略，一个是由用户主动发起声明，声明其拥有的访问认证令牌不再有效，这类似注销的操作，另一个是用户一段时间内没有使用这个认证令牌，认证令牌自动失效，这类似超时的处理。

在Internet应用环境下，安全性和信任的重要性是显而易见的，对于商用系统而言，避免非法访问和入侵是他所需要考虑的几个重要问题之一，没有比商用数据丢失或是商用系统被违规使用更糟糕的了。

在信任代理模式下，一个组织可以为他所有需要提供安全信任保障的应用系统设置一个统一身份认证服务，对这些应用系统的访问全部由统一身份认证服务代理。



流程描述如下：(仅描述正常流程)

用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等)登陆统一认证服务；

统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户；

用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统，不过用户并不将请求消息直接交给应用系统，而是传给统一身份认证服务，在消息中标识了最终的应用系统的ID。

统一认证服务访问应用系统注册库(UDDI Registry)，获取了应用系统的访问入口(统一认证服务可以将这个访问入口缓存在本地，以减少以后与应用系统注册库的交互次数)。并确认这个应用系统的确是支持统一身份认证服务的；

统一认证服务将请求消息转发给指定的应用系统，如果该应用系统使用自己的用户系统的话，那么该消息应当包含了预先定义好的相关联的用户名和密码等。

应用系统将请求结果返回给统一认证服务，最后统一认证服务将响应消息返回给用户，完成调用。

在该模式下，所有应用系统仅接收来自统一认证服务的访问请求，这样，解决方案提供商可以将主要的安全方面的投入部署在统一认证服务那端。

由于统一身份认证服务可能被应用的领域包括：

企业内部的各种应用

跨国企业的各个部门或地区分公司的各种应用

行业内各个企业的不同应用

Internet上丰富的应用环境

无论是何种应用环境，都将面对不同的平台、不同的系统和不同的编程环境，要能最大可能地支持所有的平台、系统和编程环境，同时又要确保服务的实现代价保持相对固定，那么目前看来，选择基于规范的Web Services解决方案将是一个不错的选择。

在我们这个基于统一身份识别服务的应用环境中，所有支持统一身份识别服务的应用系统都需要被注册在UDDI注册中心中。如果是企业内部的应用环境、跨国企业的应用环境或是行业内多个企业组成的联合行业应用环境，那么应当使用Private UDDI Registry(私有UDDI注册中心)，如果是Internet应用环境的话，则可以考虑使用Public UDDI Registry(公共UDDI注册中心)。

所有支持统一身份识别服务的应用系统以UDDI数据实体 businessService的形式注册在UDDI注册中心中，他们都被分配了一个UUID(唯一标识符)，这个UUID可以在用户定义关联帐号或是使用统一身份认证服务进行应用系统访问的时候，用于标识相应的应用系统。

businessService是UDDI中的一个关键的数据结构，businessService将一系列有关商业流程或分类目录的Web Service的描述组合到一起。businessService和下面要提到的bindingTemplate一起构成了技术信息。其中，一个可能的商业流程的例子是一组相关的Web 服务信息，包括采购服务、运输服务和其它的高层商业流程。这些服务都将是提供这些商业流程服务的商业实体所需要注册的Web服务。

这些businessService的信息集合可以再次加以分类，使Web应用服务的描述可以按不同的行业、产品、服务类型或是地域划分来进行。分类的方法的机制与businessEntity是类似的。

对于每一个businessService，存在一个或多个Web 服务的技术描述bindingTemplate。这些技术描述包括应用程序连接远程Web 服务并与之通讯所必须的信息。这些信息包括Web应用服务的入口地址、应用服务宿主和调用服务前必须调用的附加应用服务等。另外，通过附加的特性还可以实现一些复杂的路由选择，诸如负载平衡等。

当统一身份认证服务得到用户提交的应用系统的UUID之后，它应当使用这个 UUID查询UDDI注册中心，以获得这个应用系统的完整服务描述(businessService结构)，随后统一身份认证服务就可以得到这个应用系统的访问入口，并实施访问。当应用系统修改了访问入口或是某些关键的技术信息之后，它可以在UDDI注册中心中更新自己的信息，这样，当统一身份认证服务下一次实施关联的查询时，就可以获取新的应用系统的访问信息，这样一种方式可以无需修改代码实现动态绑定。

为了提高服务的响应效率，减少与UDDI注册中心的交互次数，统一身份认证服务也可以选择将应用系统的UDDI描述缓存在本地，当用户访问相关的应用系统时可以直接使用缓存的数据进行后继操作。

细心的读者应当已经发现，缓存操作与前面描述的应用系统自更新技术信息的操作可能会发生冲突，缓存的信息与UDDI中的信息可能发生版本不一致的情况，此时后继的应用系统访问操作可能会发生错误，当这种错误发生后，统一身份认证服务应当选择重新缓存相关的UDDI中的应用系统技术信息以恢复数据的一致性。

根据前面几个部分的描述，我们可以归纳出统一身份认证服务的对外接口，接口基本上由两部分组成：

用户Profile维护：包括用户注册，关联帐号定义，帐号信息维护等。

认证服务：包括用户登录/注销，认证令牌认证，访问转发，访问代理等等。

用户Profile维护的XML Schema定义如下：

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="user" type="userType"> <xs:annotation> <xs:documentation>USAS User Definition</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="userType"> <xs:sequence> <xs:element name="userID" type="emailType"/> <xs:element name="credential" type="xs:base64Binary"/> <xs:element name="personalInfo"> <xs:complexType> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="alternativeEmail" type="emailType"/> <xs:element name="phone" type="xs:string"/> <xs:element name="fax" type="xs:string"/> <xs:element name="company" type="xs:string"/> <xs:element name="department" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="associatedAccounts"> <xs:complexType> <xs:sequence> <xs:element name="associatedAccount" type="accountType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:simpleType name="emailType"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:complexType name="accountType"> <xs:sequence> <xs:element name="applicationID" type="xs:string"/> <xs:element name="accountID" type="xs:string"/> <xs:element name="credential" type="xs:base64Binary"/> </xs:sequence> </xs:complexType> <xs:element name="save_user"> <xs:complexType> <xs:sequence> <xs:element ref="user"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="delete_user"> <xs:complexType> <xs:sequence> <xs:element name="userID" type="emailType"/> <xs:element name="credential" type="xs:base64Binary"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

从这个XML Schema文档中，我们不难看出，我们可以使用两个API来维护用户帐号：save_user和delete_user。其中save_user用于新建帐号和更新帐号。当统一身份认证服务接受到save_user API调用时，如果发现服务的用户库中并没有相应的userID，那么就是新建帐号，否则如果发现服务的用户库中有相应的userID，那么就是更新帐号。而delete_user则用于删除帐号，当然前提是服务的用户库中有相应的userID，否则就是非法调用。

在delete_user API调用中，顶级元素是delete_user，delete_user有两个子元素userID和credential，userID是用户的标识，其类型是email地址，使用email地址作为用户标识也是目前非专用用户系统比较通用的一种方式，原因非常简单，email地址不同的人肯定不会重复，这样就避免了帐号无法成功注册的情况。而credential则是对应的授权信息，可能是用户密码，数字签名等等形式。

对于save_user API调用而言，其顶级元素是save_user，而save_user有一个子元素user，user元素完整定义了一个用户帐号的详细信息。除了 userID和credential子元素外，user元素还包括两个复合元素personalInfo和associatedAccounts。 personalInfo元素描述了用户的个人信息，包括：name(姓名)、alternativeEmail(可替换的email，userID是其使用的主要email)、phone(电话)、fax(传真)、company(所属公司)、department(所属部门)。而 associatedAccounts则定义了多个关联帐号，每个关联帐号的定义(associatedAccount)由三个元素组成： applicationID(应用系统的UDDI UUID标识)、accountID(应用系统中的用户ID)、credential(应用系统中相关用户ID对应的授权信息，可能是密码、数字签名等)。

认证服务API主要包含sign_in、check_authToken、discard_authToken等API调用。

sign_in消息用于登录统一身份认证服务，并获得认证令牌。认证令牌是登录之后访问统一身份认证服务以及使用应用系统所必须的不可缺少的必要参数。

sign_in API调用的消息语法形如：

<sign_in> <userID> "someLoginName" </userID> <credential> "someCredential" </credential> </sign_in>

其中userID是用户的标识，其类型是email地址，使用email地址作为用户标识也是目前非专用用户系统比较通用的一种方式，原因非常简单，email地址不同的人肯定不会重复，这样就避免了帐号无法成功注册的情况。而credential则是对应的授权信息，可能是用户密码，数字签名等等形式。

当sign_in成功调用后，统一身份认证服务需要返回认证令牌以供此后的授权访问。authToken消息是sign_in消息的响应消息。它返回认证信息authInfo，认证信息将用于后续的调用。

authToken消息的语法形如：

<authToken> <authInfo>some opaque token value</authInfo> </authToken>

authToken消息包含单个 authInfo 元素，该元素包含一个访问令牌，令牌将在所有后继API消息调用中被使用。作为一个对sign_in消息的同步响应，这个消息返回时始终使用SSL加密。

当应用系统收到用户传来的认证令牌后，可以选择到统一身份认证服务验证该认证令牌的合法性，并依据结果判断是否接受用户的访问请求。这个验证认证令牌的API函数是check_authToken。

check_authToken消息的语法形如：

<check_authToken> <authInfo>some opaque token value</authInfo> </check_authToken>

当认证令牌合法，将返回valid，如果认证令牌不合法或者已经失效，则返回invalid。

当用户完成了它所需的各种操作，那么它应当从统一身份认证服务中注销，以避免获取的认证令牌被非法滥用。此时它可以使用discard_authToken 函数。discard_authToken API调用用来通知统一身份认证服务可以丢弃某个认证令牌，也就是终止当前的会话。以后一切使用该认证令牌的调用全部会被拒绝。

discard_authToken的语法形如:

<discard_authToken> <authInfo/> </discard_authToken>

我们先前已经提到，统一身份认证服务在得到用户传入的应用系统UUID之后，需要去查询UDDI注册中心以获得相关应用系统的技术信息以被之后的服务调用。这个查询API具体来说，就是get_serviceDetail函数。

get_serviceDetail消息用来请求获取已知的businessService结构的完整信息。

语法形如:

<get_serviceDetail generic="2.0" xmlns="urn:uddi-org:api_v2" > <serviceKey/> [<serviceKey/> ...] </get_serviceDetail>

其中serviceKey用于表示一个或多个用来代表已知businessService数据特定实例的uuid_key值。该函数若成功调用，则返回一个 serviceDetail消息，其成功匹配了一个或多个serviceKey值。如果传入的是多个serviceKey 值，其结果将根据传入的值的次序依次返回。如果匹配到的记录数量过多，操作入口站点将对返回值执行截断操作。如果该情况发生，serviceDetail 将包含一个truncated 属性，且该属性值为true。

serviceDetail消息返回一个或多个完整的businessService结构，作为对get_serviceDetail查询消息的响应。

语法形如:

<serviceDetail generic="2.0" operator="uddi.sourceOperator" [truncated="false"] xmlns="urn:uddi-org:api_v2"> <businessService businessKey="urn:uuid_key" serviceKey="urn:uuid_key"> ... </businessService> [<businessService/>...] </serviceDetail>

需要注意的是， businessKey值在该消息中被表述，这是因为子元素的父容器(serviceDetail元素)并不提供到父businessEntity结构的键引用。其中businessService用于表示一个或多个的完整的在UDDI注册中心中的businessService结构。这些结构是由 get_serviceDetail消息所指定的。

通过之前的阐述，相信大家对于身份认证组建模式和统一认证模式的实现已经没有过多的疑问了。在本节，我将结合之前描述的体系和API设计，针对信任代理模式，通过一个具体的例子演示统一身份认证服务的使用方法。

这个例子的应用场景是一个生产和销售电子器件的企业，它使用了ERP系统管理其自身的生产流程和库存、使用SCM系统管理与供应商之间的供应流程，同时使用 CRM系统管理客户、分销等。在最初，各个系统分别使用自己的用户系统，公司员工在使用这三个系统，并在三个系统之间切换的时候非常烦恼，不得记住三套用户并多次重复登录，工作效率也有所影响。随着更多的企业应用被一一部署，企业IT部门认为如果能够将用户系统统一的话，将会显著地提高员工的工作效率。同时企业IT部分选定了信任代理模式来实施统一身份认证服务。这样所有的授权访问能够置于统一身份认证服务的监控之下，便于企业管理部门对访问的监控和审计。

下面我用使用SOAP消息的形式来演示用户访问SCM系统的流程。

用户使用在统一认证服务注册的用户名和密码登陆统一认证服务，用户名是"UATest"，而密码则使用了Base64编码表示的HASH值；

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Header> <ac:universalauthentication xmlns:ac="http://example.org/universalauthentication"> <sign_in> <userID>UATest</userID> <credential>EH67ij45DGg5</credential> </sign_in> </ac:universalauthentication> </env:Header> <env:Body> ............ </env:Body> </env:Envelope>

统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户，在SOAP消息中，访问认证令牌使用Base64编码；

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Header> <ac:universalauthentication xmlns:ac="http://example.org/universalauthentication"> <authToken> <authInfo>K8nfd858a3gJhk877fKLJSDH</authInfo> </authToken> </ac:universalauthentication> </env:Header> <env:Body> ............ </env:Body> </env:Envelope>

用户使用这个访问认证令牌访问SCM系统，不过用户并不将请求消息直接交给SCM应用系统，而是传给统一身份认证服务，在消息中标识了SCM系统的ID："C1ACF26D-9672-4404-9D70-39B756E62AB4"。

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Header> <ac:universalauthentication xmlns:ac="http://example.org/universalauthentication"> <authToken> <authInfo>K8nfd858a3gJhk877fKLJSDH</authInfo> </authToken> <accessService> <serviceKey>C1ACF26D-9672-4404-9D70-39B756E62AB4</serviceKey> </accessService> </ac:universalauthentication> </env:Header> <env:Body> ............ </env:Body> </env:Envelope>

统一认证服务访问应用系统注册库(UDDI Registry)，获取了SCM系统的访问入口(统一认证服务可以将这个访问入口缓存在本地，以减少以后与应用系统注册库的交互次数)。并确认这个SCM系统的确是支持统一身份认证服务的；

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> <get_serviceDetail generic="2.0" xmlns="urn:uddi-org:api_v2" > <serviceKey>C1ACF26D-9672-4404-9D70-39B756E62AB4</serviceKey> </get_serviceDetail> </env:Body> </env:Envelope>

假设返回消息中的serviceDetail所包含的bindingTemplate结构中所指明的服务访问入口accessPoint是"http://leo/scmentry/"的。

统一认证服务将请求消息转发给指定的SCM应用系统，如果该SCM系统使用自己的用户系统的话，那么该消息应当包含了预先定义好的相关联的用户名和密码等。

SCM系统将请求结果返回给统一认证服务，最后统一认证服务将响应消息返回给用户，完成调用。

目前，与统一身份认证服务相关的一些工作已经在业界巨头之间有效开展：

Passport 是Microsoft提供的一个公共Web Service，用于同一的身份验证服务。使用者可以在http://www.passport.com/申请使用Passport服务。同时对于开发人员而言，Microsoft在MSDN中分别提供了SDK下载(http: //msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url= /msdn-files/027/001/885/msdncompositedoc.xml)和在线文档(http: //msdn.microsoft.com/library/default.asp?url=/library/en-us/ppsdk14/defeula2.asp? frame=true)。Passport是目前最大的几个投入使用的Web Service之一，在Microsoft的努力下已经慢慢地脱离了使用者对Microsoft .NET安全性的抱怨，并为My .NET Services的推广奠定了扎实的基础。

其中，Microsoft和Arcot通过合作，将Microsoft .NET Passport与Arcot TransFort支付认证平台进行了集成。发行信用卡的银行支持在线认证，例如通过Visa和MasterCard的安全支付应用为Internet购买提供校验，而通过这一合作计划，信用卡的持有人就能够将他们的个人.NET Passport帐号与安全的TransFort在线信用卡认证无缝集成在一起。信用卡持有人可以使用简单而方便的Passport登录和使用界面来登录、购物以及认证在线购买。

IBM、Microsoft和VeriSign在4月11日，共同发布了新的Web服务安全规范WS-Security，这个规范之前仅仅是由Microsoft提出的，IBM和Verisign加入后，在这个规范的基础上制订了当前的版本，同时宣布了在Web服务安全方面合作的发展路线，称为"Security in Web Services World"。

Web 服务安全性(WS-Security)通过消息完整性、消息机密性和单独消息认证提供保护质量对 SOAP 消息传递的增强。这些机制可以用于提供多种安全性模型和加密技术。WS-Security 还提供关联安全性令牌和消息的通用机制。WS-Security 不需要特定类型的安全性令牌。它在设计上就是可扩展的（例如支持多安全性令牌格式）。举例来说，客户机可能会提供身份证明和他们有特定商业认证的证明。另外，WS-Security 还描述如何对二进制安全性令牌编码。此规范特别描述如何对 X.509 证书和 Kerberos 票据编码以及如何加入难于理解的加密密钥。它还包括可以用于进一步描述消息中包含的凭证特征的扩展性机制。

Microsoft 于2002年6月6日宣布了一个新的Windows技术，代码名为"TrustBridge"。TrustBridge将使得企业能够"在应用和组织之间交换用户标识信息"。关于TrustBeidge，Microsoft在技术和产品方面的动作主要包括：[1] TrustBridge将使用Kerboros 5.0，这是按照最近的WS-Security的发展计划而定的。[2] TrustBridge将和Microsoft Active Directory服务进行集成，以识别和共享用户标识。[3] 最今年的后半段，Visual Studio .NET将以此升级以支持数字签名和SOAP消息加密。[4] 明年Microsoft Passport将支持SOAP消息并实现WS-Security和Kerberos。[5] 明年，.NET Server将投入使用，同时将通过Active Directory和IIS来提供Passport。

作为 Passport的对立方，以SUN为主导的Liberty Alliance Project于2002年7月15日发布了它的第一个规范：开放联合网络身份验证规范。这是Liberty Alliance Project为提供开放联合网络身份验证解决方案而迈出的第一步。这个1.0规范针对为提供优化的帐号关联以及简单的登录功能而所需要的系统间的互操作性。通过这一规范，用户能够决定是否要将多个标识提供者所提供的帐号进行关联，同时使得帐号的使用对于消费者和商业实体都能更为方便，以充分显现成长中的 Web Services空间。Liberty Alliance Project提供了规范的下载。

统一身份认证服务资源

Microsoft .NET Passport, Microsoft的统一身份认证服务。

Liberty Alliance Project, 以Sun为主倡导的统一身份认证标准化组织。

Web Service 技术/评论网站

SimplePage.UDDI-China.ORG, Web服务中文资源。

UDDI-China.ORG, 以UDDI为主的Web服务技术网站。

WebServices.ORG, Web服务的综合类技术网站。

IBM developerWorks/Web Service Zone, IBM的Web服务技术资源中心

MSDN Online Web Services Developer Resources, Microsoft的Web服务的开发者资源网站

ITPapers/Web Service, ITPapers的Web服务评论文章

解决开放式应用交互和集成的Web Services系列技术标准规范

WS-Security规范, Microsoft, 2001

WS-License规范, Microsoft, 2001

UDDI执行白皮书, UDDI-China.org, UDDI.org

UDDI技术白皮书, UDDI-China.org, UDDI.org

UDDI程序员API规范, UDDI-China.org, UDDI.org

UDDI数据结构参考, UDDI-China.org, UDDI.org

Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000

SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000

XML Schema Part 0: Primer, W3C, 2 May 2001

Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000

关于作者 柴晓路: 老柴，呵呵我们家族 人才辈出呀！