[转]LoongSSO 大中型WEB系统单点登陆(SSO)整合利器

转载自: http://blog.chinaunix.net/space.php?uid=1760882&do=blog&id=93117

我们都知道网易、搜狐等大型门户都有“通行证”的概念，这个通行证系统就是今天讨论的“单点登录系统”。其主要特征是多个站点一个用户中心，一点登陆后其他也自动登录，注销也是。比如我们在126登录了邮箱，再去163.com就是登陆状态。就好比要建一个摩天大楼,打好地基是重点之重.看到SSO的重要性了吧.

下面我简单介绍一下国际一些名气比较大的SSO解决方案:

一. SAML

SAML，鸟语全名为Security Assertion Markup Language,他是由SUN、BEA、IBM、RSA、AOL、Boeing等大公司，制定技术规范相当专业有水准，系统分层合理，抽象了几个概念把整个系统描述得很清楚，使用流行技术XML Schema来描述协议，使用到了XML-Sign和XML Encrypt等较为前缘XML安全技术. 一看就会让你感觉望而生畏。用个形象性的比喻,SAML协议跟java一样，把每个层都分的很细.跟裹脚布一样.所以SAML技术在java领域用的比较多,在非java领域比较稀少了.sun的 open sso就是开源的SAML一种实现. 要想把opensso 搞定，那得要深厚的功力.自个修炼去吧

二. OpenID

OpenID实际上不属于SSO, 只是一种身份的认证而已。OpenID挺NB的,拥有众多大腕粉丝, 例如GOOGLE、YAHOO、Facebook，希望别人的系统使用它们的帐号登陆。他们希望一种足够简单的WEB SSO规范，于是选择一种草根网络协议OpenID。OpenID，名字取得好，顾名思义，一看就知道它是干嘛的。国内也有它的Fans，例如豆瓣网。openID的确足够简单，但是协议本身是不完善，可能需要一些补充协议才能够满足业务需求。例如GOOGLE采用OpenID + OAuth。目前支持OpenID有Yahoo、Google、Windows Live，还有号称要支持OpenID的Facebook。目前Yahoo和Google宣称对OpenID的支持，但是其实是有限制的，Yahoo的OpenID只有少数合作伙伴才能获得其属性，Google也只有在其Google Apps中才能获得账号的Attribute。用户账号毕竟是一个互联网公司的最宝贵资源，希望他们完全分享账号是不可能的。OpenId 作为一个所谓的“开源项目”，仿佛是人人都在为他服务，但是又好象人人都不给他服务。没有一个机构能够真正的去帮助别人熟悉和使用他

三. Oauth

OAUTH跟OpenID差不多实际不属于SSO范围.是用户身份权限制认证。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同发起的，目的在于为API访问授权提供一个开放的标准。OAuth规范的1.0版于2007年12月4日发布。目前在微博上应用比较多.

oAuth的典型应用场景（senario）

以前，用户在 拥有资源 的的网站A有一大堆东西；现在用户发现了一个新的网站B，比较好玩，但是这个新的网站B想调用 拥有资源的网站A的数据。

用户在 求资源的网站B 上，点击一个URL，跳转到 拥有 资源的网站A。

拥有资源的网站A提示：你需要把资源分享给B网站吗？Yes/No。

用户点击 Yes，拥有资源的网站A 给 求资源的网站B 临时/永久 开一个通道，然后 求资源的网站 就可以来拥有资源的网站 抓取所需的信息了。

oAuth更像是一种资源更像是一种网站资源的共享,而并不是用户数据的共享和一站登陆全站都登陆的机制.

四.CAS

CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目，据统计，大概每 10 个采用开源构建 Web SSO 的 Java 项目，就有 8 个使用 CAS 。Cas是java应用最广泛的开源单点登陆实现了。

国内的一些门户网站包括吃都是基于cookie SSO方案。浏览器直接请求SSO server进行身份验证,验证成功返回一段回调的JS代码。然后浏览器用js src逐个隐式的去访问sso client , sso client用P3P技术，把各个域名的cookie种在用户浏览器,这样就实现了整个SSO过程

   这种方式显而易见就是非常简单,比刚才介绍的任何一款SSO开源项目都简单方便. 但是这种方式的缺点，本人认为主要是两点：1. 子站点过多时，回调接口相应增多，这个在分布子站的量的限制上，如何控制来使登录效率不会太低，不好把握； 2. 当某个子站回调接口出现问题时，默认的登录过程会卡住（可以限制登录程序的执行时间，但相应出现问题子站后面的子站的回调接口就调不到了。

以下是大致的流程图

 

LoongSSO是2008年就开始发布的一款整体SSO开源解决方案。项目包括sso server(单点登陆)、session pool server.

Loongsso开源网站 http://www.loongsso.com

使用文档: http://www.loongsso.com/doc.html
论坛讨论: http://www.loongsso.com/bbs/

loongsso 作者 七夜(李锦星)
mail lijinxing@gmail.com
QQ 531020471
MSN lijinxing20@hotmail.com

LoongSSO2.1 下载地址
http://code.google.com/p/loongsso/downloads/detail?name=loongsso2.1.tar.bz2&can=2&q=

loongsso for Discuz api 下载地址
http://code.google.com/p/loongsso/downloads/detail?name=Discuz7.2.tar.bz2&can=2&q=

loongsso2.1 for phpwind API 下载地址
http://code.google.com/p/loongsso/downloads/detail?name=phpwind8.3.tar.bz2&can=2&q=

Loongsso server 大致介绍

1. 采用C开发,能稳定高效的运行在linux、freebsd等类*NIX系统下
2. 使用master-worker多进程工作模型再配合epoll、kqueue事件触发机制
3. 采用MySQL作为用户数据库,通过Handler Socket来进行读写mysql,既保证了用户数据的安全稳定,又提高了读写数据的效率
4. 采用简单易配置的xml配置文件
5. 使用HTTP协议交互,MD5数字签名,保证数据交互的方便性、安全性、高效性
6. 有保留关键注册名的功能
7. 对SSO client的编辑删除的权限控制

session pool server 大致介绍

1. 采用C开发,能稳定高效的运行在linux、freebsd等类*NIX系统下
2. 使用线程池工作模型再配合epoll、kqueue事件触发机制
3. 持久session保存数据,内部采用高效的hashtable来存储session数据
4. 采用haproxy作为入口网关,使用haproxy的一致性hash工作模式把请求分发给集群中的session server

loongSSO分为两种SSO工作模式
1. JS回调机制.Javascript回调各个SSO client，然后利用P3P协议种各自的cookie
2. 统一cookie机制.就是session id统一种植在SSO server所运行的域名cookie下.各个SSO client需要session id。都通过loongsso去查询

 

总结

第一种模式的优点和缺点上文已经大概的介绍过了，个人觉的缺点大于利,无法在几十个或者几百个域名下实现单点登陆。

    第二种模式,用户登录后是不用把用户登录的信息逐个通知给各个SSO client。当用户访问哪个SSO client，那个SSO client就会去loongsso server去读取。这样就保证了资源最大化的利用，就算成千上万个sso client都不成问题。当然loongsso server是可以分布式的运行的来支持更多的请求

DEMO 站点

http://sso2.weigame.com/             Discuz 论坛

http://sso3.dlapk.com/index.php?m=bbs  phpwind论坛

测试用户名: demo123 密码: 123456

在任何一端登陆,到另一个网站就无须登陆

 

 1. 用户浏览器请求www.bbb.com的login.html
2. Web server返回 login.html
3. 用户直接把表单POST到SSO server
4. SSO server根据用户名去mysql的用户库去验证
5. 数据库验证成功,生成session id,把session数据写到session pool server
6. Sso server 把session id种在sso server本域名下cookie
7. 用户访问www.bbb.com
8. www.bbb.com返回页面给用户浏览器.用户浏览器请求SSO server查询session id
9. SSO server返回session id给用户浏览器.
10. www.aaa.com用session id去session pool server查询session 用户数据
11. 根据session用户数据，生成www.aaa.com的cookie