1. 程式人生 > >單點登錄SSO的實現原理 (轉)

單點登錄SSO的實現原理 (轉)

客戶 解決方案 bus 應用集成 eight 冗余 請求 效率 att

單點登錄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多個業務系統,這些系統包括兩個不同版本的SAPERP系統,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);根據用戶提供的登錄信息,認證系統進行身份效驗,如果通過效驗,應該返回給用戶一個認證的憑據--ticket2);用戶再訪問別的應用的時候(35)就會將這個ticket帶上,作為自己認證的憑據,應用系統接受到請求之後會把ticket送到認證系統進行效驗,檢查ticket的合法性(46)。如果通過效驗,用戶就可以在不用再次登錄的情況下訪問應用系統2和應用系統3了。 技術分享 從上面的視圖可以看出,要實現SSO,需要以下主要的功能:
  • 所有應用系統共享一個身份認證系統。
    統一的認證系統是SSO的前提之一。認證系統的主要功能是將用戶的登錄信息和用戶信息庫相比較,對用戶進行登錄認證;認證成功後,認證系統應該生成統一的認證標誌(ticket),返還給用戶。另外,認證系統還應該對ticket進行效驗,判斷其有效性。
  • 所有應用系統能夠識別和提取ticket信息
    要實現SSO的功能,讓用戶只登錄一次,就必須讓應用系統能夠識別已經登錄過的用戶。應用系統應該能對ticket進行識別和提取,通過與認證系統的通訊,能自動判斷當前用戶是否登錄過,從而完成單點登錄的功能。
上面的功能只是一個非常簡單的SSO架構,在現實情況下的SSO有著更加復雜的結構。有兩點需要指出的是:
  • 單一的用戶信息數據庫並不是必須的,有許多系統不能將所有的用戶信息都集中存儲,應該允許用戶信息放置在不同的存儲中,如下圖所示。事實上,只要統一認證系統,統一ticket的產生和效驗,無論用戶信息存儲在什麽地方,都能實現單點登錄。
技術分享
  • 統一的認證系統並不是說只有單個的認證服務器,如下圖所示,整個系統可以存在兩個以上的認證服務器,這些服務器甚至可以是不同的產品。認證服務器之間要通過標準的通訊協議,互相交換認證信息,就能完成更高級別的單點登錄。如下圖,當用戶在訪問應用系統1時,由第一個認證服務器進行認證後,得到由此服務器產生的ticket。當他訪問應用系統4的時候,認證服務器2能夠識別此ticket是由第一個服務器產生的,通過認證服務器之間標準的通訊協議(例如SAML)來交換認證信息,仍然能夠完成SSO的功能。
技術分享 3 WEB-SSO的實現 隨著互聯網的高速發展,WEB應用幾乎統治了絕大部分的軟件應用系統,因此WEB-SSOSSO應用當中最為流行。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/ServerC/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 謝!

單點登錄SSO的實現原理 (轉)