跨domain的SSO

转载自：芋头的故事 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了，而转而自己开发了。但我觉得不会，原因有：

1. 本文虽然有源码，但是也指出了当前实现的局限性，需要完整、完善的方案还需要大量的工作和投入
2. Sun公司的产品本来也免费，没有必要再开发
3. 这片文章虽然没有提到任何产品的信息，但对理解Access Manager是有好处的。