單點登入（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[1] 。

實現方法

編輯

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，提供視訊服務[2]
   。

企業應用整合

編輯 通常情況下運維內控審計系統、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)[3]。

技術實現機制

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

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

優點

編輯 1）提高使用者的效率。 使用者不再被多次登入困擾，也不需要記住多個 ID 和密碼。另外，使用者忘記密碼並求助於支援人員的情況也會減少。 2）提高開發人員的效率。 SSO 為開發人員提供了一個通用的身份驗證框架。實際上，如果 SSO 機制是獨立的，那麼開發人員就完全不需要為身份驗證操心。他們可以假設，只要對應用程式的請求附帶一個使用者名稱，身份驗證就已經完成了。 3）簡化管理。 如果應用程式加入了單點登入協議，管理使用者帳號的負擔就會減輕。簡化的程度取決於應用程式，因為 SSO 只處理身份驗證。所以，應用程式可能仍然需要設定使用者的屬性（比如訪問特權）。

缺點

編輯 1）不利於重構 因為涉及到的系統很多，要重構必須要相容所有的系統，可能很耗時。 2） 無人看守桌面 因為只需要登入一次，所有的授權的應用系統都可以訪問，可能導致一些很重要的資訊洩露。