一、初步方案
最近公司要开发新版系统，有幸和几个组员第一时间进入新版的用户中心的开发，按照公司的要求，新版的用户中心要实现单点登录，建议不使用SESSION，以减轻服务端维护SESSION的成本。于是考虑使用cookie+cache来维护会话，实现单点登录。
但是由于系统存在WAP客户端，不能使用COOKIE，使用COOKIE+cache的方案似乎无法得到解决，而WAP客户端中又存在两个应用，简版和3G彩版，进一步讨论之后，决定WAP之间与WEB之间不同步登陆状态。但是WAP端各应用要进行登录状态同步。
于是出来一个初步的方案，在WEB客户端端使用cookie+cache,在WAP客户端端依然使用session+cache实现单点登录，无论是WEB客户端或者WAP客户端，都调用后台发布的服务，本身并不直接连接数据库，后台服务组集群管理集中式的缓存，各个客户端维护自身的缓存。
1、缓存组件的选择
由于存在WEB端与WAP端，应用都在集群环境中，所以使用一个好的分布式缓存似乎也是项目稳定性的关键，Terracotta+ehcache是个不错的选择，由于hibernate官方推荐的第三方缓存组件是ehcache,如果服务端已经使用了ehcache作为hibernate缓存组件，再对系统进行分布式缓存集成Trracotta，那就显得非常的简单。但我们是开发新的项目，而使用集中式缓存管理策略对分布式缓存的效率和缓存服务器扩展有一定的好处，于是决定采用memcache进行缓存服务器的搭建。
2、会话维护与过期所存在的问题
使用SESSION登录会比较简单，server端可以设置session的过期时间。
而使用COOKIE设置过期时间，浏览器会将COOKIE数据写入硬盘上保存，这时即使用户关闭浏览器，COOKIE文件还未到过期时间还是保存在硬盘上，这就存在一些不安全的隐患，但是如果设置COOKIE的过期时间为一个小于0的数值，则COOKIE保存在客户端的内存中，这样，用户只要不关闭浏览器，COOKIE就不会失效，也会存在一些安全隐患。
用户会话的cache信息也将会有问题，由于cache在创建的时候就会有一个创建时间，创建之后，根据配置的缓存策略来管理缓存元素。cache一旦创建，只要到了配置的过期时间，就一定会销毁缓存元素，这样，客户端的会话即使依然真实存在，也无法通过cache来获取用户的数据，用户的登录状态也将消失。
3，会话维护与过期存在问题的解决方案
使用COOKIE进行会话的维护，为了使得COOKIE的信息尽量的保密和安全，需要对COOKIE进行加密，而由于COOKIE的会话的设计依然存在一些问题，所以使用另外一种方案对COOKIE进行设计，用户登录时，生成一个名为SSO_LOGIN的cookie，此COOKIE保存三个信息，用户名|生成时间|加密数据。用户登录时，将用户名+生成时间+密钥进行MD5加密，然后将用户名，生成时间和MD5的加密数据连起来作为cookie的VALUE值写入客户端，并将COOKIE的过期值设置为负数(关闭浏览器失效)，通过后台发布的服务将用户信息写入中心缓存中，这样，用户每进行一次请求，都直接从中心缓存中获取用户信息。当用户客户端的COOKIE失效时，让用户进入登陆流程；当中心缓存中无用户信息时，也让用户进入登陆流程。这样就必须保证用户在活动期间，中心缓存中的用户信息不能过期，有两种解决方案，一是设置缓存策略时间较长，如果用户数比较多，无疑会较大程度的提高服务器管理缓存所花的成本。第二种方案，用户每获取一次信息，则更新一次缓存，将用户信息的缓存策略的过期时间设置和COOKIE的过期时间一致。虽然也在一定程度上提高了缓存管理的成本，但是笔者认为第二种比第一种要好一些。
4，总结
通过以上的分析，可以总结出来整个单点登录的过程：WEB客户端，用户登录时，生成COOKIE和中心缓存，用户每进行一次请求，首先取出COOKIE，验证加密数据；其次取出COOKIE的生成时间与现在的时间进行对比，验证是否过期；再次，若验证通过则调用服务获取缓存中的用户信息并刷新缓存的生成时间，若验证不通过或者过期，则进入用户登录流程；最后，获取到用户信息之后，刷新COOKIE的生成时间，重新写入COOKIE到客户端。这样只要用户的浏览器中存在相关的COOKIE并没有过期（用户关闭浏览器或者在超过设置COOKIE的有效期），则在该域名的路径下面所有的项目都可以获取到用户登录状态和信息。
而WAP端的SSO登录将变得更为简单，用户登录之后，获取服务器分配给用户浏览器的SESSIONID，将SESSIONID作为KEY值，用户信息作为VALUE值生成中心缓存，这样用户访问该域名下的所有的应用，只要使用的是同一个浏览器(SESSIONID无变化)，并且在SESSION的有效期内，都可以获取用户信息，同步登录信息，实现单点登录。