J2EE和Domino系统间跨域SSO的实现.docVIP

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请求域（）一致或为上级域（）时，Cookie才能生效。 也就是说： 若A、B系统域名分别为和，登录系统A，同时写来自两个系统的Cookie到浏览器，且Cookie的domain设为.，那么浏览器是可以接受的，SSO成功。 若A、B系统域名分别为和，登录系统A，同时写来自两个系统的Cookie到浏览器，其中A Cookie的domain设为.，B Cookie的domain设为.，那么浏览器是不可以接受B Cookie的，因为该HTTP请求是来自.，因此不能写.域中的Cookie。 这也就是跨域SSO难题的原因所在。 2.4. 跨域SSO 了解了Cookie的局限和跨域SSO难题所在，也就不难找到解决跨域问题的办法了：由各应用系统中创建各自域的Cookie并返回给浏览器。不要幻想在一个应用中创建所有域的Cookie，这是徒劳的。 至于如何一次性在各应用系统中创建各自域的Cookie并返回给浏览器，这就仁者见仁智者见智了，一般常见的做法是： 在SSO验证成功的返回页中利用JS脚本动态创建隐藏的IFRAME，并将验证信息通过IFRAME的SRC属性的URL参数传递给各应用系统的某个资源，这些资源可以是动态程序也可以是JS脚本，由各应用系统的动态程序或JS脚本根据传入的参数来完成该应用的验证过程并返回验证通过的Cookie。 下文说的做法与上略有不同，我的想法是：只在请求哪个应用系统时才进行哪个应用系统的身份验证，而不是一次性全将所有身份都验证完毕。 3. Domino SSO 实现 Domino 的用户信息和身份验证是通过目录（NAMES.NSF ）来实现的；J2EE 系统也往往有自己开发的用户管理和身份验证机制。要实现二者的SSO ，可以通过部署统一的身份认证应用来完成。 要部署唯一的SSO 应用有三个选择： l 扩展Domino 的身份认证功能，提供SSO 服务； l 扩展J2EE 系统的身份认证功能，提供SSO 服务； l 部署单独的SSO 应用，提供SSO 服务； Domino 的身份认证在names.nsf 中进行，登录界面在dom