单点登录原理与技术实现比较

1.1    单点登录原理与技术实现 比较

1.1 .1   单点登录原理

单点登录 （ SSO ） 是指一个用户身份只需进行一次鉴权便可以访问所有经授权的资源，而不需要多次认证。 SSO 机制能够减少人为错误，同时提高整个系统的安全性。虽然 SSO 很有价值，但是它的实现并不容易，因为到目前为止还没有一种用户身份验证的统一标准。 IBM WebSphere  Portal 服务器提供了各种手段使 SSO 的实现简单化、安全化、有效化。

通常会有 外置代理和内置代理两种方法。

1 ．外置代理

在有些情况下，可以使用一种类似中介的代理进程，该进程处于用户和应用程序之间，如图 1- 1 所示。当用户被应用程序要求提供身份证明时，代理进程从用户资料库中得到用户的信用状，并送给应用程序。信用状相当于一个令牌，它只有用户的身份信息，而没有用户的密码凭证。换句话说，使用外置代理实现单点登录，被集成的 Web 应用系统是不再验证该用户在 Web 应用系统中的密码的。它认为，只要你是 Portal 的合法用户并且成功登录了 Portal ，你只需告诉我你的身份跟角色，我就认为你是该 Web 系统中可以使用授权信息的合法用户了。

图 1- 1   门户服务器进行身份验证过程 — — Web 应用没有提供 Authentication API 的情况

 ① 用户登录到门户服务器，身份验证服务对用户进行身份验证。

  ② 验证通过，建立用户信用状，并请求建立用户默认桌面。

  ③ 代 理程序使用用户信用状，并发送请求给目录服务，要求得到 Web 应用的用户名和口令。

  ④ 得到用户名和权限信息。

  ⑤ 代理程序使用它们进入 Web 应用并依据权限信息得到应用数据。

  ⑥ 代理程序将得到的数据格式化后生成用户默认桌面，应用程序的内容以门户 Channel 的形式展现。

  ⑦ 将生成的桌面传送给用户。

上面的情况适用于 Web 应用没有提供 Authentication API 的情况，对于提供 Authentication API 的 Web 应用（如 Lotus Notes ），则多出来一步，即第 4 步：鉴权。用户在 Web 应用中的用户名和密码必须事先通过加密存储机制存储到 Portal 平台，此时代理程序建立的信用状同时包含了此用户在该 Web 应用系统中的密码。代理程序携带此用户的用户名和密码调用 Web 验证服务实现认证过程，认证完成后，至于此用户在该 Web 系统中到底有哪些权限，这就由接下来的 Web 系统去执行了，因为此时此用户已经通过调用验证服务的手段成功登录了该 Web 应用系统。如图 1- 2 所示。

图 1- 2   门户服务器进行身份验证过程 — — Web 应用提供 Authentication API 的情况

 ① 用户登录门户服务器。

 ② 请求建立用户默认桌面。

 ③ 代理程序使用 Portal Token 并批准使用 Web 应用的 Authentication API 进行用户身份验证。所使用的用户名与登录门户服务器时使用的一样，或者是一个映射值，映射表应存放在门户服务器的 Profile 中。

 ④ 进行用户鉴权。

 ⑤ 鉴权成功。

 ⑥ 代理程序使用 Web 应用 API   获取数据。

 ⑦ 代理程序将得到的数据格式化后生成用户默认桌面，应用程序的内容以门户 Channel 的形式展现。

 ⑧ 将生成的桌面传送给用户。

上面所提到的代理程序，可以通过 IBM WebSphere Portal 提供的 API 编写的  Servlet 程序实现。这个  Servlet   程序将用户的信用状传递给应用程序，并将用户重定向到应用的主页面。  

外置代理的优点：

—  启动投资相对较少。

缺点：

—  不利于系统管理和维护。

—  对系统总体性能有影响。

—  不支持跨域的 SSO 。

2 ．内置代理

内置代理方法 是 指 利用策略管理软件，即 Identity 服务器软件。策略管理软件的工作原理是，在 Web 服务器上安插一个代理模块（ Agent Module ），该模块与   Identity   服务器共同负责用户身份验证和授权信息。

要 将策略管理软件与 Portal 服务器进行集成，可以将策略代理模块安装在内嵌于 Portal 服务器中的 Web 服务器上，并使用 Portal 服务器提供的 API ，基于策略管理软件的 S ession 创建过程生成一个有效的 Portal   服务器 S ession 。这样，用户可以在策略管理系统的控制下访问任何 W eb 应用。

内置代理的 优点：

—  通过 Identity 服务器及其 Web 代理模块可以安全 、 有效地控制用户身份验证和资源访问 。

—  提供集中的访问控制管理，增强大型复杂应用系统的可管理性和效率 。

—  为系统开发人员提供一种简单的方法对集中化的目录资源进行访问，易于扩展 。

—  通过 Extranet Web Agents ，可以无缝地集成 Web 应用 。

—  具有 支持百万级用户的良好系统扩展性 。

—  保护投资 。

—  支持跨域的 SSO 。

从逻辑概念上 看 ， Identity 服务器作为企业核心的应用访问控制器，而 Portal 服务器则是一个内容聚合器，聚合由 Identity 服务器保护的应用。同时， Portal 服务器还作为企业内部安全的应用访问转送器。 使用内置代理实现 Portal 与 Web 应用系统的原理及过程如下，我们分 12 个步骤来介绍。

 ① 用户访问门户网关。

 ② 门户网关检查当前 IPS Session 是否包含有效的 Cookie ，如果不包含（即 Session 还未建立），门户网关则将信息包传给门户服务器的身份验证模块。

 ③ 服务器的身份验证模块将信息包转发给 Identity 服务器的代理模块。

 ④ 代理模块给用户发送一个经过定制的登录页面（此页面显示使用 Identity 服务器进行身份验证）。

  ⑤ 用户输入用户名 / 口令（或其他身份信息），并返回给代理模块。

 ⑥ 代理模块将该信息发送给 Identity   服务器。

 ⑦ Identity 服务器验证用户身份（查询存储用户信息的目录数据库）。

 ⑧ 验 证成功， Identity 服务器生成 Identity Cookie （包含验证成功等信息） , 并发送给代理模块。

 ⑨ 代理模块存储 Identity Cookie ，并调用门户服务器的身份验证模块使 Session 有效（生成一个 Portal Session ）。

 ⑩ 门户服务器的身份验证模块将 Identity Session 和 Portal Session 发送给用户浏览器。

 ⑪ 门户网关保存 Portal Session ，使用户的 Session 生效。

 ⑫ 门户网关给用户发送门户首页。

一旦身份验证流程完成，用户不需要重新认证就可以访问由门户服务器及 Identity 服务器保护的任何资源和应用。

3 ． 页面流方式实现单点登录

页面流方式的单点登录，指的是用户成功登录 Portal 后，在业务系统中用户每调用一次 Web 系统的页面， Web 系统都要联络代理进行一次验证。 iDSAME 产品就提供了这种功能，它是一种更加严格的访问控制策略，用来保护企业核心、重要系统的数据和资源，具体实现是由 iDSAME 的 Web 代理以及相应的 URL 访问策略来共同完成的。

Web 代理安装在受保护资源的机器上，当用户访问受保护的系统资源时， Web 代理首先截获请求，检查访问的是否是受保护资源，如果不是，则允许访问；如果是， iDSAME 则会根据用户的 Token 检查用户能访问还是不能访问。与内置代理、外置代理不同，使用该策略实现单点登录会严重降低应用系统的性能，因为用户每访问一个页面，都会引起一次鉴权的过程。通常，这种情况应用于企业的比较核心和重要的业务系统中。

4 ．交叉域单点登录

交叉域单点登录（ Cross Domain SSO ）是指实现单点登录的几个应用服务器在不同的域内。在这种情况下要实现单点登录，必须将其他域转换到本地域，进行域名映射。交叉域单点登录实现原理示意图如图 1- 3 所示。

图 1- 3   交叉域单点登录实现原理示意图

1.1 .2   单点登录的技术方案

针对集成的不同的应用系统，我们会提供不同的单点登录解决方案，下面是实现单点登录功能的 常用技术方案。

1 ． LTPA （ Lightweight Third-Party Authentication ） 令牌环技术

LTPA 是一种令牌环，上面记录了用户的登录信息和身份信息，它 提供 了 基于 Cookie 的轻量级第三方认证机制（ LTPA ），当用户发出对资源的请求时，首先 必须 向 认证服务器 认证。认证成功后， 认证服务器 代表用户生成 LTPA Cookie 。作为认证标记服务的 LTPA Cookie 中 包含用户标识、密钥和标记数据、缓冲区长度和到期信息，此信息使用 认证服务器 和 应用系统 之间共享的受密码保护的密钥加密。 认证服务器 在请求的 HTTP 头中插入 Cookie ，该请求通过连接发送到 应用系统 ， 应用系统 服务器接收请求、解密 Cookie 并基于 Cookie 中提供的标识信息认证用户。

2 ．基于表单的单点登录（ Form-Based SSO ）

基 于表单的单点登录 （ Form-Based SSO ） 功能 ， 允许 认证服务器 将已认证的用户透明地登录到需要通过 HTML 表单认证的后台系统中 。基于表单的单点登录实现原理示意图如 图 1- 4 所示。

图 1- 4   基于表单的单点登录实现原理示意图

3 ． HTTP 头文件（ HTTP Header ）技术

利用 HTTP Header 这种认证方式， 认证服务器 可以把经过认证的用户身份信息（包括账号、属性信息等），通过 HTTP Header 传给后台的应用系统，后台的应用系统可以从 HTTP Header 中把这些用户信息截取出来，用来确认用户身份，从而实现统一认证（单点登录）的功能。这种统一认证的方式需要后台的应用系统进行相应的修改，使它可以获得 HTTP Header 中的用户信息。

4 ．凭证保险库（ GSO-Lockbox ）技术

GSO-Lockbox 这种实现单点登录的方式一般会和 Form-Based SSO 方式一起来使用，主要 是 考虑到每个人在各个系统中的用户身份可能会不一致，利用这种方式可以解决这种问题。利用 GSO-Lockbox ，可以建立起用户身份信息和后台应用系统之间的对应关系 。

在不同的产品中有各自的实现方式，例如，在 IBM WebSphere Portal 中叫做 Credential Vault ，也翻译为 “凭证保险库”。凭证保险库为实现单点登录的每套应用系统创建一个凭证保险段，在每个凭证保险段里则为每个 Web 用户创建一个凭证保险槽。槽是最小的凭证单位，用来存储一个用户在一套应用系统中的用户名和密码键值对（见表 1- 1 ）。

表 1- 1   GSO-Lockbox 实现单点登录的方式

以上几种方式很难说谁最好，最佳实践的做法是根据客户的具体情况选用不同的解决方案，或几种实现方案同时使用，依据不同的应用系统情况而定。但通常来说，应遵循如下几个原则。

（ 1 ）对部署在 WebSphere Application Server 、 WebLogic Server 、 SAP NetWeaver Application Server 、 Domino 等服务器上能识别 LTPA 令牌环，且用户目录与 Portal 的用户目录为同一套，或者有一一对应关心的应用系统，与 Portal 实现单点登录时，建议采用 LTPA 机制。

（ 2 ）对部署在 WebSphere Application Server 、 WebLogic Server 、 SAP NetWeaver Application Server 、 Domino 等服务器上，且用户目录与 Portal 的用户目录不是同一套，或者没有一一对应的应用系统，与 Portal 实现单点登录时，建议采用 JAAS 认证。

（ 3 ）用户注册表与 Portal 不一致，但应用系统中的用户在 Portal 中都有对应的用户时，不管其用户名编排规则是否一致，皆建议采用凭证保险库技术。

1.2    单点登录在最佳项目实践 中的应用

使用单点登录技术实现 Portal 系统与其他应用系统的单点登录后，用户只要成功登录 Portal ，就可以无须再次登录而直接进入应用系统，或者在 Portal 中直接使用应用系统中授权的应用或信息。在进行实际项目开发时，通常会设计如下几种模式，作为单点登录及单点登录的扩展应用。

1.2 .1   以列表的方式进入应用系统首页

以列表的方式进入应用系统首页，指的是提供一个展现应用系统列表的 Portlet ，上面列出了实现单点登录的所有应用系统（见图 1- 5 ）。点击列表中的条目，可以直接在新的页面中进入该应用系统，而无须再次登录或者提供任何凭证。

图 1- 5   以列表 Portlet 的方式应用单点登录

1.2 .2   直接进入各个应用系统的深度集成模式

很多时候，用户需要进入到系统的某个深层次页面，而不是从系统首页一步步点击。单点登录的深度集成模式指的是通过不同的标签直接进入到客户想进去的页面，如图 1- 6 所示。

图 1- 6   点击不同的标签直接进入到应用系统的深度集成页面

1.2 .3   以应用导航的方式梳理后集成

很多客户会有这样的经验：当应用系统过多时，自己都忘记了发起某个业务或某个功能的页面到底在哪套系统中。应用导航集成思路指的是，不是从应用系统的角度梳理深度集成的页面，而是从用户的业务应用角度来分析，将用户经常使用的功能页面从业务的角度梳理、分类，并分门别类地展现到系统中。用户只需知道要干什么就行了，而不必关心要执行的这个页面到底在哪套系统中。也就是说，让用户忘掉系统的存在。图 1- 7 所示是典型的应用导航图。

图 1- 7   典型的应用导航图（应用导航允许用户忘记系统的存在，只需知道要干什么就行了）

1.2 .4   作为统一待办调用任务处理界面时的通用验证逻辑单元

单点登录的最广泛和深入的应用莫过于统一工作待办了。把所有系统中每个用户需要待办的事项分门别类地按照业务域划分出来，并集中展现到一个个栏目中，让用户原来需要登录多套系统去处理的待办事项，在一个栏目中就完成了，多方便啊！图 1- 8 所示是将来自几十套系统的待办事项统一集成到一个栏目中，并按照 9 大业务域划分的一个典型场景。

图 1- 8   按照业务域在一个栏目中集中展现来自几十套系统的待办事项

1.3    单点登录技术的开发 /配置指南

单点登录的实现技术还有很多，比如 JAAS 认证等，但在项目实践中应用最多的就是 LTPA 令牌环和凭证保险库技术。本节详细介绍这两种方案的开发 / 配置过程。

1.3 .1  LTPA 技术是如何实现

1.3 .1.1　 LTPA 对于 SSO 的 工作 机制

LTPA 机制适用于部署在 WebSphere Application Server 、 WebLogic Server 、 SAP NetWeaver Application Server 、 Domino 等服务器上，它能识别 LTPA 令牌环，以及用户目录与 Portal 的用户目录为同一套，或有一一对应关系的应用系统。本节以 WebSphere Portal 与 Domino 之间实现单点登录为例，介绍 LTPA 机制是如何配置的。

LTPA （ 轻量级第三方认证 ）是一个令牌环， 它是通过使用 Domain Cookie 而启用的。这种经过加密的会话 C ookie 被放置在用户浏览器中，包含了一些信息， WebSphere 或者 Domino Application 服务器可以加密这些信息，并使用这些信息来说明用户已经通过该 C ookie 所覆盖的 DNS （ Domain Naming Service ，域名服务）域中的认证。

LTPA C ookie 包含以下信息 。

—  Cookie 名称：总是设置为 LtpaToken 。

—  域：设置为 Internet 域，该域由参与单点登录的所有服务器共享（例如： mycompany.   com ）。

—  Cookie 到期：设置为当浏览器终止时删除该 C ookie 。

—  安全：设置为开状态，以强制使用安全套接字层 （ SSL ） 。 LTPA 配置有一个设置参数，使它创建只通过 SSL 发送的 C ookie 。

—  Cookie 值：被设置为 LTPA 标记。

LTPA 标记是一个加密的字符串，它包含以下信息 。

—  用户数据：一般被设置为用户 ID ，但也可以是任何用于 唯 一标识用户的用户信息。

—  过期时间：与 Cookie 过期不同，这个字段用于强加一个时间限制，时间限制从登录进来的那一刻算起，而不受浏览器活动或者不活动影响。 这个时间限制是一个可 设 置的 LTPA 配 置， 在默认 情况下为 30 分钟。

1.3 .1.2   如何配置 Portal 与 Domino 之间的 SSO

Portal 与 Domino 的 SSO 可以通过配置 LTPA 的方法来实现。通俗地讲就是，用户登录 Portal 系统后， Portal 系统会把用户登录信息加密成 LTPA 并存放到某一位置，当用户继续访问 Domino 系统中的授权资源时， Domino 系统会自动读取该位置的 LTPA ，读到并解密后拿到 Domino 系统中验证，如果验证通过，则显示给用户授权信息。所以要配置 Portal 与 Domino 之间的 SSO 非常容易，只要先将 Domino 系统服务器的 LTPA 导出并存为 .key 文件，然后导入 Portal 系统所在的服务器（ WebShpere Application Server ）中就可以了。

1.3 .2   凭证保险库 技术是如何实现的

1.3 .2.1   概述

WebSphere Portal 提供了 Credential Vault （凭证保险库）功能 ， Credential Vault 通过 Basic Authentication Header 将用户名和密码传递给后端应用程序。为了使 Domino 服务器接受通过这个头部传递进来的凭证，必须将服务器会话验证配置为 Single-Server 模式。在 Multi-Server 模式中，该服务器只接受通过 LTPA 机制传递的凭证。因此，为了与 Domino 应用程序一起使用用于 SSO 的 Credential Vault ，必须将 Domino 服务器会话验证配置为 Single-Server 模式。

要使用 Credential Vault ，用户需输入一些凭证，输入一次就够了。随后，这些凭证被存放在一个经过加密的数据库表中，每当用户访问该 P ortlet 时，这些凭证便被传递给后端应用程序。要了解关于配置 Credential Vault 的细节， 请 参见 WebSphere Portal InfoCenter 。

1.3 .2.2 　凭证保险库实现 SSO 原理

下面以一个最简单的 SSO 过程为例进行介绍。

  普 通业务系统的登录过程：系统首先提供一个页面，让我们输入应用程序中的用户信息。

  用户输入用户名和密码后，单击 “登录”按钮，该页面提交到 form 所对应的 Action （ check_login.jsp ）进行处理，我们看 check_login.jsp 的代码。

接下来提交到数据库验证用户信息的合法性，如果合法，则定位到授权信息页面；否则，重定位回到登录页面 login.jsp 。

在 Portlet 开发中是如何解决这个问题的？

其实起关键作用的还是 check_login.jsp 页面，它需要获得用户名和密码两个键值，然后拿着这两个参数到后台数据库去验证。在常规的登录方式中，这两个参数是通过 login.jsp 获得的。事实上，只要 Portlet 能为该页面提供这两个键值，也就实现了登录的自动化。而 Portlet 要得到这两个参数是非常简单的，所以实现单点登录也就非常简单了。我们可以复制一个 check_login.jsp 文件，例如名为 check_portal_login.jsp ，这个页面的两个参数是 Portlet 提供的，剩下的事完全交给业务系统去处理，页面流转和全线控制都不用我们管了。

1.3 .2.3 　开发 Portlet 实现 SSO 的方法

（ 1 ） JSP 取值传送 URL

我们开发一个使用系统专用槽的 Portlet ，使用凭证保险库的相关接口在 PortletView.jsp 中取出用户存储在凭证保险库中的键值，然后以 URL 的方式传送到 iFrame 内。

PortletView.jsp 的部分代码如下：

如果用户已经在凭证保险库中存储了键值，那么该 Portlet 的 View.jsp 页面被初始化时， iFrame 中将显示用户成功登录后的授权信息，也就是实现了 SSO 。

（ 2 ） Class 取值写 Session ， JSP 取出并以 URL 传送

我们在 Portlet 的控制类中取得用户存储在凭证保险库中的键值对，并在 PortletView 的 doview() 方法中写入 Session 。在 Portlet 的Ｖ iwe.jsp 中取出 Session ，然后像第一种方法一样，以 URL 的方式传送到目的代理。

（ 3 ） Class 写 Session ，单点登录代理取 Session

我们在 Portlet 的控制类中取得用户存储在凭证保险库中的键值对，并在 PortletView 的 doview() 方法中写入 Session 。而专为 Portal 开发的协助登录页面则会直接从 Session 中取出用户凭证，具体的操作方法略过。

由于这几种方法开发起来比较简单，所以这里就一带而过，不再详细介绍了。