單點登陸 SSO（Single Sign-On）的實現原理

遷移到：http://www.bdata-cap.com/newsinfo/1741388.html

爲何要 SSO？

---

企業的信息化過程是一個按部就班的過程，這就形成在企業的不一樣時期，根據業務和發展須要，構建了多個應用程序，而這些應用程序在功能、設計和技術可能都有所不一樣，就造成了各自獨立的用戶庫和用戶認證體系。因而，在訪問不一樣的應用系統時，須要記錄/輸入的用戶名和密碼（不一樣時期創建的系統，用戶名和密碼的規則可能還不同；要是忘了，還得讓人重置；若是人員發生變更，那全部的系統都要改）。這太麻煩了。

若是引入單一用戶登陸的解決方案，創建一套統一的、完善的、科學的單點登陸系統，每一個用戶只需記錄一個用戶名和密碼，登陸一個平臺後便可實現各應用系統的透明跳轉，並且實行統一的用戶信息管理系統（系統管理員能夠經過平臺接口同步更新至各個應用系統，實現單次維護全公司同步變動），就能夠大幅度提升工做效率。

單點登陸在如今的軟件系統已經很常見，好比，阿里集團，有不少應用系統，有淘寶、有天貓、有支付寶、有阿里旺旺，只要登陸一次，其餘的全部系統均可以使用，再好比，像有道雲筆記、Evernote，它們有網頁版，還有客戶端，只要登陸一個，另外一個就能自動登陸~

什麼是 SSO?

---

單點登陸，Single Sign-On，簡寫爲 SSO，是一個用戶認證的過程，容許用戶一次性進行認證後，就可訪問系統中不一樣的應用；而無須要訪問每一個應用時，都從新輸入用戶和密碼。IBM 對 SSO 有一個形象的解釋「單點登陸、全網漫遊」。

SSO 的好處？

---

SSO 將一個企業內部全部域中的用戶登陸和用戶賬號管理集中到一塊兒，SSO 的好處顯而易見：

• 減小用戶在不一樣系統中登陸耗費的時間，減小用戶登陸出錯的可能性

• 實現安全的同時避免了處理和保存多套系統用戶的認證信息

• 減小了系統管理員增長、刪除用戶和修改用戶權限的時間

• 增長了安全性：系統管理員有了更好的方法管理用戶，包括能夠經過直接禁止和刪除用戶來取消該用戶對全部系統資源的訪問權限

對於內部有多種應用系統的企業來講，單點登陸的效果是十分明顯的。不少國際上的企業已經將單點登陸做爲系統設計的基本功能之一。

解決方案

---

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

• 存儲信任
• 驗證信任

只要解決了以上的問題，達到了開頭講得效果就能夠說是 SSO。SSO 的實現機制大致分爲 Cookie 機制和 Session 機制兩大類。

Cookie 機制

最簡單實現 SSO 的方法就是用 Cookie，實現流程以下所示：

圖 1 Cookie 機制

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

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

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

目前好點的開源單點登陸產品 CAS（Central Authentication Service）就是採用 Cookie 機制。CAS 最先由耶魯大學開發。2004年12月，CAS 成爲 JA-SIG 中的一個項目。JA-SIG 全稱是 Java Architectures Special Interest Group。CAS 的優勢，如配置簡單、客戶端支持普遍、技術成熟等。

圖 2 CAS

 

CAS 涉及 5 種票據： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。Ticket-granting cookie（TGC），是存放用戶身份認證憑證的 cookie ，在瀏覽器和 CAS Server 間通信時使用，而且只能基於 Https，是 CAS Server 用來明確用戶身份的憑證；Service ticket（ST），是服務票據，服務的唯一標識碼 , 由 CAS Server 經過 HTTP 發出，經過客戶端瀏覽器到達業務服務器端。一個特定的服務只能有一個唯一的 ST； Proxy-Granting ticket（PGT），是由 CAS Server 頒發給擁有 ST 憑證的服務， PGT 綁定一個用戶的特定服務，使其擁有向 CAS Server 申請，得到 PT 的能力； Proxy-Granting Ticket I Owe You（PGTIOU），是將經過憑證校驗時的應答信息由 CAS Server 返回給 CAS Client ，同時，與該 PGTIOU 對應的 PGT 將經過回調連接傳給 Web 應用。Web 應用負責維護 PGTIOU 與 PGT 之間映射關係的內容表； Proxy Ticket（PT），是應用程序代理用戶身份對目標程序進行訪問的憑證。

CAS 驗證過程：

 

• 應用程序一開始，一般進入原來的登錄界面，直接轉向 CAS 自帶的登陸界面（固然也能夠在原來登陸界面增長登陸按鈕，來跳轉）。若是用戶但願，也能夠直接進入 CAS 的登陸界面登陸，再啓動其餘應用程序。不過這種方式主要用於測試環境）。
• CAS 的登陸界面處理所謂的「主體認證」。它要求用戶輸入用戶名和密碼，就像普通的登陸界面同樣。
• 主體認證時，CAS 獲取用戶名和密碼，而後經過某種認證機制進行認證。一般認證機制是 LDAP（Lightweight Directory Access Protocol）。
• 爲了進行之後的單點登陸，CAS向瀏覽器送回一個所謂的「內存cookie」。這種cookie並非真的保存在內存中，而只是瀏覽器一關閉，cookie就自動過時。這個cookie稱爲「ticket-granting cookie」，用來代表用戶已經成功地登陸。
• 認證成功後，CAS 服務器建立一個很長的、隨機生成的字符串，稱爲「Ticket」。隨後，CAS將這個ticket和成功登陸的用戶，以及服務聯繫在一塊兒。這個ticket是一次性使用的一種憑證，它只對登陸成功的用戶及其服務使用一次。使用過之後馬上失效。
• 主體認證完成後，CAS將用戶的瀏覽器重定向，回到原來的應用。CAS客戶端，在從應用轉向CAS 時，同時也會記錄原始的URL，所以 CAS 知道誰在調用本身。CAS 重定向的時候，將ticket 做爲一個參數傳遞回去。
• 例如，原始應用的地址是 http://www.itil.com/，轉向 CAS 服務器的單點登陸頁面 https://secure.oa.com/cas/login?service=http://www.itil.com/auth.aspx；
• CAS 完成主體認證後，會使用 http://www.itil.com/authenticate.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20 這個 URL 進行重定向 。
• 收到 ticket 後，應用程序須要驗證 ticket。這是經過將 ticket 傳遞給一個校驗 URL 來實現的。校驗 URL 也是 CAS 服務器提供的。
• CAS 經過校驗路徑得到了 ticket 後，經過內部的數據庫對其進行判斷。若是是有效性，則返回一個 NetID 給應用程序。
• 隨後 CAS 將 ticket做廢，而且在客戶端留下一個 cookie。
• 之後，其餘應用程序就使用這個 cookie 進行認證（固然經過 CAS 的客戶端），而再也不須要輸入用戶名和密碼。

這種方式，之前見的比較多，如今大都用 Session 機制，別的不說，Cookie 在客戶端始終是個安全隱患，不涉及錢，還能容忍，要是涉及轉帳之類的，出問題怎麼算呢，不能簡單一句：你電腦中毒了，被黑了，你本身的問題，這麼簡單吧，並且，用 CAS 時，會重定向，若是網絡很差，能看到明顯的延遲和卡頓~

Session 機制

通常大型系統會採起在服務端存儲信任關係的作法，也就是 Session 機制實現單點登陸（畢竟像上面客戶端的 Cookie 方式，安全性實在是差了點），實現流程以下所示：

圖 3 Session 機制

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

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

對於第一個問題，通常能夠採用相似與 memcached 分佈式緩存的方案，既能提供可擴展數據量的機制，也能提供高效訪問。

而對第二個問題，通常採起數字簽名的方法，要麼經過數字證書籤名，要麼經過像 md5 方式，這就須要SSO系統返回免登URL的時候對需驗證的參數進行md5加密，並帶上 token一塊兒返回，最後需免登的系統進行驗證信任關係的時候，需把這個token傳給SSO系統，SSO系統經過對token的驗證就能夠辨別信息是否被改過。

對最後一個問題，能夠經過白名單來處理，說簡單點只有在白名單上的系統才能請求生產信任關係，同理只有在白名單上的系統才能被免登陸。