转载自:芋头的故事 http://yuwang881.blog.sohu.com/3632369.html
该作者是《编写你自己的单点登录(SSO)服务》的作者,参考详细的SSO技术介绍:http://developers.sun.com.cn/blog/yutoujava/entry/20070413
一、跨domain的SSO
在我写了SSO的文章以后,有几个网友希望我能提一提跨domain的SSO的实现方法。其实,它的实现方法有很多,如果不象JES Access Manager那样要考虑性能和安全性的问题,我下面可以给出很简单的解决方案。
跨domain的SSO的主要难点在于浏览器如何设置不同domain的cookie。所有的cookie都有一个范围,叫domain,如“.sun.com”。这个范围规定了只有在访问相同domain的时候,浏览器才会将此cookie带上。因此,如果SSO服务的domain和Web应用的domain不相同的情况下,就算当前浏览器已经登录过SSO的服务,Web应用的Agent(Filter)也不能知道。因为SSO服务给此浏览器设置的cookie是Domain A的,在访问domain B的时候,这个cookie是不会带去的。
另外,在servlet的API中,在设置cookie的时候是可以选择此cookie生效的domain--setDomain()方法。知道这个以后,请看下图的解释
如上图,我们只需要将SSO服务稍微改动就能完成跨domain的SSO的功能。
让我们一步步来看是如何实现的:通过步骤1、2,假设我们访问过Domain A中的应用1,并且登录了SSO,获得了Domain A的cookie。步骤3在访问Domain B的应用2的时候,显然此Web应用2的Agent不会发现这个cookie,因为这是Domain B。
步骤4,Web应用2的Agent给浏览器发出重新定向到SSO登录页面的指令(详细过程和原理请阅读文章本身)。步骤5,浏览器去访问SSO的登录页面。到此为止,和原来的实现过程都没有什么变化。
但是,SSO在返回给浏览器登录页面之前,可以执行一个附加的操作,检查一下当前请求是否带有cookie。值得注意的是,在这次访问当中,浏览器的确是将先前登录成功的cookie带来了,因为这是Domain A。在这个附加的操作中,我们可以去判断这个cookie是否真的有效。
如果这个cookie真的有效,这个附加的操作需要做的是给浏览器再设置一个cookie,cookie的名字和数值都和原来一样,domain的范围设置为"Domain B",并且让浏览器重新定向到刚才的请求上(Web应用2的请求)。这个请求的URL可以从“goto”的参数中获得(详细过程和原理请阅读文章本身)。
浏览器再次访问Web应用2的时候,它所希望的cookie就已经在了。
从用户的角度说,可能会发现浏览器有几次闪动和交互,但这都是自动的。
话外话:
自从该作者(java方向)
发表一篇有关SSO的文章: 请参见芋头技术博客文章的URL:http://211.151.94.21/blog/yutoujava/。文章中不但对SSO有详细的解释,还给出了一个初具规模的实现和对源码的详细解释。
我有同事担心,一旦发表以后会不会有客户就不使用我们公司的SSO的产品Access Manager了,而转而自己开发了。但我觉得不会,原因有:
- 本文虽然有源码,但是也指出了当前实现的局限性,需要完整、完善的方案还需要大量的工作和投入
- Sun公司的产品本来也免费,没有必要再开发
- 这片文章虽然没有提到任何产品的信息,但对理解Access Manager是有好处的。