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

1.1.1  单点登录原理

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

创新互联建站专注为客户提供全方位的互联网综合服务，包含不限于网站制作、网站设计、雁塔网络推广、微信小程序开发、雁塔网络营销、雁塔企业策划、雁塔品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联建站为所有大学生创业者提供雁塔建站搭建服务，24小时服务热线：13518219792，官方网址：www.cdcxhl.com

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

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，基于策略管理软件的Session创建过程生成一个有效的Portal 服务器Session。这样，用户可以在策略管理系统的控制下访问任何Web应用。

内置代理的优点：

— 通过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而启用的。这种经过加密的会话Cookie被放置在用户浏览器中，包含了一些信息，WebSphere或者Domino Application服务器可以加密这些信息，并使用这些信息来说明用户已经通过该Cookie所覆盖的DNS（Domain Naming Service，域名服务）域中的认证。

LTPACookie 包含以下信息。

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

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

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

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

— 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，用户需输入一些凭证，输入一次就够了。随后，这些凭证被存放在一个经过加密的数据库表中，每当用户访问该Portlet时，这些凭证便被传递给后端应用程序。要了解关于配置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中取出用户凭证，具体的操作方法略过。

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

网站栏目：企业门户---单点登录与企业应用系统集成
链接URL：http://lswzjz.com/article/jjgche.html