單點登陸SSO的實現原理 （轉）

單點登陸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://blog.csdn.net/cutesource/article/details/5838693  謝！

 

 

1 什麼是單點登錄

單點登陸（Single Sign On），簡稱爲 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。

較大的企業內部，通常都有不少的業務支持系統爲其提供相應的管理和IT服 務。例如財務系統爲財務人員提供財務的管理、計算和報表服務；人事系統爲人事部門提供全公司人員的維護服務；各類業務系統爲公司內部不一樣的業務提供不一樣的 服務等等。這些系統的目的都是讓計算機來進行復雜繁瑣的計算工做，來替代人力的手工勞動，提升工做效率和質量。這些不一樣的系統每每是在不一樣的時期建設起來 的，運行在不一樣的平臺上；也許是由不一樣廠商開發，使用了各類不一樣的技術和標準。若是舉例說國內一著名的IT公司（名字隱去），內部共有60多個業務系統，這些系統包括兩個不一樣版本的SAP的ERP系統，12個不一樣類型和版本的數據庫系統，8個不一樣類型和版本的操做系統，以及使用了3種不一樣的防火牆技術，還有數十種互相不能兼容的協議和標準，你相信嗎？不要懷疑，這種狀況其實很是廣泛。每個應用系統在運行了數年之後，都會成爲不可替換的企業IT架構的一部分，以下圖所示。

隨 着企業的發展，業務系統的數量在不斷的增長，老的系統卻不能輕易的替換，這會帶來不少的開銷。其一是管理上的開銷，須要維護的系統愈來愈多。不少系統的數 據是相互冗餘和重複的，數據的不一致性會給管理工做帶來很大的壓力。業務和業務之間的相關性也愈來愈大，例如公司的計費系統和財務系統，財務系統和人事系 統之間都不可避免的有着密切的關係。

爲了下降管理的消耗，最大限度的重用已有投資的系統，不少企業都在進行着企業應用集成（EAI）。 企業應用集成能夠在不一樣層面上進行：例如在數據存儲層面上的「數據大集中」，在傳輸層面上的「通用數據交換平臺」，在應用層面上的「業務流程整合」，和用 戶界面上的「通用企業門戶」等等。事實上，還用一個層面上的集成變得愈來愈重要，那就是「身份認證」的整合，也就是「單點登陸」。

一般來講，每一個單獨的系統都會有本身的安全體系和身份認證系統。整合之前，進入每一個系統都須要進行登陸，這樣的局面不只給管理上帶來了很大的困難，在安全方面也埋下了重大的隱患。下面是一些著名的調查公司顯示的統計數據：

• 用戶天天平均 16 分鐘花在身份驗證任務上 - 資料來源： IDS
• 頻繁的 IT 用戶平均有 21 個密碼 - 資料來源： NTA Monitor Password Survey
• 49% 的人寫下了其密碼，而 67% 的人不多改變它們
• 每 79 秒出現一塊兒身份被竊事件 - 資料來源：National Small Business Travel Assoc
• 全球欺騙損失每一年約 12B - 資料來源：Comm Fraud Control Assoc
• 到 2007 年，身份管理市場將成倍增加至 $4.5B - 資料來源：IDS

 

使用「單點登陸」整合後，只須要登陸一次就能夠進入多個系統，而不須要從新登陸，這不只僅帶來了更好的用戶體驗，更重要的是下降了安全的風險和管理的消耗。請看下面的統計數據：

• 提升 IT 效率：對於每 1000 個受管用戶，每用戶可節省$70K
• 幫助臺呼叫減小至少1/3，對於 10K 員工的公司，每一年能夠節省每用戶 $75，或者合計 $648K
• 生產力提升：每一個新員工可節省 $1K，每一個老員工可節省 $350 �資料來源：Giga
• ROI 回報：7.5 到 13 個月 �資料來源：Gartner

 

另外，使用「單點登陸」仍是SOA時代的需求之一。在面向服務的架構中，服務和服務之間，程序和程序之間的通信大量存在，服務之間的安全認證是SOA應用的難點之一，應此創建「單點登陸」的系統體系可以大大簡化SOA的安全問題，提升服務之間的合做效率。

2 單點登錄的技術實現機制

隨着SSO技術的流行，SSO的產品也是滿天飛揚。全部著名的軟件廠商都提供了相應的解決方案。在這裏我並不想介紹本身公司（Sun Microsystems）的產品，而是對SSO技術自己進行解析，而且提供本身開發這一類產品的方法和簡單演示。有關我寫這篇文章的目的，請參考個人博客（http://yuwang881.blog.sohu.com/3184816.html）。

單 點登陸的機制實際上是比較簡單的，用一個現實中的例子作比較。頤和園是北京著名的旅遊景點，也是我常去的地方。在頤和園內部有許多獨立的景點，例如「蘇州 街」、「佛香閣」和「德和園」，均可以在各個景點門口單獨買票。不少遊客須要遊玩全部德景點，這種買票方式很不方便，須要在每一個景點門口排隊買票，錢包拿 進拿出的，容易丟失，很不安全。因而絕大多數遊客選擇在大門口買一張通票（也叫套票），就能夠玩遍全部的景點而不須要從新再買票。他們只須要在每一個景點門 口出示一下剛纔買的套票就可以被容許進入每一個獨立的景點。

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

 

從上面的視圖能夠看出，要實現SSO，須要如下主要的功能：

• 全部應用系統共享一個身份認證系統。
  統一的認證系統是SSO的前提之一。認證系統的主要功能是將用戶的登陸信息和用戶信息庫相比較，對用戶進行登陸認證；認證成功後，認證系統應該生成統一的認證標誌（ticket），返還給用戶。另外，認證系統還應該對ticket進行效驗，判斷其有效性。
• 全部應用系統可以識別和提取ticket信息
  要實現SSO的功能，讓用戶只登陸一次，就必須讓應用系統可以識別已經登陸過的用戶。應用系統應該能對ticket進行識別和提取，經過與認證系統的通信，能自動判斷當前用戶是否登陸過，從而完成單點登陸的功能。

 

上面的功能只是一個很是簡單的SSO架構，在現實狀況下的SSO有着更加複雜的結構。有兩點須要指出的是：

• 單一的用戶信息數據庫並非必須的，有許多系統不能將全部的用戶信息都集中存儲，應該容許用戶信息放置在不一樣的存儲中，以下圖所示。事實上，只要統一認證系統，統一ticket的產生和效驗，不管用戶信息存儲在什麼地方，都能實現單點登陸。
•  

   

• 統一的認證系統並非說只有單個的認證服務器，以下圖所示，整個系統能夠存在兩個以上的認證服務器，這些服務器甚至能夠是不一樣的產品。認證服務器之間要經過標準的通信協議，互相交換認證信息，就能完成更高級別的單點登陸。以下圖，當用戶在訪問應用系統1時，由第一個認證服務器進行認證後，獲得由此服務器產生的ticket。當他訪問應用系統4的時候，認證服務器2可以識別此ticket是由第一個服務器產生的，經過認證服務器之間標準的通信協議（例如SAML）來交換認證信息，仍然可以完成SSO的功能。

 

3 WEB-SSO的實現

隨着互聯網的高速發展，WEB應用幾乎統治了絕大部分的軟件應用系統，所以WEB-SSO是SSO應用當中最爲流行。WEB-SSO有其自身的特色和優點，實現起來比較簡單易用。不少商業軟件和開源軟件都有對WEB-SSO的實現。其中值得一提的是OpenSSO （https://opensso.dev.java.net），爲用Java實現WEB-SSO提供架構指南和服務指南，爲用戶本身來實現WEB-SSO提供了理論的依據和實現的方法。

爲何說WEB-SSO比較容易實現呢？這是有WEB應用自身的特色決定的。

衆所周知，Web協議（也就是HTTP）是一個無狀態的協議。一個Web應用由不少個Web頁面組成，每一個頁面都有惟一的URL來定義。用戶在瀏覽器的地址欄輸入頁面的URL，瀏覽器就會向Web Server去發送請求。以下圖，瀏覽器向Web服務器發送了兩個請求，申請了兩個頁面。這兩個頁面的請求是分別使用了兩個單獨的HTTP鏈接。所謂無狀態的協議也就是表如今這裏，瀏覽器和Web服務器會在第一個請求完成之後關閉鏈接通道，在第二個請求的時候從新創建鏈接。Web服務器並不區分哪一個請求來自哪一個客戶端，對全部的請求都一視同仁，都是單獨的鏈接。這樣的方式大大區別於傳統的（Client/Server）C/S結構,在那樣的應用中，客戶端和服務器端會創建一個長時間的專用的鏈接通道。正是由於有了無狀態的特性，每一個鏈接資源可以很快被其餘客戶端所重用，一臺Web服務器纔可以同時服務於成千上萬的客戶端。

可是咱們一般的應用是有狀態的。先不用提不一樣應用之間的SSO，在同一個應用中也須要保存用戶的登陸身份信息。例如用戶在訪問頁面1的時候進行了登陸，可是剛纔也提到，客戶端的每一個請求都是單獨的鏈接，當客戶再次訪問頁面2的時候，如何才能告訴Web服務器，客戶剛纔已經登陸過了呢？瀏覽器和服務器之間有約定：經過使用cookie技術來維護應用的狀態。Cookie是能夠被Web服務器設置的字符串，而且能夠保存在瀏覽器中。以下圖所示，當瀏覽器訪問了頁面1時，web服務器設置了一個cookie，並將這個cookie和頁面1一塊兒返回給瀏覽器，瀏覽器接到cookie以後，就會保存起來，在它訪問頁面2的時候會把這個cookie也帶上，Web服務器接到請求時也能讀出cookie的值，根據cookie值的內容就能夠判斷和恢復一些用戶的信息狀態。

Web-SSO徹底能夠利用Cookie結束來完成用戶登陸信息的保存，將瀏覽器中的Cookie和上文中的Ticket結合起來，完成SSO的功能。

 

爲了完成一個簡單的SSO的功能，須要兩個部分的合做：

1. 統一的身份認證服務。
2. 修改Web應用，使得每一個應用都經過這個統一的認證服務來進行身份效驗。

 

轉: http://blog.csdn.net/zuoluoboy/article/details/12851725 謝！