我对sso的使用和实现

原创
2014/02/14 11:15
阅读数 3K

我对sso的使用目前有三个阶段。

1.使用cas

cas的好处自行搜索,缺点就是需要性能、维护、负载,如果cas宕机,从逻辑上来说就是所有的系统全部宕机了。
当然你可以维护集群,那就麻烦了。这个不符合我的设计理念。

2.扩展tomcat,session共享并实现sso
2011年的实现方案,目前在生成环境运行,比较稳定。缺点就是绑定容器了。
具体参见:tomcat 使用 memcached管理session ,并且实现统一登录

3.web应用session共享,和容器脱离并实现sso
2013年的实现方案,由方案2进化而来,目前在生产环境运行,并逐步替换方案2,详细实现参见springrain,通过shiro和redis实现应用级别的session共享,和容器脱离。sso部分和方案2雷同

关于统一登录sso,如果跨域名,可以通过iframe创建不同域名下的jsessionid.跨语言可以通过jsessionid直接从memcached/redis中查找当前用户的登陆信息,我目前是开了一个服务(jsp页面)让第三方系统调用.在同一个浏览器中打开,可以获取jsessionid作为参数传递.每个业务应用,jsessionId就相当于cas的ticket.

我的理念是:认证即应用,因为每台业务应用都可以具有sso认证功能,只要还有一台业务应用在线sso认证服务就在线。

 

 

展开阅读全文
打赏
0
31 收藏
分享
加载中
你好,请问这句如何理解:
"通过iframe创建不同域名下的jsessionid"
我是这样想的,如果a.com域名(php应用)下的一个页面嵌入一个b.com域名(Java应用)的iframe。php应用可以访问到iframe中的cookie jsessionid么,貌似没权限吧?
2015/12/28 14:45
回复
举报
能详细一点吗
2014/05/17 15:45
回复
举报
springrain在SSO这块,在代码层面怎么体现,可以写篇文章,详细说明
2014/03/20 16:16
回复
举报
光石头博主

引用来自“黄勇”的评论

我也不太建议与容器绑死,您的第三个阶段非常好,通过 jsessionid 从 memcached/redis 中获取用户登录信息,不错!但我有个疑问,如果系统较多的情况下采用这种方案,势必会引起一个高并发问题,不知道容错性与健壮性怎么样了?

web应用本身就是集群负载,因为session共享可以直接横向扩展,redis也可以做集群和负载。web应用都会具有认证功能。
2014/02/14 11:52
回复
举报
我也不太建议与容器绑死,您的第三个阶段非常好,通过 jsessionid 从 memcached/redis 中获取用户登录信息,不错!但我有个疑问,如果系统较多的情况下采用这种方案,势必会引起一个高并发问题,不知道容错性与健壮性怎么样了?
2014/02/14 11:46
回复
举报
赞个
2014/02/14 11:22
回复
举报
更多评论
打赏
6 评论
31 收藏
0
分享
返回顶部
顶部