1. SSO需求
单点登录（Single Sign On, SSO）是企业应用集成中最常见的需求。异构系统间往往都有各自的用户管理和身份验证机制，为
避免用户在进行系统切换时频繁输入用户名和密码，因此必须要实现单点登录。
2. SSO原理
说到SSO的原理，先得说一般Web应用的身份验证原理。Web身份验证之所以能成为问题主要在于HTTP协议的无状态性，这导
致了每次HTTP的请求和响应的无关性。而应用的状态保持是大部分应用系统的一般性需求，因此必须借助其他机制，这就是Cookie。
2.1. Cookie的原理
一个Cookie由name、value、domain、path、expires组成。可以给HTTP响应添加Cookie，然后Cookie就作为HTTP响应的
Headers返回给浏览器，例如Domino的登录成功后的Cookie响应头为：
Set-Cookie: DomAuthSessId=1AD479C4D11CD10278A4C523320A6918; path=/
没有设置expires就表示仅在当前浏览器进程生命期内有效，不保存到客户机上；若expires时间大于当前时间，则浏览器在收到
这个 Cookie以后将其写入到客户机文件中，一般是保存在C:\Documents and Settings\Administrator\Cookies\下。
没有设置domain就表示只在当前域内有效。
当客户机再次请求该域内的其他资源时，浏览器会自动将该域内的Cookie附在请求的Headers一起发送给Web服务器，形如：
Cookie: DomAuthSessId=1AD479C4D11CD10278A4C523320A6918
如此Web应用就能够通过读取HTTP请求Headers里面的Cookie值来判断用户身份，这样也就间接实现了HTTP的状态保持需
求。
2.2. SSO原理
了解的Cookie的原理以后就不难理解SSO的原理了。SSO的目的是为了实现两个或多个应用系统间的单点登录，其实现手段无
非是在登录A系统的 同时自动登录到B系统、C系统……，结合Cookie也就是说在SSO登录时同时去A系统、B系统、C系统进行验证，并将来自各系统的Cookie返回给 浏览器，就是这么简单。
一般情况下，做SSO要统一登录界面，这可以通过将各应用系统的登录界面重定向到指定的登录页来实现。
2.3. Cookie的局限
如果仅仅如上所说这么简单，那也就不会创造什么SSO的概念了。问题出在Cookie的domain上。出于浏览器安全的考虑，HTTP响应 Headers中的Cookie的domain只有与HTTP请求域（a.abc.com）一致或为上级域（abc.com）时，Cookie才能生效。
也就是说：
若A、B系统域名分别为a.abc.com和b.abc.com，登录系统A，同时写来自两个系统的Cookie到浏览器，且Cookie的domain设为.abc.com，那么浏览
替换字节数组流和管道流
文档选项
<tr
valign="top"><td width="8"><img alt="" height="1" width="8"
src="//www.ibm.com/i/c.gif"/></td><td width="16"><img alt="" width="16"
he ......
