遷移到：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的驗證就可以辨識資訊是否被改過。
對最後一個問題，可以通過白名單來處理，說簡單點隻有在白名單上的系統才能請求生産信任關系，同理隻有在白名單上的系統才能被免登入。