作者：七夜
來源：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 [email protected]
QQ 531020471
MSN [email protected]
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.aaa.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