统一认证系统（三）

　　程序员在为某个应用系统编写接入其它应用系统的程序代码的时候，常常为了用户认证大伤脑筋：1) 让最终用户频繁登录? 似乎是一个让用户很难接受的解决方案。2) 在代码中内置用户名和密码? 代码需要随用户和密码的变化经常维护，同时在很多场合下，用户名和密码对于程序员来说可能是不可见的。

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

1. 支持Web Services技术框架，使得在对各个应用系统实施基于Web Services的应用集成(EAI/B2Bi)的时候能够使用这个统一身份认证服务进行身份认证。
2. 方便使用，能够尽可能地利用现有系统的身份认证模块以及现有的用户设置和权限设置，尽量保护现有的投资，减少重新的用户设置和权限设置的费用，同时避免对现有系统进行大规模的修改。
3. 具有良好的扩展性和可集成性，不仅能支持现有的应用系统及其现有的用户系统，当有新的企业应用被部署或开发的时候，这个统一身份认证服务可以作为它的身份认证模块的形式工作，也就是说，新的企业应用可以不自带用户系统，可以通过集成该服务的形式来实现等价的功能。
4. 应当具备灵活和方便的使用模式，使用者可以通过多种方式自由地使用该统一身份认证服务。

解决方案

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

Figure 1. 统一身份认证服务

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

1. 用户注册：用户在统一身份认证服务中注册帐号，以后这个帐号可以在所有使用统一身份认证服务的应用系统中使用。
2. 帐号关联：如果用户之前已经在相关的应用系统中拥有帐号，同时也已经设置了相应的权限，那么用户能够将这些应用系统的帐号与统一身份认证服务的帐号进行关联，使得用户登录统一身份认证服务之后，就能够自动使用相关的应用系统用户来访问应用系统。
3. 用户认证：为应用系统提供用户身份认证，兼顾两个应用方式：
4. • 应用系统使用统一身份认证服务作为它的用户系统，用户与应用系统进行交互，进行登录操作，应用系统将用户提供的用户名/密码等转发给统一身份认证服务以检验其是否通过授权。
   • 用户首先登录统一身份认证服务，并获取权限令牌，以后可以使用这个权限令牌访问其他的应用系统，应用系统接收该权限令牌时应当与统一身份认证服务进行交互，以检验访问的合法性。

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

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. 应用系统将请求结果返回给统一认证服务，最后统一认证服务将响应消息返回给用户，完成调用。

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

 

以上内容为 链接内容中的一段节选

参考链接：https://www.ibm.com/developerworks/cn/webservices/ws-casestudy/part4/