在讲单点登录之前，我们先来看看cookie与session :
cookie是通过浏览器保存在客户端的临时数据，一般这些数据对安全的要求不高，虽然可以通过加密存放和SSL方式提交的方式加强cookie的安全，但不代表cookie就是百分之百安全的。再者，写入太多的cookie会造成数据管理的不可控，所以建议尽量少写cookie，像网易、新浪这些大型互联网公司，如果观察一下他们的站点，你会发觉他们会在浏览器写下大量的cookie，不过他们内部一般会有一套严格的cookie写入和清理的管理规定.
cookie有两个很重要的属性:domain和path
domain告诉浏览器当前要添加的cookie的域名归属，如果没有明确指明则默认为当前域名，比如通过访问www.vinceruan.info添加的cookie的域名默认就是www.vinceruan.info,通过访问blog.vinceruan.info所生成的cookie的域名就是blog.vinceruan.info.
path告诉浏览器当前要添加的cookie的路径归属，如果没有明确指明则默认为当前路径，比如通过访问www.vinceruan.info/java/hotspot.html添加的cookie的默认路径就是/java/,通过blog.vinceruan.info/java/hotspot.html生成的cookie的路径也是/java/.
在清楚domain和path的生成规则后，我们需要知道浏览器在什么时候提交什么cookie到服务器，即浏览器是通过怎样的规则筛选cookie并提交到服务器的?
浏览器提交的cookie需要满足以下两点：
1.当前域名或者父域名下的cookie
而且
2.当前路径或父路径下的cookie
要满足以上两个条件的cookie才会被提交.举个例子：有4个cookie:
cookie1:[name=value, domain=.vinceruan.info path=/]
cookie2:[name=value, domain=blog.vinceruan.info path=/java/]
cookie3:[name=value, domain=www.vinceruan.info path=/]
cookie4:[name=value, domain=blog.vinceruan.info path=/]
当我访问blog.vinceruan.info时,
cookie1可以被提交，因为.vinceruan.info是blog.vinceruan.info的父域名. path路径也一致.
cookie2不能被提交，因为虽然domain是保持一致的，但是path不一致，当前访问的是/， 但是cookie2的path是/java/
cookie3不能被提交，因为虽然path是一致的，但是 www.vinceruan.info不是blog.vinceruan.info的父域名.
cookie4可以被提交，因为domain和cookie都严格保持一致.
这里需要注意的是, 在浏览器看来. www.vinceruan.info不是blog.vinceruan.info的父域名，而vinceruan.info才是blog.vinceruan.info的父域名， www.vinceruan.info也算是一个二级域名
所以如果我们需要在所有二级域名下共享islogin=1的cookie，用java代码如下：
Cookie c = new Cookie("islogin","1");
c.setDomain(" .vinceruan.info");//注意是以点号开头的.
c.setPath=("/");
response.addCookie(c);
如果要在所有的二级域名下的/java/路径下共享silogin=1的cookie,用java代码如下:
Cookie c = new Cookie("islogin","1");
c.setDomain(" .vinceruan.info");//注意是以点号开头的.
c.setPath=("/java/");
response.addCookie(c);
现在，我们了解下session机制的原理， session都是保存在服务器端的，而http连接是无状态的，那么服务器是如何在多次独立的http连接中为你维持同一个session呢？
这依赖于一个叫JSESSIONID的参数，这个参数可以从cookie或url获得，你如果你打开firebug，同时你的firefox是没有禁用cookie的，那么你刷新几次页面，你会看到浏览器提交的cookie中有一个叫JSESSIONID的key/value，这个就是会话ID，在这里你可以做一个试验，我们都知道firefox和IE 的cookie是不共享的，因此你在firefox下登录了，你用IE打开同一个网址，页面会显示你还处在未登录的状态，但是如果我在firefox下已经登录，并且拿到JSESSIONID的值，再到IE中输入url，并且加入JSESSION=.....的参数，你会发现，IE下也会显示我已经登录了。
这说明，如果我通过网络截除到了别人的JESSIONID，我就可以在服务器的会话还没过期前访问该站，如果对方还是处于登录状态的，我就可以修改对方资料甚至密码，多么可怕，当然这一切都是理论上的。
session什么时候被创建
一个常见的错误是以为session在有客户端访问时就被创建，然而事实是直到某server端程序(如Servlet)调用HttpServletRequest.getSession(true)这样的语句时才会被创建。
session何时被删除
session在下列情况下被删除：
A．程序调用HttpSession.invalidate()
B．距离上一次收到客户端发送的session id时间间隔超过了session的最大有效时间
C．服务器进程被停止:再次注意关闭浏览器只会使存储在客户端浏览器内存中的session cookie失效，不会使服务器端的session对象失效。
好了，一切都显得很顺利，要在不同的二级域名共享session，只需要把JESSIONID写进共享Cookie就行了。有时在进行session共享时，需要先设置session为无效，否则在设置domain为父域名时，会匹配不到
这里需要注意的是：当多个cookie提交到服务器端的时候，如果有多个JSESSIONID也被提交，服务器端会采取严格匹配更加优先的原则。
举个例子，如果我们在访问www.vinceruan.info新建了一个session的同时， 我写入一个JSESSIONID=****的、domain是.vinceruan.info的cookie, 理论上blog.vinceruan.info 也可以访问到在www.vinceruan.info这边创建的session了，但是，如果我在访问www.vinceruan.info前先访问了blog.vinceruan.info, 同时创建了属于blog.vinceruan.info的session，这是再去访问www.vinceruan.info站点，同时建立了另一个session，并且建立了共享的JSESSIONID，这时再回去访问blog.vinceruan.info时，你会看到浏览器提交了两个JSESSIONID的cookie，类似于：
JSESSIONID=EXAD2AD5FA4D1A5D4 path =/ domain=blog.vinceruan.info
JSESSIONID=254SD2S5S1D2S5DS5 path = / domain=.vinceruan.info
可以看出,后者是我手工创建的，而前者是jboss创建的。很遗憾，服务器匹配的是domain=blog.vinceruan.info 的JSESSIONID
SSO
1、什么是单点登录(single-sign-on)
举个例子，如果你登录了msn messenger，访问hotmail邮件就不用在此登录。
一般单点登录都需要有一个独立的登录站点,一般具有独立的域名，专门的进行注册，登录，注销等操作
我们为了讨论方便，把这个登录站点叫做站点P，设其Url为http://passport.yizhu2000.com，需要提供服务的站点设为A和B，跨站点单点登录是指你在A网站进行登录后，使用B网站的服务就不需要再登录
2、单点登录分类
跨子域单点登录
完全跨域单点登录
3、单点登录实现机制
实现SSO的技术主要有：
(1)session同步
(2）基于cookies实现，需要注意如下几点：如果是基于两个域名之间传递sessionid的方法可能在windows中成立，在unix&linux中可能会出现问题;可以基于数据库实现；在安全性方面可能会作更多的考虑。另外，关于跨域问题，虽然cookies本身不跨域，但可以利用它实现跨域的SSO。
(3) Broker-based（基于经纪人），例如Kerberos等；这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的"第三方"。例如Kerberos,Sesame,IBM KryptoKnight（凭证库思想)等。Kerberos是由麻省理工大学发明的安全认证服务，当前版本V5，已经被UNIX和Windows作为默认的安全认证服务集成进操作系统。http://www.ibm.com/developerworks/cn/security/se-sso/
(4) Agent-based（基于代理人）在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个"翻译"。例如SSH等。
(5) Token-based，例如SecurID,WebID，现在被广泛使用的口令认证，比如FTP,邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。
(6) 基于网关Agent and Broker-based，这里不作介绍。
(7) 基于安全断言标记语言（SAML）实现，SAML(Security Assertion Markup Language，安全断言标记语言）的出现大大简化了SSO，并被OASIS批准为SSO的执行标准。开源组织OpenSAML 实现了 SAML 规范。http://blog.csdn.net/shanyou/article/details/5372233
CAS由耶鲁大学开发的单点登录系统（SSO,single sign-on），应用广泛，具有独立于平台的，易于理解，支持代理功能。
下文主要介绍一种基于http重定向和票据，并以跨域Cookie的共享为核心的SSO，最后，分析下Sohu 完全跨域SSO登陆过程(在CAS外面包装了AJAX技术)
4、跨子域单点登录
所谓跨子域登录，A，B站点和P站点位于同一个域下面，比如A站点为http://blog.yizhu2000.com B站点为 http://forum.yizhu2000.com,他们和登录站点P的关系可以看到，都是属于同一个父域，yizhu2000.com,不同的是子域不同，一个为blog，一个为forum，一个是passport
我们先看看最常用的非跨站点普通登录的情况，一般登录验证通过后，一般会将你的用户名和一些用户信息，通过某一密钥进行加密，写在本地，也就是一个加密的cookie，我们把这个cookie叫做--票（ticket）。
需要判断用户是否登录的页面，需要读取这个ticket，并从其中解密出用户信息，如果ticket不存在，或者无法解密，意味着用户没有登录，或者登录信息不正确，这时就要跳转到登录页面进行登录，在这里加密的作用有两个，一是防止用户信息被不怀好意者看到，二是保证ticket不会被伪造，后者其实更为重要，加密后，各个应用需要采用与加密同样的密钥进行解密，如果不知道密钥，就不能伪造出ticket
跨子域的单点登录，和上述普通登录的过程没有什么不同，唯一不同的是写cookie时，由于登录站点P和应用A处于不同的子域，P站写入的cookie的域为passport.yizhu2000.net，而A站点为forum.yizhu2000.net，A在判断用户登录时无法读到P站点的ticket
解决方法非常简单，当Login完成后P站点写ticket的时候，只需把cookie的域设为他们共同的父域yizhu2000.net就可以了：cookie.setDomain(".yizhu2000.net");A站点自然就可以读到这个ticket了
5、完全跨域单点登录
完全跨域登录，是指A，B站点和P站点没有共同的父域，比如A站点为forum.yizhu1999.net,B站点为blog.yizhu1998.net，大家可以参考微软旗下的几个站点http://www.live.com，www.hotmail.com,这两个站点就没有共同的父域，而仍然可以共用登录，怎样才能实现呢？请参考下图，由于这种情况ticket比较复杂，我们暂时把P站点创建的的ticket叫做P-ticket，而A站点创建的ticket叫A-ticket，B的为B-ticket
6、完全跨域单点登录流程
当用户访问A站点上需要登录才能访问的资源时，A站点会首先查看是否有A-ticket，如果没有，证明用户没有在A站点登录过，不过并不保证用户没有在B站点登录，（重复一下，既然是单点登录，当然无论你在A，B任意一个站点登录过，另外一个站点都要可以访问,并且，站点A（forum.yizhu1999.com）不能读取到由站点P（passport.yizhu2000.com）创建的加密ticket），请求会被重定向到p站点的验证页面，验证页面读取P-ticket，如果没有，或者解密不成功，就需要重定向登录页面，登录页面完成登录后，写一个加密cookie，也就是P-ticket，并且重定向到A站点的登录处理页，并把加密的用户信息作为参数传递给这个页面，这个页面接收登录页的用户信息，解密后也要写一个cookie，也就是A-ticket，今后用户再次访问A站点上需要登录权限才能访问的资源时，只需要检查这个A-cookie是否存在就可以了
当用户访问B站点时，会重复上面的过程，监测到没有B-ticket，就会重定向到P站点的验证页面，去检查P-ticket，如果没有，就登录，有则返回B的登录处理页面写B-ticket
7、注销的时候需要删除P-ticket和A-ticket
创建一个和你要删除的cookie同名的cookie，并把cookie的expire设为当前时间之前的某个时间，不过在跨子域的删除cookie时有一点要注意：必须要把cookie的域设置为父域，在本文中为yizhu2000.com
Sohu SSO登陆过程分析
在http://passport.sohu.com/ 登录后 fiddler可以拦截到如下的返回信息：
由于passport.sohu.com的登录界面使用了iframe隐藏提交。所以页面没有看到刷新。隐藏的iframe把用户名和加密的password和其他信息发送给了passport.sohu.com。passport.sohu.com在Response中设置了成功登录的cookie。这个cookie可以证实这个用户成功登录了passport.sohu.com
当用户在Passport成功登录后。客户端的Javascript根据成功登录的标志，操作iframe请求http://passport.sohu.com/sso/crossdomain_all.jsp?action=login 因为在同一个域名下，没有跨域，在这次请求中，上次成功登陆的cookie会被一并带着回去。服务器端检查到成功登录的cookie后会Render回一段同时登录多个站点的html。
这段html 要向4个地址发送请求。截至到现在都是在相同的Domain(passport.sohu.com)请求和返回，为真正的跨站点登录做准备，真正的跨站点登录还没有开始。下面passport.sohu.com通过sso/crossdomain.jsp 在服务器端进行Redirect 设置http head 为302进行跳转。跳转后在这个跳转后的域名下设置登录成功的cookie。这就是sohu实现跨站点登录的核心过程。下面是passport.sohu.com登录17173.com的过程。
1. 通过http://passport.sohu.com/sso/crossdomain_all.jsp?action=login Render回来的script <script type="text/javascript" src="http://passport.sohu.com/sso/crossdomain.jsp?action=login&domain=17173.com"></script> 请求同域下的http://passport.sohu.com/sso/crossdomain.jsp?action=login&domain=17173.com 这时passport.sohu.com下成功登录的cookie会被带回去。
3. 17173.com从url的QueryString中取得信息。并在Response中设置Cookie。这个Cookie终于写到了17173.com下。而不是passport.sohu.com下。从而使得用户在17173.com下登录。其实用户在17173.com下手动登录也是写上同样的Cookie。以后用户再访问17173.com的页面时这个Cookie会被带回去。这就表示用户在17173.com下成功登录过了。
经过上面的步骤。用户在passport.sohu.com下登录的同时也在其他站点登录了。
完全跨域单点登录实现的核心思想：发送跨域请求，然后各自写各自的cookie。
具体实现有很多变种，上面sohu的例子只是其中一种，还可以参看京东单点登录的例子。
同时，为了保证安全性，建议使用https安全传输、绑定IP等
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
