Web Service Case Study: 统一身份认证服务 柴晓路 ([email protected])CIO, DealEasy
简介： 本文是Web Service Case Study 系列文章的第四篇。在这篇文章中，我将围绕一个多应用环境下统一认证服务组件的架构展开讨论，探讨如何利用Web 服务所带来的好处，实现跨平台跨应用的统一身份识别和权限认证。同时将其拓展到多种应用模式中去，包括Internet 公用服务、行业电子商务环境统一认证以及企业内部应用集成等。 标记本文！
发布日期： 2002 年 8 月 01 日
级别： 初级
访问情况 135 次浏览
建议: 0 (添加评论)
平均分 （共 1 个评分 ）
应用背景
以下描述中使用的地名、机构名和系统名称纯属虚构，但是是从具体应用中抽象出来的。
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决定开发一个统一身份认证服务，以解决这一应用集成中碰到的用户认证的问题。这个服务需要达到以下功能和目标：
1. 支持Web Services技术框架，使得在对各个应用系统实施基于Web Services 的应用集成(EAI/B2Bi)的时候能够使用这个统一身份认证服务进行身份认证。
2. 方便使用，能够尽可能地利用现有系统的身份认证模块以及现有的用户设置和权限设置，尽量保护现有的投资，减少重新的用户设置和权限设置的费用，同时避免对现有系统进行大规模的修改。
3. 具有良好的扩展性和可集成性，不仅能支持现有的应用系统及其现有的用户系统，当有新的企业应用被部署或开发的时候，这个统一身份认证服务可以作为它的身份认证模块的形式工作，也就是说，新的企业应用可以不自带用户系统，可以通过集成该服务的形式来实现等价的功能。
4. 应当具备灵活和方便的使用模式，使用者可以通过多种方式自由地使用该统一身份认证服务。
回页首
解决方案
根据这个统一身份认证服务的目标和初步的功能定义，我们将这个服务设计如下：
Figure 1. 统一身份认证服务
该服务主要需要具备三项功能：
1. 用户注册：用户在统一身份认证服务中注册帐号，以后这个帐号可以在所有使用统一身份认证服务的应用系统中使用。
2. 帐号关联：如果用户之前已经在相关的应用系统中拥有帐号，同时也已经设置了相应的权限，那么用户能够将这些应用系统的帐号与统一身份认证服务的帐号进行关联，使得用户登录统一身份认证服务之后，就能够自动使用相关的应用系统用户来访问应用系统。
3. 用户认证：为应用系统提供用户身份认证，兼顾两个应用方式：
4.
o 应用系统使用统一身份认证服务作为它的用户系统，用户与应用系
统进行交互，进行登录操作，应用系统将用户提供的用户名/密码
等转发给统一身份认证服务以检验其是否通过授权。
o 用户首先登录统一身份认证服务，并获取权限令牌，以后可以使用
这个权限令牌访问其他的应用系统，应用系统接收该权限令牌时应
当与统一身份认证服务进行交互，以检验访问的合法性。
按照以上的功能描述，我们可以认为统一身份认证服务中需要考虑的实体可以使用下图来表示：
Figure 2. 统一身份认证服务的数据实体
1. 用户(User)：即统一身份认证服务的用户；
2. 帐号(Account)：应用系统的帐号，与统一身份认证服务的用户相关联，一个用户可以关联多个帐号；
3. 应用系统(Application)：使用统一身份认证服务的应用系统；
4. 会话(Session)：当用户登录统一身份认证服务后，即创建了一个活跃的会话，并获得会话的认证令牌，在这个会话中，用户可以使用会话的认证令牌访问各种应用系统。
用户注册
用户注册(包括用户更新注册信息) 的流程可以使用下图来表示。其中主要包含了两个流程：新用户注册和用户更新注册信息。
Figure 3. 用户注册流程
新用户注册：
1. 用户向统一身份认证服务发出新用户注册请求
2. 服务查询用户注册库，如果该用户可以注册(没有同名ID 等违背约束条件的情况发生) ，那么将该用户的信息保存到用户注册库中。
3. 当保存完毕后，统一身份认证服务响应用户，注册完成。
用户更新注册信息：
1. 用户向统一身份认证服务发出用户注册信息更新请求。
2. 服务查询用户注册库，如果该用户信息可以更新(有该ID 存在，同时提供的密码也是正确的等等) ，那么将该用户的信息将在用户注册库中更新。
3. 当保存完毕后，统一身份认证服务响应用户，更新完成。
帐号关联
帐号关联操作可以使用下图来表示。图中仅包含一个登记新的帐号关联的操作，相关的修改、删除操作被省略了，有兴趣的读者可以自行给出。
Figure 4. 用户关联流程
登记新的帐号关联：
1. 用户向统一身份认证服务发出帐号关联注册请求，用户提供了应用系统的标识A ，同时提供了可以在该应用系统中使用的用户信息(可能包含用户名和密码等) 。
2. 服务首先向该应用系统A 征询，用户信息是否合法。如果合法则响应服务。
3. 如果收到合法响应，那么服务就将这个帐号关联注册信息保存到用户注册库中，以后该用户登录统一身份认证服务之后，就能够使用相应的应用系统A 。
4. 当注册库完成保存操作后，统一身份认证服务响应用户，注册完成。 身份认证组件模式
统一身份认证服务的一个基本应用模式是以应用系统的身份认证组件的形式工作，在这个应用模式下，主导地位的是应用系统。在这种情况下，应用系统自身没有用户系统，因此本模式下涉及的帐号一定是统一身份认证服务的用户帐号。
Figure 5. 身份认证组件模式流程
流程描述如下：(仅描述正常流程)
1. 用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等) 登陆应用系统A
2. 应用系统A ，将用户名和密码连同自己的标识(应用系统A 的标识) 一起转发给统一认证服务，要求统一认证服务完成登录操作。
3. 统一认证服务核查自己的应用系统注册库(使用UDDI Registry，我将在后面解释为什么使用UDDI Registry)看看应用系统A 是否已经是统一认证服务的用户系统。同时在用户注册库中核查由应用系统A 转发过来的用户名和密码。
4. 待核查完毕后，统一认证服务响应应用系统A ，登录完成。
5. 应用系统A 创建一个系统会话(Session，系统A 自己的机制) ，并将应用系统A 自己的权限令牌返回给用户，以后用户端可以通过这个权限令牌持续访问应用系统A ，直至登出系统或是会话超时。
统一认证模式
统一认证模式是以统一身份认证服务为核心的服务使用模式。用户登录统一身份认证服务后，即可使用所有支持统一身份认证服务的应用系统。
Figure 6. 统一认证模式流程
流程描述如下：(仅描述正常流程)
1. 用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等) 登陆统一认证服务；
2. 统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户；
3. 用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统；
4. 该应用系统将访问认证令牌传入统一身份认证服务，认证访问认证令牌的有效性；
5. 统一身份认证服务确认认证令牌的有效性；
6. 应用系统接收访问，并返回访问结果，如果需要提高访问效率的话，应用系统可选择返回其自身的认证令牌已使得用户之后可以使用这个私有令牌持续访问。
此外，关于访问认证令牌的失效，有两个策略，一个是由用户主动发起声明，声明其拥有的访问认证令牌不再有效，这类似注销的操作，另一个是用户一段时间内没有使用这个认证令牌，认证令牌自动失效，这类似超时的处理。 信任代理模式
在Internet 应用环境下，安全性和信任的重要性是显而易见的，对于商用系统而言，避免非法访问和入侵是他所需要考虑的几个重要问题之一，没有比商用数据丢失或是商用系统被违规使用更糟糕的了。
在信任代理模式下，一个组织可以为他所有需要提供安全信任保障的应用系统设置一个统一身份认证服务，对这些应用系统的访问全部由统一身份认证服务代理。
Figure 7. 信任代理模式流程
流程描述如下：(仅描述正常流程)
1. 用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等) 登陆统一认证服务；
2. 统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户；
3. 用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统，不过用户并不将请求消息直接交给应用系统，而是传给统一身份认证服务，在消息中标识了最终的应用系统的ID 。
4. 统一认证服务访问应用系统注册库(UDDI Registry)，获取了应用系统的访问入口(统一认证服务可以将这个访问入口缓存在本地，以减少以后与应用系统注册库的交互次数) 。并确认这个应用系统的确是支持统一身份认证服务的；
5. 统一认证服务将请求消息转发给指定的应用系统，如果该应用系统使用自己的用户系统的话，那么该消息应当包含了预先定义好的相关联的用户名和密码等。
6. 应用系统将请求结果返回给统一认证服务，最后统一认证服务将响应消息返回给用户，完成调用。
在该模式下，所有应用系统仅接收来自统一认证服务的访问请求，这样，解决方案提供商可以将主要的安全方面的投入部署在统一认证服务那端。
回页首
使用Web 服务架构
由于统一身份认证服务可能被应用的领域包括：
企业内部的各种应用
跨国企业的各个部门或地区分公司的各种应用
∙ 行业内各个企业的不同应用
∙ Internet 上丰富的应用环境 ∙
无论是何种应用环境，都将面对不同的平台、不同的系统和不同的编程环境，要能最大可能地支持所有的平台、系统和编程环境，同时又要确保服务的实现代价保持相对固定，那么目前看来，选择基于规范的Web Services解决方案将是一个不错的选择。
UDDI 的角色
在我们这个基于统一身份识别服务的应用环境中，所有支持统一身份识别服务的应用系统都需要被注册在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 中的应用系统技术信息以恢复数据的一致性。
Web 服务接口
根据前面几个部分的描述，我们可以归纳出统一身份认证服务的对外接口，接口基本上由两部分组成：
1. 用户Profile 维护：包括用户注册，关联帐号定义，帐号信息维护等。
2. 认证服务：包括用户登录/注销，认证令牌认证，访问转发，访问代理等等。
用户Profile 维护
用户Profile 维护的XML Schema定义如下：
elementFormDefault="qualified" attributeFormDefault="unqualified">
USAS User Definition
type="accountType" minOccurs="0" maxOccurs="unbounded"/>
从这个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调用的消息语法形如：
"someLoginName"
"someCredential"
其中userID 是用户的标识，其类型是email 地址，使用email 地址作为用户标识也是目前非专用用户系统比较通用的一种方式，原因非常简单，email 地址不同的人肯定不会重复，这样就避免了帐号无法成功注册的情况。而credential 则是对应的授权信息，可能是用户密码，数字签名等等形式。
当sign_in成功调用后，统一身份认证服务需要返回认证令牌以供此后的授权访问。authToken 消息是sign_in消息的响应消息。它返回认证信息authInfo ，认证信息将用于后续的调用。
authToken 消息的语法形如：
some opaque token value
authToken 消息包含单个 authInfo 元素，该元素包含一个访问令牌，令牌将在所有后继API 消息调用中被使用。作为一个对sign_in消息的同步响应，这个消息返回时始终使用SSL 加密。
当应用系统收到用户传来的认证令牌后，可以选择到统一身份认证服务验证该认证令牌的合法性，并依据结果判断是否接受用户的访问请求。这个验证认证令牌的API 函数是check_authToken。
check_authToken消息的语法形如：
some opaque token value
当认证令牌合法，将返回valid ，如果认证令牌不合法或者已经失效，则返回invalid 。
当用户完成了它所需的各种操作，那么它应当从统一身份认证服务中注销，以避免获取的认证令牌被非法滥用。此时它可以使用discard_authToken函数。
discard_authToken API 调用用来通知统一身份认证服务可以丢弃某个认证令牌，也就是终止当前的会话。以后一切使用该认证令牌的调用全部会被拒绝。 discard_authToken的语法形如:
查询UDDI 注册中心
我们先前已经提到，统一身份认证服务在得到用户传入的应用系统UUID 之后，需要去查询UDDI 注册中心以获得相关应用系统的技术信息以被之后的服务调用。这个查询API 具体来说，就是get_serviceDetail函数。
get_serviceDetail消息用来请求获取已知的businessService 结构的完整信息。 语法形如:
[ ...]
其中serviceKey 用于表示一个或多个用来代表已知businessService 数据特定实例的uuid_key值。该函数若成功调用，则返回一个serviceDetail 消息，其成功匹配了一个或多个serviceKey 值。如果传入的是多个serviceKey 值，其结果将根据传入的值的次序依次返回。如果匹配到的记录数量过多，操作入口站点将对返回值执行截断操作。如果该情况发生，serviceDetail 将包含一个truncated 属性，且该属性值为true 。
serviceDetail 消息返回一个或多个完整的businessService 结构，作为对get_serviceDetail查询消息的响应。
语法形如:
[truncated="false"] xmlns="urn:uddi-org:api_v2">
serviceKey="urn:uuid_key">
...
[...]
需要注意的是，businessKey 值在该消息中被表述，这是因为子元素的父容器(serviceDetail元素) 并不提供到父businessEntity 结构的键引用。其中businessService 用于表示一个或多个的完整的在UDDI 注册中心中的
businessService 结构。这些结构是由get_serviceDetail消息所指定的。 信任代理模式示例
通过之前的阐述，相信大家对于身份认证组建模式和统一认证模式的实现已经没有过多的疑问了。在本节，我将结合之前描述的体系和API 设计，针对信任代理模式，通过一个具体的例子演示统一身份认证服务的使用方法。
这个例子的应用场景是一个生产和销售电子器件的企业，它使用了ERP 系统管理其自身的生产流程和库存、使用SCM 系统管理与供应商之间的供应流程，同时使用CRM 系统管理客户、分销等。在最初，各个系统分别使用自己的用户系统，公司员工在使用这三个系统，并在三个系统之间切换的时候非常烦恼，不得记住三套用户并多次重复登录，工作效率也有所影响。随着更多的企业应用被一一部署，企业IT 部门认为如果能够将用户系统统一的话，将会显著地提高员工的工作效率。同时企业IT 部分选定了信任代理模式来实施统一身份认证服务。这样所有的授权访问能够置于统一身份认证服务的监控之下，便于企业管理部门对访问的监控和审计。
下面我用使用SOAP 消息的形式来演示用户访问SCM 系统的流程。
用户使用在统一认证服务注册的用户名和密码登陆统一认证服务，用户名是"UATest" ，而密码则使用了Base64编码表示的HASH 值；
xmlns:ac="http://example.org/universalauthentication">
UATest
EH67ij45DGg5
............
统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户，在SOAP 消息中，访问认证令牌使用Base64编码；
xmlns:ac="http://example.org/universalauthentication">
K8nfd858a3gJhk877fKLJSDH
............
用户使用这个访问认证令牌访问SCM 系统，不过用户并不将请求消息直接交给SCM 应用系统，而是传给统一身份认证服务，在消息中标识了SCM 系统的ID ："C1ACF26D-9672-4404-9D70-39B756E62AB4" 。
xmlns:ac="http://example.org/universalauthentication">
K8nfd858a3gJhk877fKLJSDH
C1ACF26D-9672-4404-9D70-39B756E62AB4
............
统一认证服务访问应用系统注册库(UDDI Registry)，获取了SCM 系统的访问入口(统一认证服务可以将这个访问入口缓存在本地，以减少以后与应用系统注册库的交互次数) 。并确认这个SCM 系统的确是支持统一身份认证服务的；
C1ACF26D-9672-4404-9D70-39B756E62AB4
假设返回消息中的serviceDetail 所包含的bindingTemplate 结构中所指明的服务访问入口accessPoint 是"http://leo/scmentry/"的。
统一认证服务将请求消息转发给指定的SCM 应用系统，如果该SCM 系统使用自己的用户系统的话，那么该消息应当包含了预先定义好的相关联的用户名和密码等。
SCM 系统将请求结果返回给统一认证服务，最后统一认证服务将响应消息返回给用户，完成调用。
Web Service Case Study: 统一身份认证服务 柴晓路 ([email protected])CIO, DealEasy
简介： 本文是Web Service Case Study 系列文章的第四篇。在这篇文章中，我将围绕一个多应用环境下统一认证服务组件的架构展开讨论，探讨如何利用Web 服务所带来的好处，实现跨平台跨应用的统一身份识别和权限认证。同时将其拓展到多种应用模式中去，包括Internet 公用服务、行业电子商务环境统一认证以及企业内部应用集成等。 标记本文！
发布日期： 2002 年 8 月 01 日
级别： 初级
访问情况 135 次浏览
建议: 0 (添加评论)
平均分 （共 1 个评分 ）
应用背景
以下描述中使用的地名、机构名和系统名称纯属虚构，但是是从具体应用中抽象出来的。
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决定开发一个统一身份认证服务，以解决这一应用集成中碰到的用户认证的问题。这个服务需要达到以下功能和目标：
1. 支持Web Services技术框架，使得在对各个应用系统实施基于Web Services 的应用集成(EAI/B2Bi)的时候能够使用这个统一身份认证服务进行身份认证。
2. 方便使用，能够尽可能地利用现有系统的身份认证模块以及现有的用户设置和权限设置，尽量保护现有的投资，减少重新的用户设置和权限设置的费用，同时避免对现有系统进行大规模的修改。
3. 具有良好的扩展性和可集成性，不仅能支持现有的应用系统及其现有的用户系统，当有新的企业应用被部署或开发的时候，这个统一身份认证服务可以作为它的身份认证模块的形式工作，也就是说，新的企业应用可以不自带用户系统，可以通过集成该服务的形式来实现等价的功能。
4. 应当具备灵活和方便的使用模式，使用者可以通过多种方式自由地使用该统一身份认证服务。
回页首
解决方案
根据这个统一身份认证服务的目标和初步的功能定义，我们将这个服务设计如下：
Figure 1. 统一身份认证服务
该服务主要需要具备三项功能：
1. 用户注册：用户在统一身份认证服务中注册帐号，以后这个帐号可以在所有使用统一身份认证服务的应用系统中使用。
2. 帐号关联：如果用户之前已经在相关的应用系统中拥有帐号，同时也已经设置了相应的权限，那么用户能够将这些应用系统的帐号与统一身份认证服务的帐号进行关联，使得用户登录统一身份认证服务之后，就能够自动使用相关的应用系统用户来访问应用系统。
3. 用户认证：为应用系统提供用户身份认证，兼顾两个应用方式：
4.
o 应用系统使用统一身份认证服务作为它的用户系统，用户与应用系
统进行交互，进行登录操作，应用系统将用户提供的用户名/密码
等转发给统一身份认证服务以检验其是否通过授权。
o 用户首先登录统一身份认证服务，并获取权限令牌，以后可以使用
这个权限令牌访问其他的应用系统，应用系统接收该权限令牌时应
当与统一身份认证服务进行交互，以检验访问的合法性。
按照以上的功能描述，我们可以认为统一身份认证服务中需要考虑的实体可以使用下图来表示：
Figure 2. 统一身份认证服务的数据实体
1. 用户(User)：即统一身份认证服务的用户；
2. 帐号(Account)：应用系统的帐号，与统一身份认证服务的用户相关联，一个用户可以关联多个帐号；
3. 应用系统(Application)：使用统一身份认证服务的应用系统；
4. 会话(Session)：当用户登录统一身份认证服务后，即创建了一个活跃的会话，并获得会话的认证令牌，在这个会话中，用户可以使用会话的认证令牌访问各种应用系统。
用户注册
用户注册(包括用户更新注册信息) 的流程可以使用下图来表示。其中主要包含了两个流程：新用户注册和用户更新注册信息。
Figure 3. 用户注册流程
新用户注册：
1. 用户向统一身份认证服务发出新用户注册请求
2. 服务查询用户注册库，如果该用户可以注册(没有同名ID 等违背约束条件的情况发生) ，那么将该用户的信息保存到用户注册库中。
3. 当保存完毕后，统一身份认证服务响应用户，注册完成。
用户更新注册信息：
1. 用户向统一身份认证服务发出用户注册信息更新请求。
2. 服务查询用户注册库，如果该用户信息可以更新(有该ID 存在，同时提供的密码也是正确的等等) ，那么将该用户的信息将在用户注册库中更新。
3. 当保存完毕后，统一身份认证服务响应用户，更新完成。
帐号关联
帐号关联操作可以使用下图来表示。图中仅包含一个登记新的帐号关联的操作，相关的修改、删除操作被省略了，有兴趣的读者可以自行给出。
Figure 4. 用户关联流程
登记新的帐号关联：
1. 用户向统一身份认证服务发出帐号关联注册请求，用户提供了应用系统的标识A ，同时提供了可以在该应用系统中使用的用户信息(可能包含用户名和密码等) 。
2. 服务首先向该应用系统A 征询，用户信息是否合法。如果合法则响应服务。
3. 如果收到合法响应，那么服务就将这个帐号关联注册信息保存到用户注册库中，以后该用户登录统一身份认证服务之后，就能够使用相应的应用系统A 。
4. 当注册库完成保存操作后，统一身份认证服务响应用户，注册完成。 身份认证组件模式
统一身份认证服务的一个基本应用模式是以应用系统的身份认证组件的形式工作，在这个应用模式下，主导地位的是应用系统。在这种情况下，应用系统自身没有用户系统，因此本模式下涉及的帐号一定是统一身份认证服务的用户帐号。
Figure 5. 身份认证组件模式流程
流程描述如下：(仅描述正常流程)
1. 用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等) 登陆应用系统A
2. 应用系统A ，将用户名和密码连同自己的标识(应用系统A 的标识) 一起转发给统一认证服务，要求统一认证服务完成登录操作。
3. 统一认证服务核查自己的应用系统注册库(使用UDDI Registry，我将在后面解释为什么使用UDDI Registry)看看应用系统A 是否已经是统一认证服务的用户系统。同时在用户注册库中核查由应用系统A 转发过来的用户名和密码。
4. 待核查完毕后，统一认证服务响应应用系统A ，登录完成。
5. 应用系统A 创建一个系统会话(Session，系统A 自己的机制) ，并将应用系统A 自己的权限令牌返回给用户，以后用户端可以通过这个权限令牌持续访问应用系统A ，直至登出系统或是会话超时。
统一认证模式
统一认证模式是以统一身份认证服务为核心的服务使用模式。用户登录统一身份认证服务后，即可使用所有支持统一身份认证服务的应用系统。
Figure 6. 统一认证模式流程
流程描述如下：(仅描述正常流程)
1. 用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等) 登陆统一认证服务；
2. 统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户；
3. 用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统；
4. 该应用系统将访问认证令牌传入统一身份认证服务，认证访问认证令牌的有效性；
5. 统一身份认证服务确认认证令牌的有效性；
6. 应用系统接收访问，并返回访问结果，如果需要提高访问效率的话，应用系统可选择返回其自身的认证令牌已使得用户之后可以使用这个私有令牌持续访问。
此外，关于访问认证令牌的失效，有两个策略，一个是由用户主动发起声明，声明其拥有的访问认证令牌不再有效，这类似注销的操作，另一个是用户一段时间内没有使用这个认证令牌，认证令牌自动失效，这类似超时的处理。 信任代理模式
在Internet 应用环境下，安全性和信任的重要性是显而易见的，对于商用系统而言，避免非法访问和入侵是他所需要考虑的几个重要问题之一，没有比商用数据丢失或是商用系统被违规使用更糟糕的了。
在信任代理模式下，一个组织可以为他所有需要提供安全信任保障的应用系统设置一个统一身份认证服务，对这些应用系统的访问全部由统一身份认证服务代理。
Figure 7. 信任代理模式流程
流程描述如下：(仅描述正常流程)
1. 用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等) 登陆统一认证服务；
2. 统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户；
3. 用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统，不过用户并不将请求消息直接交给应用系统，而是传给统一身份认证服务，在消息中标识了最终的应用系统的ID 。
4. 统一认证服务访问应用系统注册库(UDDI Registry)，获取了应用系统的访问入口(统一认证服务可以将这个访问入口缓存在本地，以减少以后与应用系统注册库的交互次数) 。并确认这个应用系统的确是支持统一身份认证服务的；
5. 统一认证服务将请求消息转发给指定的应用系统，如果该应用系统使用自己的用户系统的话，那么该消息应当包含了预先定义好的相关联的用户名和密码等。
6. 应用系统将请求结果返回给统一认证服务，最后统一认证服务将响应消息返回给用户，完成调用。
在该模式下，所有应用系统仅接收来自统一认证服务的访问请求，这样，解决方案提供商可以将主要的安全方面的投入部署在统一认证服务那端。
回页首
使用Web 服务架构
由于统一身份认证服务可能被应用的领域包括：
企业内部的各种应用
跨国企业的各个部门或地区分公司的各种应用
∙ 行业内各个企业的不同应用
∙ Internet 上丰富的应用环境 ∙
无论是何种应用环境，都将面对不同的平台、不同的系统和不同的编程环境，要能最大可能地支持所有的平台、系统和编程环境，同时又要确保服务的实现代价保持相对固定，那么目前看来，选择基于规范的Web Services解决方案将是一个不错的选择。
UDDI 的角色
在我们这个基于统一身份识别服务的应用环境中，所有支持统一身份识别服务的应用系统都需要被注册在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 中的应用系统技术信息以恢复数据的一致性。
Web 服务接口
根据前面几个部分的描述，我们可以归纳出统一身份认证服务的对外接口，接口基本上由两部分组成：
1. 用户Profile 维护：包括用户注册，关联帐号定义，帐号信息维护等。
2. 认证服务：包括用户登录/注销，认证令牌认证，访问转发，访问代理等等。
用户Profile 维护
用户Profile 维护的XML Schema定义如下：
elementFormDefault="qualified" attributeFormDefault="unqualified">
USAS User Definition
type="accountType" minOccurs="0" maxOccurs="unbounded"/>
从这个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调用的消息语法形如：
"someLoginName"
"someCredential"
其中userID 是用户的标识，其类型是email 地址，使用email 地址作为用户标识也是目前非专用用户系统比较通用的一种方式，原因非常简单，email 地址不同的人肯定不会重复，这样就避免了帐号无法成功注册的情况。而credential 则是对应的授权信息，可能是用户密码，数字签名等等形式。
当sign_in成功调用后，统一身份认证服务需要返回认证令牌以供此后的授权访问。authToken 消息是sign_in消息的响应消息。它返回认证信息authInfo ，认证信息将用于后续的调用。
authToken 消息的语法形如：
some opaque token value
authToken 消息包含单个 authInfo 元素，该元素包含一个访问令牌，令牌将在所有后继API 消息调用中被使用。作为一个对sign_in消息的同步响应，这个消息返回时始终使用SSL 加密。
当应用系统收到用户传来的认证令牌后，可以选择到统一身份认证服务验证该认证令牌的合法性，并依据结果判断是否接受用户的访问请求。这个验证认证令牌的API 函数是check_authToken。
check_authToken消息的语法形如：
some opaque token value
当认证令牌合法，将返回valid ，如果认证令牌不合法或者已经失效，则返回invalid 。
当用户完成了它所需的各种操作，那么它应当从统一身份认证服务中注销，以避免获取的认证令牌被非法滥用。此时它可以使用discard_authToken函数。
discard_authToken API 调用用来通知统一身份认证服务可以丢弃某个认证令牌，也就是终止当前的会话。以后一切使用该认证令牌的调用全部会被拒绝。 discard_authToken的语法形如:
查询UDDI 注册中心
我们先前已经提到，统一身份认证服务在得到用户传入的应用系统UUID 之后，需要去查询UDDI 注册中心以获得相关应用系统的技术信息以被之后的服务调用。这个查询API 具体来说，就是get_serviceDetail函数。
get_serviceDetail消息用来请求获取已知的businessService 结构的完整信息。 语法形如:
[ ...]
其中serviceKey 用于表示一个或多个用来代表已知businessService 数据特定实例的uuid_key值。该函数若成功调用，则返回一个serviceDetail 消息，其成功匹配了一个或多个serviceKey 值。如果传入的是多个serviceKey 值，其结果将根据传入的值的次序依次返回。如果匹配到的记录数量过多，操作入口站点将对返回值执行截断操作。如果该情况发生，serviceDetail 将包含一个truncated 属性，且该属性值为true 。
serviceDetail 消息返回一个或多个完整的businessService 结构，作为对get_serviceDetail查询消息的响应。
语法形如:
[truncated="false"] xmlns="urn:uddi-org:api_v2">
serviceKey="urn:uuid_key">
...
[...]
需要注意的是，businessKey 值在该消息中被表述，这是因为子元素的父容器(serviceDetail元素) 并不提供到父businessEntity 结构的键引用。其中businessService 用于表示一个或多个的完整的在UDDI 注册中心中的
businessService 结构。这些结构是由get_serviceDetail消息所指定的。 信任代理模式示例
通过之前的阐述，相信大家对于身份认证组建模式和统一认证模式的实现已经没有过多的疑问了。在本节，我将结合之前描述的体系和API 设计，针对信任代理模式，通过一个具体的例子演示统一身份认证服务的使用方法。
这个例子的应用场景是一个生产和销售电子器件的企业，它使用了ERP 系统管理其自身的生产流程和库存、使用SCM 系统管理与供应商之间的供应流程，同时使用CRM 系统管理客户、分销等。在最初，各个系统分别使用自己的用户系统，公司员工在使用这三个系统，并在三个系统之间切换的时候非常烦恼，不得记住三套用户并多次重复登录，工作效率也有所影响。随着更多的企业应用被一一部署，企业IT 部门认为如果能够将用户系统统一的话，将会显著地提高员工的工作效率。同时企业IT 部分选定了信任代理模式来实施统一身份认证服务。这样所有的授权访问能够置于统一身份认证服务的监控之下，便于企业管理部门对访问的监控和审计。
下面我用使用SOAP 消息的形式来演示用户访问SCM 系统的流程。
用户使用在统一认证服务注册的用户名和密码登陆统一认证服务，用户名是"UATest" ，而密码则使用了Base64编码表示的HASH 值；
xmlns:ac="http://example.org/universalauthentication">
UATest
EH67ij45DGg5
............
统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户，在SOAP 消息中，访问认证令牌使用Base64编码；
xmlns:ac="http://example.org/universalauthentication">
K8nfd858a3gJhk877fKLJSDH
............
用户使用这个访问认证令牌访问SCM 系统，不过用户并不将请求消息直接交给SCM 应用系统，而是传给统一身份认证服务，在消息中标识了SCM 系统的ID ："C1ACF26D-9672-4404-9D70-39B756E62AB4" 。
xmlns:ac="http://example.org/universalauthentication">
K8nfd858a3gJhk877fKLJSDH
C1ACF26D-9672-4404-9D70-39B756E62AB4
............
统一认证服务访问应用系统注册库(UDDI Registry)，获取了SCM 系统的访问入口(统一认证服务可以将这个访问入口缓存在本地，以减少以后与应用系统注册库的交互次数) 。并确认这个SCM 系统的确是支持统一身份认证服务的；
C1ACF26D-9672-4404-9D70-39B756E62AB4
假设返回消息中的serviceDetail 所包含的bindingTemplate 结构中所指明的服务访问入口accessPoint 是"http://leo/scmentry/"的。
统一认证服务将请求消息转发给指定的SCM 应用系统，如果该SCM 系统使用自己的用户系统的话，那么该消息应当包含了预先定义好的相关联的用户名和密码等。
SCM 系统将请求结果返回给统一认证服务，最后统一认证服务将响应消息返回给用户，完成调用。