多系統實現單點登陸方案：SSO 單點登陸

1、什麼是單點登陸SSO（Single Sign-On）

　　SSO是一種統一認證和受權機制，指訪問同一服務器不一樣應用中的受保護資源的同一用戶，只須要登陸一次，即經過一個應用中的安全驗證後，再訪問其餘應用中的受保護資源時，再也不須要從新登陸驗證。

2、單點登陸解決了什麼問題

　　解決了用戶只須要登陸一次就能夠訪問全部相互信任的應用系統，而不用重複登陸。

3、單點登陸的技術實現機制

　　以下圖所示：

　　

認證後返回給應用系統而不是用戶

注（圖片所述存在的問題）：單點登陸對用戶而言是透明的，它 只是保證子系統之間是相互信任的，也就是說用於訪問子系統1，被引導到認證系統，獲得一個憑據，這個憑據並非返回給了用戶，而是給了子系統1，接着用戶 經過子系統1訪問子系統2，此次訪問會帶着剛纔的憑據，子系統2收到請求後，發現此次請求有憑據，與是用此憑據到認證系統進行驗證，驗證合法則准許訪問子 系統2，不合法引導到登錄界面。

 

　　　　當用戶第一次訪問應用系統1的時候，由於尚未登陸，會被引導到認證系統中進行登陸；根據用戶提供的登陸信息，認證系統進行身 份效驗，若是經過效驗，應該返回給用戶一個認證的憑據－－ticket；用戶再訪問別的應用的時候，就會將這個ticket帶上，做爲本身認證的憑據，應 用系統接受到請求以後會把ticket送到認證系統進行效驗，檢查ticket的合法性（4,6）。若是經過效驗，用戶就能夠在不用再次登陸的狀況下訪問 應用系統2和應用系統3了。

從上圖能夠看出sso的實現技術點：

　　1）全部應用系統共享一個身份認證系統。

　　　　統一的認證系統是SSO的前提之一。認證系統的主要功能是將用戶的登陸信息和用戶信息庫相比較，對用戶進行登陸認證；認證成功後，認證系統應該生成統一的認證標誌（ticket），返還給用戶。另外，認證系統還應該對ticket進行效驗，判斷其有效性。

　　2）全部應用系統可以識別和提取ticket信息

　　　　要實現SSO的功能，讓用戶只登陸一次，就必須讓應用系統可以識別已經登陸過的用戶。應用系統應該能對ticket進行識別和提取，經過與認證系統的通信，能自動判斷當前用戶是否登陸過，從而完成單點登陸的功能。

關於統一身份認證機制：以下圖

　   ①用戶請求訪問業務系統。

　　②業務系統在系統中查看是否有對應請求的有效令牌，如有，則讀取對應的身份信息，容許其訪問；若沒有或令牌無效，則把用戶重定向到統一身份認證平臺，並攜帶業務系統地址，進入第③步。

　　③在統一身份認證平臺提供的頁面中，用戶輸入身份憑證信息，平臺驗證此身份憑證信息，如有效，則生成一個有效的令牌給用戶，進入第④步；若無效，則繼續進行認證，直到認證成功或退出爲止。

　　④用戶攜帶第③步獲取的令牌，再次訪問業務系統。

　　⑤業務系統獲取用戶攜帶的令牌，提交到認證平臺進行有效性檢查和身份信息獲取。

　　⑥若令牌經過有效性檢查，則認證平臺會把令牌對應的用戶身份信息返回給業務系統，業務系統把身份信息和有效令牌寫入會話狀態中，容許用戶以此身份信息進行業務系統的各類操做；若令牌未經過有效性檢查，則會再次重定向到認證平臺，返回第③步。

　　經過統一身份認證平臺獲取的有效令牌，能夠在各個業務系統之間實現應用漫遊。

4、單點登陸的優勢

　　1）提升用戶的效率。

　　　　用戶再也不被屢次登陸困擾，也不須要記住多個 ID 和密碼。另外，用戶忘記密碼並求助於支持人員的狀況也會減小。 

　　2）提升開發人員的效率。

　　　　SSO 爲開發人員提供了一個通用的身份驗證框架。實際上，若是 SSO 機制是獨立的，那麼開發人員就徹底不須要爲身份驗證操心。他們能夠假設，只要對應用程序的請求附帶一個用戶名，身份驗證就已經完成了。 

　　3）簡化管理。

　　　　若是應用程序加入了單點登陸協議，管理用戶賬號的負擔就會減輕。簡化的程度取決於應用程序，由於 SSO 只處理身份驗證。因此，應用程序可能仍然須要設置用戶的屬性（好比訪問特權）。

5、單點登陸的缺點

　　1）不利於重構

　　　　由於涉及到的系統不少，要重構必需要兼容全部的系統，可能很耗時

　　2） 無人看守桌面

　　　　由於只須要登陸一次，全部的受權的應用系統均可以訪問，可能致使一些很重要的信息泄露。

6、登陸驗證分析

單點登陸SSO（Single Sign On）說得簡單點就是在一個多系統共存的環境下，用戶在一處登陸後，就不用在其餘系統中登陸，也就是用戶的一次登陸能獲得其餘全部系統的信任。單點登陸在 大型網站裏使用得很是頻繁，例如像阿里巴巴這樣的網站，在網站的背後是成百上千的子系統，用戶一次操做或交易可能涉及到幾十個子系統的協做，若是每一個子系 統都須要用戶認證，不只用戶會瘋掉，各子系統也會爲這種重複認證受權的邏輯搞瘋掉。實現單點登陸說到底就是要解決如何產生和存儲那個信任，再就是其餘系統 如何驗證這個信任的有效性，所以要點也就如下幾個：

• 存儲信任
• 驗證信任

只要解決了以上的問題，達到了開頭講得效果就能夠說是SSO。最簡單實現SSO的方法就是用Cookie，實現流程以下所示：

否則發現以上的方案是把信任存儲在客戶端的Cookie裏，這種方法雖然實現方便但立馬會讓人質疑兩個問題：

• Cookie不安全
• 不能跨域免登

對於第一個問題通常都是經過加密Cookie來處理，第二個問題是硬傷，其實這種方案的思路的就是要把這個信任關係存儲在客戶端，要實現這個也不必定只能用Cookie，用flash也能解決，flash的Shared Object API就提供了存儲能力。

通常說來，大型系統會採起在服務端存儲信任關係的作法，實現流程以下所示：

以上方案就是要把信任關係存儲在單獨的SSO系統（暫且這麼稱呼它）裏，提及來只是簡單地從客戶端移到了服務端，但其中幾個問題須要重點解決：

• 如何高效存儲大量臨時性的信任數據
• 如何防止信息傳遞過程被篡改
• 如何讓SSO系統信任登陸系統和免登系統

對於第一個問題，通常能夠採用相似與memcached的分佈式緩存的方案，既能提供可擴展數據量的機制，也能提供高效訪問。對於第二個問題，通常 採起數字簽名的方法，要麼經過數字證書籤名，要麼經過像md5的方式，這就須要SSO系統返回免登URL的時候對需驗證的參數進行md5加密，並帶上 token一塊兒返回，最後需免登的系統進行驗證信任關係的時候，需把這個token傳給SSO系統，SSO系統經過對token的驗證就能夠辨別信息是否 被改過。對於最後一個問題，能夠經過白名單來處理，說簡單點只有在白名單上的系統才能請求生產信任關係，同理只有在白名單上的系統才能被免登陸。

以上只是提供了些簡單的實現技術，但須要強調的是這只是技術實現而已，僅僅是爲了解決上面談到的一些問題，SSO自己來講並非什麼高科技，有了這個認識比較有利於咱們深刻探索SSO。

參考地址：

http://www.cnblogs.com/yupeng/archive/2012/05/24/2517317.html，

http://blog.csdn.net/cutesource/article/details/5838693