对《多站点整合—单点登录简单方案》的一点补充

前两天看到一个帖子《多站点整合—单点登录简单方案》，一直没顾得上回复。我想，Sohu并不仅仅为了“需要设计一个统一的登录界面”而考虑，它在安全性、授权机制上下了很大功夫。在这里对作者Zesson的分析做一些补充。<o:p></o:p>

需要统一登录界面是SSO（Single Sign On）的一个典型场景，此外相关的还有认证，同步，授权与统一登出等等，最为复杂的往往是同步，授权这两个环节。SSO直译过来叫单点登录，是对Portal这个继续流行的企业业务整合方案的另一种称谓。由于整合范围和技术不同，主要有Web层单点登录、跨越Web层单点登录（Web与传统系统），传统系统单点登录（Portal）等等。<o:p></o:p>

记得2004年在做某单位的Protal系统时，因为要整合很多来自不同编程语言（PB，VB，Dephi），不同编程时期的程序，遇到很多极为棘手的问题，调整方案往往对现有系统造成伤筋动骨的伤害，或者根本就是重做，最后系统也不了了之。而现在在Web层实现单点登录相较就简单了很多，比如在我们建立的Portal页面上有每个网站的链接，用户点击这些链接就可以了。<o:p></o:p>

<o:p> </o:p>

J，当然还有更好的形式，我们先回顾一下基础知识。<o:p></o:p>

因为HTTP 协议是无状态的，我们想在Web开发中维持服务器段的应用状态可以利用Session。而基于Web的身份验证实质是用户在表单中输入用户名和密码后提交，服务器从Request中提取用户名和密码，通过第一次验证后用Session来存储客户的登录信息。以后每次Request过来时，便从Session中读取这些信息，如果有则进入相应界面，没有则认为未登录。<o:p></o:p>

而Cookie特性则帮助我们在客户端维持状态。服务器在HTTP的Response头上加上一行以提示浏览器按照指示生成相应的Cookie。Cookie主要有名字，值，过期时间，路经和域这些字段。浏览器会按照一定的时间原则在后台自动发送给服务器，如果Cookie声明的作用范围大于等于将要请求的资源所在位置，则把该Cookie附在Request头上。<o:p></o:p>

如果设置了Cookie的有效期，浏览器就会把Cookie保存到硬盘上，这个Cookie可以在不同的浏览器中实现共享。如果不设置有效期或者设置为负数，这个Cookie将保存在内存中。对于内存中的Cookie，IE与同一IE新建窗口的进程可以共享，而与其它方式打开的（如“我的电脑”）IE进程则不能共享；JavaScript的window.open打开的窗口可以与原窗口共享；FireFox的进程或标签页可以共享。关闭浏览器，内存中的Cookie就终止了。<o:p></o:p>

服务器端为每一个Session编号，以便提取与某个具体的交互过程相关的Session，同时也需要在客户端保存编号以区分具体的交互过程，这样便可以利用Cookie。 如果浏览器设置为禁用Cookie，服务器可以利用Request的提交来维持Session在客户端的标志。在地址栏中看到类似于JSessionID=xxxxxxxx的就是Get方式，服务器在返回请求时总是将与该交互过程相关的SessionId追加到URL上，以保持状态。也可以在返回的HTML的Form表单中追加hidden，将Session标志放进去，Form提交往往是Post方式。浏览器关闭时并不会通知服务器，如果Cookie保存在硬盘上，那么关掉浏览器再打开还会继续前面的Session。因此服务器端需要对Session设置一个期限，多长时间未收到客户端的请求将让Seesion实效。<o:p></o:p>

综上，如果浏览器登录过某Web系统，服务器端生成了Session，客户端的Cookie中记录了SessionId，浏览器没有关闭，即使使用内存中的Cookie，访问其它Web系统再回来只要Session没有失效，服务器还是会认为登录是有效的。因此利用Cookie便可以达到SSO。浏览器登录Web A的页面后生成一个Cookie，再访问Web B的页面时通过访问服务器端通过Cookie就可以判断该客户段是否已成功登录。基于这样思路的就是SSO的Agent方式。<o:p></o:p>

<o:p> </o:p>

目前SSO有两种主流实现方案，Agent和Proxy。如果是非跨域的情况，还有共享Session的方式，如WebLogic和金蝶。<o:p></o:p>

Agent方式是，增加一台SSO认证服务器，然后在每一个Web应用系统上安装一个Agent，由它访问SSO认证服务器来实现统一的身份验证和访问控制。SSO认证服务器存储了各Web应用系统的用户之间的映射方式。这样的缺点是必须改造现有系统。<o:p></o:p>

一次SSO过程大致为：<o:p></o:p>

1．  用户第一次访问Web A的页面<o:p></o:p>

2．  Web A发现用户未登录<o:p></o:p>

3．  Web A 调用AgentA<o:p></o:p>

4．  AgentA将页面转向SSO Auth<o:p></o:p>

5．  SSO Auth 返回登录页面<o:p></o:p>

6．  用户输入用户名密码提交<o:p></o:p>

7．  SSO Auth验证密码成功<o:p></o:p>

8．  SSO Auth调用AgentA的URL传递帐号信息<o:p></o:p>

9．  AgentA解密帐号信息，传送给Web A<o:p></o:p>

10． Web A进行授权，返回原来请求的页面<o:p></o:p>

11． 用户访问Web B<o:p></o:p>

12． Web B发现用户未登录，调用AgentB<o:p></o:p>

13． AgentB将页面转向SSO Auth<o:p></o:p>

14． SSO Auth发现用户已经登录<o:p></o:p>

15． SSO Auth调用AgentB的URL传递帐号信息<o:p></o:p>

16． AgentB解密帐号信息，传送给Web B<o:p></o:p>

17． Web B进行授权，返回原来请求的页面<o:p></o:p>

由于第5步与第14步都是在同一域下进行的，因此可以直接访问浏览器中的Cookie，以验明正身，不存在跨域取Cookie的问题。<o:p></o:p>

Proxy方式有时也称之为Gateway，即通过DNS将多个系统的域名配置在一个承担SSO的Proxy Server上，同时还需要一个LDAP服务器。用户对各Web系统的访问首先被定向在Proxy Server，Proxy Server发现用户未登录，返回自己的登录页面。用户提交用户名密码，Proxy Server根据LDAP服务器查询原有系统的用户名和密码，再Post给用户访问的原系统。<o:p></o:p>

<o:p> </o:p>

看了Zesson的分析数据，我认为：<o:p></o:p>

1．  Sohu使用的是Agent方式，但是对它有一些改动，不需要独立安装，在现有系统扩充一些代码就可以。<o:p></o:p>

2．  它的认证服务器映射了用户信息但不做验证，登录的验证由每个网站自己维护，在登录成功后通知其他网站（登录成功后在页面上生成每个Web系统的Token URL作为ticket）。<o:p></o:p>

3．  出于安全考虑，URL中只存放Token，不会存放用户相关的信息。<o:p></o:p>

Sohu SSO可能的过程如下：<o:p></o:p>

1．  用户登录Sohu的Passport的login，提交用户名密码<o:p></o:p>

2．  Sohu login验证登录成功后返回，生成脚本http://passport.sohu.com/sso/crossdomain_all.jsp?action=login，刷iframe以来准备调用Agent<o:p></o:p>

3．  Crossdomain_all回写/sso/crossdomain.jsp?action=login&domain=17173.com， 页面刷iframe调用Agent<o:p></o:p>

4．  Sohu Agent将登录信息传递给 SSO<o:p></o:p>

5．  SSO 生成Token或者包含Token的URL，返回Sohu Agent<o:p></o:p>

6．  Sohu Agent 将调用其它网站Agent的URL传给页面，如pass.17173.com/sso/setcookie.jsp?passport= xxxxxxxxxxxx<o:p></o:p>

7．  页面刷iframe，调用17173的Agent<o:p></o:p>

8．  17173 Agent将Token（就是那个passport）传递给SSO获取验证<o:p></o:p>

9．  SSO返回验证成功及17173用户信息<o:p></o:p>

10． 17173 Agent调用17173登录模块进行授权<o:p></o:p>

11． 17173登录模块在响应中设置Cookie<o:p></o:p>

在这里认为Sohu有统一认证的证据是，调用其它网站时所用的passport是一致的。<o:p></o:p>

由于前期开发时是各自为政（如Sohu和Chinaren），系统都有各自的认证和授权，后来合并后提取统一的方式比较困难，便使用了现在这种既灵活，侵入性也不大的方案。