Web服务实战：统一身份认证服务

当“基于供应链管理应用”在家用电子产品零售商和制造商中部署之后，收到了非常好的效果。由于采用了Web服务技术作为应用集成交互技术，各个企业实体都能自行选择平台，自行开发实施系统，并且只需要遵循事先商定的Web服务接口就可以彼此无缝连接。各个企业实体开始使用Web服务技术改造内部的旧有信息系统以实现企业内部、企业之间的广泛应用互联。然而此时，企业又发现了一个使用上的障碍。　　每个应用系统都有其自身的用户系统和认证方式。程序员在为某个应用系统编写接入其它应用系统的程序代码时，常常为用户认证大伤脑筋。问题主要表现在以下几方面：　　1．让最终用户频繁登录? 但这似乎是一个让用户很难接受的解决方案。　　2．在代码中内置用户名和密码? 　　但代码需要随用户和密码的变化经常维护，同时在很多场合下，用户名和密码对于程序员来说是不可见的。如何解决这一问题呢？我们从目前和未来的应用发展趋势判断认为，应当开发一个统一身份认证服务，以解决这一应用集成中碰到的用户认证问题。这个服务需要达到以下功能和目标：　　1. 支持Web服务技术框架，使得在对各个应用系统实施基于Web服务的应用集成(EAI/B2Bi)的时候，能够使用这个统一身份认证服务，进行身份认证。　　2. 方便使用，能够尽可能地利用现有系统的身份认证模块及现有的用户设置和权限设置，尽量保护现有的投资，减少新用户设置和权限设置的费用。同时避免对现有系统进行大规模的修改。　　3. 具有良好的扩展性和可集成性，不仅能支持现有的应用系统及用户系统，当有新的企业应用被部署或开发的时候，这个统一身份认证服务还可以作为其身份认证模块的形式工作。也就是说，新的企业应用可以不自带用户系统，可以通过集成该服务的形式来实现等价的功能。　　4. 应当具备灵活和方便的使用模式，使用者可以通过多种方式自由地使用该统一身份认证服务。　　　　解决方案　　根据这个统一身份认证服务的目标和初步的功能定义，将这个服务设计为图1所示。该服务主要需要具备三项功能：　　1. 用户注册，用户在统一身份认证服务中注册账号。以后这个账号可以在所有使用统一身份认证服务的应用系统中使用。　　2. 账号关联。如果用户之前已经在相关的应用系统中拥有账号，同时也已经设置了相应的权限，那么用户能够将这些应用系统的账号与统一身份认证服务的账号进行关联，使得用户登录统一身份认证服务之后，就能够自动使用相关的应用系统用户来访问应用系统。　　3. 用户认证。为应用系统提供用户身份认证，应兼顾以下两个应用方式：　　◆ 应用系统使用统一身份认证服务作为它的用户系统，用户与应用系统进行交互，并进行登录操作，应用系统将用户提供的用户名、密码等转发给统一身份认证服务以检验其是否通过授权。　　◆ 用户首先登录统一身份认证服务，并获取权限令牌，然后可以使用这个权限令牌访问其它应用系统，应用系统接收该权限令牌时应当与统一身份认证服务进行交互，以检验访问的合法性。按照以上的功能描述，可以确定统一身份认证服务中需要考虑的实体包括：　　1. 用户(User)，即统一身份认证服务的用户。　　2. 账号(Account)，即应用系统的账号，与统一身份认证服务的用户相关联。一个用户可以关联多个账号。　　3. 应用系统(Application)，使用统一身份认证服务的应用系统。　　4. 会话(Session)，当用户登录统一身份认证服务后，即创建了一个活跃的会话，并获得会话的认证令牌。在这个会话中，用户可以使用会话的认证令牌访问各种应用系统。　　　　用户注册　　用户注册(包括用户更新注册信息)的流程主要包含两个流程：新用户注册和用户更新注册信息。　　　　账号关联　　账号关联操作可以使用图2所示的形式来表示。图2中仅包含一个登记新的账号关联的操作，相关的修改、删除操作已被省略。登记新的账号关联：　　1. 用户向统一身份认证服务发出账号关联注册请求，用户提供了应用系统的标识A，同时提供了可以在该应用系统中使用的用户信息(如用户名和密码等)。　　2. 服务首先向该应用系统A征询，用户信息是否合法。如果合法则响应服务。　　3. 如果收到合法响应，那么服务就将这个账号关联注册信息保存到用户注册库中，在该用户登录统一身份认证服务之后，就能够使用相应的应用系统A。　　4. 当注册库完成保存操作后，统一身份认证服务响应用户，最后注册完成。　　身份认证组件模式　　统一身份认证服务的一个基本应用模式是以应用系统的身份认证组件的形式工作。在这个应用模式下，处在主导地位的是应用系统。在该情况下，应用系统自身没有用户系统，因此模式下涉及的账号一定是统一身份认证服务的用户账号。　　流程描述如下 (如图3，仅描述正常流程) ：1. 用户使用在统一认证服务注册的用户名和密码(也可能是其它授权信息，比如数字签名等)登陆应用系统A。　　2. 应用系统A将用户名和密码连同自己的标识(应用系统A的标识)一起转发给统一认证服务，要求统一认证服务完成登录操作。　　3. 统一认证服务核查自己的应用系统注册库(使用UDDI Registry)，看看应用系统A是否已经是统一认证服务的用户系统。同时在用户注册库中核查由应用系统A转发过来的用户名和密码。　　4. 待核查完毕后，统一认证服务响应应用系统A，登录完成。　　5. 应用系统A创建一个系统会话(Session，系统A自己的机制)，并将应用系统A自己的权限令牌返回给用户。以后用户端可以通过这个权限令牌持续访问应用系统A，直至登出系统或是会话超时。　　统一认证模式　　统一认证模式是以统一身份认证服务为核心的服务使用模式。用户登录统一身份认证服务后，即可使用所有支持统一身份认证服务的应用系统。　　流程描述如下 (如图4，仅描述正常流程)：1. 用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等)登陆统一认证服务；　　2. 统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户；　　3. 用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统；　　4. 该应用系统将访问认证令牌传入统一身份认证服务，认证访问认证令牌的有效性；　　5. 统一身份认证服务确认认证令牌的有效性；　　6. 应用系统接收访问，并返回访问结果，如果需要提高访问效率的话，应用系统可选择返回其自身的认证令牌已使得用户之后可以使用这个私有令牌持续访问。　　此外，关于访问认证令牌的失效，有两个策略：一个是由用户主动发起声明，声明其拥有的访问认证令牌不再有效，这类似注销的操作；另一个是用户一段时间内没有使用这个认证令牌，认证令牌自动失效，这类似超时的处理。　　信任代理模式　　在Internet应用环境下，安全性和信任的重要性是显而易见的，对于商用系统而言，避免非法访问和入侵是他所需要考虑的几个重要问题之一，没有比商用数据丢失或是商用系统被违规使用更糟糕的了。　　在信任代理模式下，一个组织可以为他所有需要提供安全信任保障的应用系统设置一个统一身份认证服务，对这些应用系统的访问全部由统一身份认证服务代理。　　流程描述如下(如图5，仅描述正常流程)：1. 用户使用在统一认证服务注册的用户名和密码(也可能是其他的授权信息，比如数字签名等)登陆统一认证服务；　　2. 统一认证服务创建了一个会话，同时将与该会话关联的访问认证令牌返回给用户；　　3. 用户使用这个访问认证令牌访问某个支持统一身份认证服务的应用系统，不过用户并不将请求消息直接交给应用系统，而是传给统一身份认证服务，在消息中标识了最终的应用系统的ID。　　4. 统一认证服务访问应用系统注册库(UDDI Registry)，获取了应用系统的访问入口(统一认证服务可以将这个访问入口缓存在本地，以减少以后与应用系统注册库的交互次数)，并确认这个应用系统的确是支持统一身份认证服务的。　　5. 统一认证服务将请求消息转发给指定的应用系统，如果该应用系统使用自己的用户系统的话，那么该消息应当包含了预先定义好的相关联的用户名和密码等。　　6. 应用系统将请求结果返回给统一认证服务，最后统一认证服务将响应消息返回给用户，完成调用。　　在该模式下，所有应用系统仅接收来自统一认证服务的访问请求。这样，解决方案提供商可以将主要的安全方面的投入部署在统一认证服务那端。　　使用Web服务架构　　由于统一身份认证服务可能被应用的领域包括：　　◆ 企业内部的各种应用　　◆ 跨国企业的各个部门或地区分公司的各种应用　　◆ 行业内各个企业的不同应用　　◆ Internet上丰富的应用环境　　无论是何种应用环境，都将面对不同的平台、不同的系统和不同的编程环境，要能最大可能地支持所有的平台、系统和编程环境，同时又要确保服务的实现代价保持相对固定。那么目前看来，选择基于规范的Web服务解决方案将是最佳的选择。