应用整合中SSO的技术实现

jim153

                                               
在税务行业信息化发展的关键阶段，应用整合已经非常重要，而应用整合的表现层首先要实现的就是单点登陆（SSO，Single sign-on的缩写），以下是笔者结合南京地税进行应用整合中SSO的技术实现
      
。
南京地税目前有多种企业应用，包括征管系统、行政系统、辅助决策系统、公文系统、人事系统、电子地图、
邮件系统等等，这些应用主要是采用三层体系结构（IE6.0+weblogic portal7.0 +weblogic server7.0
+oracle9i）来构架。所有的用户登陆需要通过weblogic portal进行。
我们在系统中使用SSO来实现用户通过一次认证（authenticate）来存取多个受保护的资源，也就是说，用户随后对受保护资源的存取，将不会导致每一次都要用户提供认证的信息，只需要一次认证即可。
一、SSO实现原理
1、概念：SSO的一种偏向技术的说法：用户只需登陆一次，就可使用多个SSO enable的应用系统。
（1）、单一的登陆点。理想的情况是用户通过任何应用系统都能进行SSO，这对于基于Web的系统是可
行的。这种单一的登陆点在整个系统的设计中是唯一认证用户的地方，由登陆点将SSO
token（针对不同的C/S，B/S应用可能还需要传递用户名，口令）传递给应用系统，应用系统利用SSO
token来进行用户已认证的验证。我们将这个单一的登陆点称为SSO Entry。
（2）、SSO
enable意味着对应用系统的修改不可避免。并不是任何系统都能够使用SSO，只有那些符合SSO规范，使用SSO
API的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统，屏蔽已有的应用系统的用户认证模块，使用系统提供的SSO
API来验证用户，以及对用户的操作进行授权。
（3）、需要统一的认证，权限信息库。通常，认证与授权管理模块以一种应用专有的方式实现，系统的授权
模型、认证，授权信息存贮结构与访问控制逻辑与应用的业务逻辑之间耦合紧密。这种设计与实现方式的缺点是显而易见的：由于认证、授权模块与应用逻辑之间的
紧耦合使得认证、授权模块很难进行扩展与维护；认证、授权模块的设计与编码需要很大的工作量，而且很难在不同的应用系统之间共享与重用。这也是越来越多企
业应用需要SSO的原因之一。
SSO要求有统一的认证，权限存放库。但现实中，有的系统无法使用外部的认证，授权信息库，所以就需要在应用系统和Portal Server之间进行认证，同时进行授权信息的数据同步。
2、实现描述：在用户成功登录 weblogic Portal之后，系统提供的Login Delegate机制来为用户登录到其有权可以使用的应用系统。系统提供Logout Delegate机制实现用户的注销功能（即SSO logout）。
用户存取由Portal SSO保护的若干资源，SSO会话服务（Session/SSO
Service）提供了授权的证明，这样就不再需要用户重新进行身份验证了。在这种方式下，即使用户要访问不同的域（weblogic
domain）的应用，我们提供的Portal SSO Service为其保持会话服务。
同时，SSO还包括的与登录恰恰相反的，统一的注销点，即用户一旦从Portal注销，则亦当从所有参
与Portal
SSO的应用注销。此处有一个例外，就是当用户从Portal登录并转向一个应用后，经过一段时间后可能会出现用户的该应用的会话还有效时用户的
Portal会话过期时，此时用户将只能使用该应用，直到该用户再次登录Portal。
3、通过SSO
Agent：当用户试图通过浏览器存取受保护的应用资源时，系统提供安装在不同应用上的SSO
Agent来截取用户对资源的请求，并检查请求是否存在会话标识符，即token。如果token不存在，请求就被传递给Portal
SSO，在Portal SSO上会话服务负责创建会话token，然后认证服务将提供登陆页面以验证用户。
4、创建会话Token：在用户身份验证之前，会话服务就创建了会话token。token为随机产生
的Portal  Server
会话标识符，该标识符代表了一个确定用户的特定会话。创建会话token后，认证服务把token插入cookie中在用户的浏览器中设定cookie。
在token被设定的同时，该用户将会看到一个登陆页面。
5、用户认证：用户收到登陆页面和会话token后，填入合适的认证信息。当用户提交登陆页面后，这些
认证信息就被发给认证提供者（authentication
provider）（LDAP服务器，RADIUS服务器等）进行验证。一旦认证提供者成功验证了认证信息，用户就被认为是通过了认证。Identity
Server会从用户的token中取出会话信息并将会话状态设为有效。此后，用户就可以访问这些受保护的资源。
6、cookie和会话token：Cookie是由Web服务器创建的信息包，并传递给浏览器。
Cookie 保存类似用户习惯等Web服务器产生的信息。它本身并不表明用户通过了认证。Cookie是特定于某个域的。在Identity
Server的实现中，cookie由会话服务产生，并由认证服务设定。而且，Identity
Server的cookie是会话cookie，存储在内存中。会话token由会话服务创建并插入Cookie。会话token利用安全随机数发生器产
生，并包含Portal Server特有的会话信息。在存取受保护的资源之前，用户由认证服务验证，并创建SSO token。
二、SSO技术实现
1、SSO entry
SSO entry 作为系统唯一的登陆点将完成如下的功能：
（1）提供用户身份认证的登陆页面；
（2）根据用户的权限，显示可供用户使用的应用系统；
（3）调用用户选择的应用系统（B/S或C/S均可）；
（4）为应用系统传递SSO Token（针对不同的C/S，B/S应用可能还需要传递用户名，口令）；
（5）关闭SSO；
（6）SSO token失效后，关闭SSO entry。
注意SSO entry 并不提供通知应用系统SSO token已失效的功能，这一问题并不大，因为SSO token失效后，SSO entry 已被关闭。用户只有重新认证，才能获取新的SSO token。
2、SSO 部署


上面是整个系统的部署的示意图。白色的立方体表示应用系统。浅蓝色的立方体表示Portal SSO平台。从上图可以看出：各个应用系统各个应用系统与SSO entry发生联系。SSO entry 需要向应用系统传递SSO Token，用户名，口令；启动应用系统。
3、SSO实现方式
SSO 的实现方式按照应用系统与Portal
Server的交互程度分为三种。需要指出这些SSO的实现方式并没有优略之分，不同的实现方式适应不同的应用环境。解决现实中遇到的不同问题。真单点登
陆： 通过SSO entry认证后，应用系统利用SSO API同Portal
Server通信，验证用户是否经过认证。新开发的应用系统大多使用这种SSO的实现方式。这种方式需要对应用系统的认证模块进行修改。伪单点登陆：通过
SSO
entry认证后，应用系统还要自己进行用户的认证。这种方式适用于那些无法修改认证模块的应用系统。我们应用系统的整合采用该方式进行。整合第三方软件
的单点登陆：Tarantella和Citrix都是将C/S应用系统转化为Web应用的第三方软件系统。在某些应用环境下，这类软件将发挥其作用。这种
SSO实现方式在实施中并不使用，列出这种使用方式主要用来展现Identity Server的扩展性。
4、SSO的实现
（1）用户从Portal登录

说
明：以上蓝色区域为Portal Server上的服务，白色为需要与Portal进行SSO的应用，绿色为每个应用的SSO
Entry。代理登录的具体过程：用户首先登录Portal，Portal处理完登录后，启动代理登录，为用户登录应用系统，Portal把用户转向到应
用系统，应用系统再把用户在征管系统的sessionID转发给Portal，登录代理（Login
Delegate）把用户在征管系统中的sessionID和用户id发到征管系统的SSO
Service进行登记，Portal把用户访问转向征管系统SSOEntry，征管系统SSOEntry通过用户的sessionID得到
SSOService中记录的用户在Portal的用户userID，并把当前用户认可为此Portal
userID对应的在征管系统中的用户，征管系统把用户访问转回Portal。接着登录代理再对SSO应用列表中的其它应用进行代理登录。代理登录完成，
用户被重定向到Portal的相关页面。
用户访问应用系统：之后，当用户访问征管的某个应用时，征管系统发现该用户还未经认证，则将其
sessionID与SSOService中登记的uid/sessionID比较，如果存在匹配，则认证通过，将用户id与session相关联。之后
用户就可以直接访问征管系统了。
（2）SSO单点注销


说明：
（1）用户注销总是从Portal开始；
（2）注销代理（Logout Delegate）将注销消息发到各应用的SSO Logout Entry；
（3）应用的SSO Logout Entry注销本地的用户会话记录；
（4）注销Portal上的用户会话记录。
三、安全性分析
Portal SSO的安全性需要从几个方面理解：
1.客户登录Portal Server之后SSO到应用的安全性，即SSOToken的安全性；
2.客户无SSOToken时，首先访问应用的安全性；
3.客户有SSOToken时想通过仿冒别人的有效SSOToken来进行非法的访问。
Portal Server生成的SSO token
因为需要在应用程序间传递，所以SSOToken比较容易被窃取，但Portal
Server保证了SSOToken的唯一性，那些盗用合法SSOToken的人无法通过SSOToken的验证。因为SSOToken的生成收集了用户
端和服务器端的很多信息，当非法用户持有效的SSOToken试图访问某应用时，该应用将通过Portal
Server的SSOService进行SSOToken验证时，SSOToken的这些信息以及Portal
Server的安全算法确保了盗用者即使拿到合法用户的SSOToken也无法通过SSOToken的有效性验证。所以SSOToken的安全性也得到了
保证。
用户没有SSOToken的时候，如果客户要访问某应用，如果用户没有该应用的会话信息也没有
Portal的SSOToken，则该用户必须先通过Portal的认证并SSO到该应用；如果用户已经在应用登录成功（可能是该应用保留了原有的认证入
口，用户通过该入口访问此应用，也有可能是用户从Portal 登录后，通过SSO访问该应用，经过一段时间后，用户的Portal
SSOToken已经过期，但是用户在该应用中的会话仍然保持有效），则用户可以继续使用该应用系统而无需重新认证。但是如果用户想访问Portal或者
与Portal进行SSO的其它应用的话，则用户须经过Portal的认证并拿到SSOToken。所以在这种情况下SSOToken也是安全的。
每个用户的SSOToken只在其当次会话过程中有效，离开其当次会话，SSOToken即被视作无效，因此这种情况下也是安全的。
                在门户项目中，经常会遇到如何实现单点登录的问题，下面就本人的经验做个总结。欢迎大家进行补充讨论。
单点登录的具体实现有很多种选择：包括：
a)  采用专门的SSO商业软件：  主要有：Netgrity的Siteminder，已经被CA收购。Novell  公司的iChain。RSA公司的ClearTrust等。
b)  采用门户产品供应商自己的SSO产品，如：IBM  的Tivoli  Access  Manager，Sun  公司的identity  Server，Oracle公司的OID等。
c)
这些商业软件一般适用于客户对SSO的需求很高，并且企业内部采用COTS软件如：Domino,SAP,Sieble的系统比较多的情况下采用。并结
合身份管理。统一认证等项目采用。采用这些软件一般都要对要集成的系统做些改造，如在要集成的系统上安装AGENT。现在一般只提供常见软件如：
Domino,SAP,Sieble，常见应用服务器：weblogic,websphere等的AGENT。要先统一这些系统的认证。一般采用LDAP
或数据库。然后才能实现SSO。比较麻烦。
d)  另外，如果不想掏银子，也有OPEN
SOURCE的SSO软件可选：主要有：http://www.josso.org/  
https://opensso.dev.java.net/    http://www.sourceid.org  等。具体怎么样就不清楚了。
如果项目对SSO的要求比较低，又不想对要被集成的系统做任何改动，可采用下面介绍的方式简单实现：下面我们通过一个例子来说明。假如一个门户项目要对下面的几个系统做SSO。

用户在这些系统中的用户名，密码各不相同，如：员工号为001的员工在这些系统中的用户名，密码分别如下：  
用户  系统  用户名  密码  
001  Portal系统  A  1234  
001  邮件系统  B  23456  
001  DOMINO系统  C  ABCDE  
001  报销系统  D  CCCCC  
001  工资系统  E  DDDDD  
首先，建立员工在PORTAL系统中的用户名和其他系统中的用户名之间的对应关系
要
建立员工在PORTAL系统中的用户名和其他系统中的用户名之间的对应关系并保存。可保存在表中或LDAP中或文件系统中。当然要考虑这些系统之间的数据
同步问题。比较好的方式是找到用户在这些系统中的都存在的唯一信息（如员工号，MAIL地址，姓名等）。通过唯一信息实时到各个系统中去取认证所需要的信
息。就不需要考虑数据同步问题。比较实用。可以建立类似下面的表：密码可采用加密保存。  
create  table  sso_info         
(

user    varchar2(20),        /*用户名*/
app_name  varchar2(20),      /*应用系统*/
architect  varchar2(4),        /*应用系统的架构BS或CS*/
app_company  varchar2(50),                    /*用户所属分公司*/
app_department  varchar2(50),            /*用户所在的部门*/
app_user  varchar2(15),         
                  
   /*在该系统中的用户名*/
app_passwd  varchar2(15),    /*在该系统中的密码*/
app_cookie  varchar2(30),         
               
/*COOKIE名称*/
form_user  varchar2(20),         
                  
/*认证页面中FORM的用户名字段*/
form_passwd  varchar2(20),                    /*认证页面中FORM的密码字段*/
app_special    varchar2(20)                      /*其他*/
);
通过IFRAME或超连接方式集成目标系统，并进行SSO

通过IFRAME或超连接方式集成目标系统,并在URL中带上用户名和密码。如集成DOMINO可采用如下方式：  
或：
以上采用的是在HTTP中直接传递明码，为提高安全性，可采用HTTPS来传递用户名和密码。另外采用这种方式被集成的系统必须支持FORM方式认证。J2EE应用，DOMINO等都支持FORM认证。
这两种方式如果SSO成功，就自动进入目标系统的界面，如果实现会显示目标系统的登录界面。其效果图如下：

这
种方式，必须维护对应关系表，如上面的sso_info。更好的方式是提供界面，让最终用户自己维护这种对应关系，可模仿Compoze
portlets  for
lotus的做法，在用户第一次进入要与之做SSO的系统时，如DOMINO系统，显示一个界面，让用户自己输入他在该系统中的用户名/密码等信息。并
保存到表中或LDAP等其他数据源中。以后用户要进入这些系统时，就直接从表中或其他数据源中取用户的用户名/密码等信息，帮助用户做认证。建议采用这种
方式。如下图所示。如果用户改变了自己在DOMINO系统中的用户名，密码。从门户系统进入DOMINO系统时，认证会失败，就重新显示类似下面的界面。
让用户重新输入他在DOMINO系统中新的用户名，密码并保存。

以上这种实现方式，一般需要浏览器支持COOKIE，所以要注意浏览器的配置，在开发阶段，为方便调试，可设置IE，让它显示COOKIE的名称。如下所示：

采
用这种方式，对要集成的系统不需要做任何的改动。如果PORTAL系统中的用户在被集成的系统中的权限都一样，可采用建立一个通用用户的做法。也就是所有
在PORTAL系统中的用户都采用这个通用用户进入目标系统。这种方式等于是采用页面集成方式做集成。比较方便使用。另外，有时候需要采用调用API，或
配置Adapter等应用集成方式来集成其他系统，一般也是通过定义一个连接专用的用户。在API中或在配置Adapter的时候写死。如采用JAVA
API方式集成DOMINO：
lotus.domino.Session  dominoSession  =  NotesFactory.createSession(dominoServer,  “***”,  “password”);
CS结构实现方式
经
常有人问CS结构的应用如何实现SSO，本人的建议是对这种系统不要自己去实现SSO。很麻烦，其实输个用户名，密码没什么大不了的。如果要实现，一是采
用商业软件。另外也可以采用以下方式：在PORTAL的PORTLET上建立超连接。并通过APPLET方式启动CS结构的应用系统的登录界面。然后通过
如下的方式把用户名/密码传递过去。
-不能做任何改动的客户端  -  WIN消息（给登录窗口发送用户名，密码等登录所需要的信息）,模拟键盘（java有模拟键盘输入的API）
-可以做改动的客户端  -  参数传递，并让登录的EXE文件读取参数进行认证。
因为要让APPLET执行本地的EXE文件，所以必须对IE中的JRE的安全进行设置。   
其他：
在采用以上方式实现了SSO后，要注意LOGOUT，可采用与LOGIN相同的方式。也可以通过被集成系统的超时设置来实现。
               
               
               
               
               
               
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/24141/showart_242380.html