單點登錄

單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個套用系統中，用戶只需要登錄一次就可以訪問所有相互信任的套用系統。

基本介紹

• 中文名：單點登錄
• 外文名：Single Sign On
• 簡稱：SSO
• 解釋：企業業務整合的解決方案

概述

很早期的公司，一家公司可能只有一個Server，慢慢的Server開始變多了。每個Server都要進行註冊登錄，退出的時候又要一個個退出。用戶體驗很不好！你可以想像一下，上豆瓣 要登錄豆瓣FM、豆瓣讀書、豆瓣電影、豆瓣日記......真的會讓人崩潰的。我們想要另一種登錄體驗：一家企業下的服務只要一次註冊，登錄的時候只要一次登錄，退出的時候只要一次退出。怎么做？

一次註冊。 一次註冊不難，想一下是不是只要Server之間同步用戶信息就行了？可以，但這樣描述不太完整，後續講用戶註冊的時候詳細說。實際上用戶信息的管理才是SSO真正的難點，只是作為初學者，我們的難點在於實現SSO的技術！我們先討論實現手段。

一次登錄與一次退出。 回頭看看普通商場的故事，什麼東西才是保持登錄狀態關鍵的東西？記錄器（session）？那種叫做cookie的紙張？寫在紙張上的ID? 是session裡面記錄的信息跟那個ID，cookie不只是記錄ID的工具而已。客戶端持有ID，服務端持有session，兩者一起用來保持登錄狀態。客戶端需要用ID來作為憑證，而服務端需要用session來驗證ID的有效性（ID可能過期、可能根本就是偽造的找不到對於的信息、ID下對應的客戶端還沒有進行登錄驗證等）。但是session這東西一開始是每個server自己獨有的，豆瓣FM有自己的session、豆瓣讀書有自己的session，而記錄ID的cookie又是不能跨域的。所以，我們要實現一次登錄一次退出，只需要想辦法讓各個server的共用一個session的信息，讓客戶端在各個域名下都能持有這個ID就好了。再進一步講，只要各個server拿到同一個ID，都能有辦法檢驗出ID的有效性、並且能得到ID對應的用戶信息就行了，也就是能檢驗ID。

實現方法

server端

以server群如何生成、驗證ID的方式大致分為兩種：

• “共享Cookie”這個就是上面提到的共享session的方式，我倒覺得叫“共享session”來得好一點，本質上cookie只是存儲session-id的介質，session-id也可以放在每一次請求的url里。據說這種方式不安全，我沒去細究，哪位大神可以推薦下相關的資料，我後期補上。其實也是，畢竟session這項機制一開始就是一個server一個session的，把session拿出來讓所有server共享確實有點奇怪。
• SSO-Token方式因為共享session的方式不安全，所以我們不再以session-id作為身份的標識。我們另外生成一種標識，把它取名SSO-Token(或Ticket)，這種標識是整個server群唯一的，並且所有server群都能驗證這個token，同時能拿到token背後代表的用戶的信息。我們要討論的也是這種方式，一會上具體流程圖。

瀏覽器端

• 單點登錄還有非常關鍵的一步，這一步跟server端驗證token的方式無關，用最早的“共享session”的方式還是現在的“token”方式，身份標識到了瀏覽器端都要面臨這樣的一個問題：用戶登錄成功拿到token(或者是session-id)後怎么讓瀏覽器存儲和分享到其它域名下？同域名很簡單，把token存在cookie里，把cookie的路徑設定成頂級域名下，這樣所有子域都能讀取cookie中的token。這就是共享cookie的方式（這才叫共享Cookie嘛，上面那個應該叫共享session）。比如：谷歌公司，google.com是他的頂級域名，信箱服務的mail.google.com和地圖服務的map.google.com都是它的子域。但是，跨域的時候怎么辦？谷歌公司還有一個域名，youtube.com，提供視頻服務。

企業套用集成

通常情況下運維內控審計系統、4A系統都包含此項功能，目的是簡化賬號登錄過程並保護賬號和密碼安全，對賬號進行統一管理。

企業套用集成（EAI, Enterprise Application Integration）。企業套用集成可以在不同層面上進行：例如在數據存儲層面上的“數據大集中”，在傳輸層面上的“通用數據交換平台”，在套用層面上的“業務流程整合”，和用戶界面上的“通用企業門戶”等等。事實上，還有一個層面上的集成變得越來越重要，那就是“身份認證”的整合，也就是“單點登錄”。

在信息安全管理中，訪問控制(Access Controls)環繞四個過程：Identification；Authentication；Authorization；Accountability。單點登錄（Single Sign On）屬於Authentication認證系統，除單點登錄外還包括：Lightweight Directory Access Protocol 和 Authorization ticket。（Michael E. Whitman (2011) Management Of Information Security Kennesaw University)。

技術實現機制

當用戶第一次訪問套用系統的時候，因為還沒有登錄，會被引導到認證系統中進行登錄；根據用戶提供的登錄信息，認證系統進行身份校驗，如果通過校驗，應該返回給用戶一個認證的憑據－－ticket；用戶再訪問別的套用的時候，就會將這個ticket帶上，作為自己認證的憑據，套用系統接受到請求之後會把ticket送到認證系統進行校驗，檢查ticket的合法性。如果通過校驗，用戶就可以在不用再次登錄的情況下訪問套用系統2和套用系統3了。

要實現SSO，需要以下主要的功能：

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

優點

1）提高用戶的效率。

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

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

SSO 為開發人員提供了一個通用的身份驗證框架。實際上，如果 SSO 機制是獨立的，那么開發人員就完全不需要為身份驗證操心。他們可以假設，只要對應用程式的請求附帶一個用戶名，身份驗證就已經完成了。

3）簡化管理。

如果應用程式加入了單點登錄協定，管理用戶帳號的負擔就會減輕。簡化的程度取決於應用程式，因為 SSO 只處理身份驗證。所以，應用程式可能仍然需要設定用戶的屬性（比如訪問特權）。

缺點

1）不利於重構

因為涉及到的系統很多，要重構必須要兼容所有的系統，可能很耗時。

2） 無人看守桌面

因為只需要登錄一次，所有的授權的套用系統都可以訪問，可能導致一些很重要的信息泄露。