最近好多朋友問我關于 SSO 的問題，其實市面上有很多成型的產品，SSO 理論本身也提了好多年了，下面是我以前寫的一篇文章《基于 Web 的單點登錄理論研究》里的一部分關于跨域和票據設計問題，相信對問我的朋友們有些幫助。
早在上個世紀中期，SSO技術就已備雛型了，后來一些大公司用驅動技術或者屏幕截取技術把 windows 認證信息傳遞到自己的應用系統中，避免用戶再次登陸。直到 1998年，SSO技術日趨成熟，他們已經建立了獨立的SSO系統，這些系統能夠透明的把OS 認證信息傳遞給上層的應用系統，為后來 SSO 系統打下了良好的基礎。
隨著互聯網技術的不斷發展，互聯網應用的復雜度越來越高，SSO技術也從原來只在C/S應用程序下使用，發展到了B/S應用系統。所以SSO系統構建的復雜性也越來越大。隨著XML,WEB SERVICE等一些跨平臺，跨語言的技術產生和應用，以及相關的一些標準和規范的發布和使用，比如 SAML(Security Assertion Markup Language，安全斷言標記語言)等為異構系統的通訊提供了一個較好的平臺，共同構成現代網絡的必備條件。目前業界基本上構成兩大陣營，OASIS/Liberty與WS-*，即SAML2.0與WS-Federation，兩者有些地方是重復的，未來統一的單一標準究竟是以哪個為基礎，還沒有定論，或許會建立在二者之上。
近年來，身份認證系統發展的很快，已經逐漸由傳統的多點登錄向集中式單點登錄方向發展，同時身份也不僅僅局限在一個公司內，公司之間的聯合身份認證已很熱門，聯合身份認證解決如何在公司之間實現單點登錄，涉及到多個身份認證服務器互聯和信任問題。
目前業界已有很多門戶產品支持 SSO，如 IBM 的 WebSphere，BEA 的 WebLogic 和 Apache 的 Tomcat 等等；也有不少成功的商業軟件，如微軟的 Passport, Netegrity 的 Siteminder，Novell 公司的 iChain，RSA 公司的 ClearTrust 以及 USBKey 的方式等等；開源的也有很多，如耶魯大學開發的 CAS，Sun 的 OpenSSO 等等；當然互聯網上也有不少的資料。但各家 SSO 產品的實現方式也不盡相同，對客戶的要求比較嚴格，較難應用到自己的系統中，所以很多公司都有自己的單點登錄平臺。
3 單點登錄機制
單點登錄的機制其實是很簡單的，現實中也不乏這樣的例子，比如你去景點游玩，里面有“過山車”，“百鳥園”，“劃船”等等項目，游客可以在各自的項目點買票，如果游客期望游玩所有的項目，這種買票方式需要游客在每個項目點排隊，很不方便，而且錢包掏來掏去，也不安全。因此絕大部分游客都選擇買一套票，就可玩遍所有的項目而不需要多余的排隊，只需在每個項目入口出示一下套票就可游玩。
單點登錄的機制也是一樣地，如圖1：
當用戶第一次訪問 ERP系統的時候，因為還沒有登錄，就被引導到認證中心進行登錄（1）；根據用戶登錄信息，認證中心進行身份驗證，如果通過，就返回一票據（ticket）給用戶（2）；用戶再訪問其他應用系統的時候（3，5）就會帶上這個票據，作為自己認證的憑據，應用系統接受到請求之后會把ticket送到認證中心進行效驗，檢查ticket的是否合法（4，6）。如果通過效驗，用戶不需要重新登陸就可訪問EFP系統和EIP系統了，即”一次登錄，多方認證[2]”。
要實現單點登錄，就要統一認證機制，認證中心的主要功能是用戶登錄認證，票據生成和票據有效性檢查。所有加入認證中心的系統都不能解析票據信息（要想獲得用戶信息，認證中心有功能提供），而是通過與認證中心的通信來判斷當前用戶是否登錄過，從而完成單點登錄的功能。
用戶信息的格式、命名與存儲方式多種多樣，針對目前各個系統用戶信息很難整合的情況，應該允許存儲在不同的地方或以不同的方式存儲（比如數據庫，LDAP， 文件或者網絡來源） 如圖2。
實際上，只要有統一的認證中心，統一的票據，無論用戶信息來源哪里都可實現單點登錄機制。
當然，認證中心也不一定唯一，比如聯合登錄，如圖3。
這就需要不同的認證中心之間可共享票據和互通驗證信息。實現更高一級別的單點登錄系統，目前已有幾種聯合認證的 XML 標準[4], 包括安全聲明標記語言( SAML)，自由聯盟( Liberty Alliance) 計劃和Web 服務聯盟語言( WS-Federation) 。
1 跨域和票據設計
1.1 跨域設計
單點登錄機制中，比較核心的數據結構就是票據，票據本身的實現下一小節介紹，由于這篇論文針對的是 Web 應用系統，所以客戶端一般用的是瀏覽器，如果讓瀏覽器保存票據，那只能借助 Cookie，當然也可采用服務器端 Session 共享票據信息，但本文采用 Cookie 和Session 雙存儲的方式。
瀏覽器中最多保存300個cookie;為單個服務器最多只能保存20個;每個不能超過4000個字節，通過 HTTP 協議在瀏覽器和服務器之間傳輸，完全滿足目前系統認證整合的需求。
理論上，Cookie 是不能跨域訪問的，但通過一些技巧也可實現。針對跨域 Cookie 設計這里分兩種方式論述：即跨子域和跨域。
1.1.1 跨子域設計
所謂跨子域登錄，比如A 站點為a.jmsys.com, B 站點為b.jmsys.com，認證中心站點 C為 c.jmsys.com。從三個站點的關系可以看出，他們都屬于同一個二級域 jmsys.com,不同的是子域不同，一個為a，一個為b，一個是c. 他們統一的平臺域名為 www.jmsys.com。
Cookie 本身是不能跨域的，即 A, B 站點讀不到C 站點寫的 cookie 信息，解決辦法很簡單，將 cookie 的 domain 屬性設置為二級域 即Cookie. domain=".jmsys.com"，那么 C 寫的 cookie 信息 A, B都能讀到。當認證中心產生票據時，以 Cookie 的方式存于瀏覽器端，A,B都能通過 Cookie 得到票據，可簡單實現單點登錄機制。
1.1.2 跨異域設計
所謂跨子域登錄，比如A 站點為a.jmsys.com, B 站點為b.jmsys.com，認證中心站點 C為 c.jmsys.com。從三個站點的關系可以看出，他們都屬于同一個二級域 jmsys.com,不同的是子域不同，一個為a，一個為b，一個是c. 他們統一的平臺域名為 www.jmsys.com。
Cookie 本身是不能跨域的，即 A, B 站點讀不到C 站點寫的 cookie 信息，解決辦法很簡單，將 cookie 的 domain 屬性設置為二級域即Cookie. domain=".jmsys.com"，那么 C 寫的 cookie 信息 A, B都能讀到。當認證中心產生票據時，以 Cookie 的方式存于瀏覽器端，A,B都能通過 Cookie 得到票據，可簡單實現單點登錄機制。
完全跨域登錄[3]，是指A，B站點和C站點沒有共同的父域，比如A站點為a.jmsys1.com,B站點為b.jmsys2.com，由于這種情況票據較復雜，這里暫時把C站點(c.jmsys3.com)創建的ticket叫做C-ticket，而A站點創建的叫A-ticket，B的為B-ticket. 這種情況每個站點都要有創建 Cookie 的能力，其實就是 C-ticket 的復制，當然也有其他的方式達到這種效果，如圖4
由于A 站點（a.jmsys1.com）不能讀取到由C站點（c.jmsys3.com）創建的票據，所以當用戶訪問A站點時，首先查看是否有A-ticket，如果沒有，證明用戶沒有在A站點登錄過，不過并不保證用戶沒有在B站點登錄，請求被重定向到C 站點，C讀取C-ticket，如果沒有，就需要重定向登錄頁面，登錄頁面完成登錄后，寫一個加密cookie，也就是C-ticket，并且重定向到A站點，并把 ticket作為參數傳遞過去，A 站點也要寫一個cookie，也就是A-ticket，今后用戶再次訪問A站點時，只需要檢查這個A-ticket 是否存即可。當用戶訪問B站點時，會重復上述過程。
注銷時需要刪除C-ticket 。只要 C-ticket 在認證中心清除了，用戶訪問任何一個站點都需要重新登錄。
1.2 票據設計
票據以 Cookie 為載體，采用數字簽名技術和 RSA 算法。認證中心產生自己的公鑰和私鑰，每次生成票據時對其簽名。客戶端請求驗證時，認證中心會用其公鑰和會話密鑰驗證票據，保證票據的機密性、完整性和簽發方身份的不可否認性。
當 RSA 算法的密鑰長度為1024bit時，需要1012 MIPS(100 萬次/s運算的計算機工作一年)年才能解開[1]，而且認證中心也會為每個票據生成會話密鑰，加密 ticket。所以票據是比較安全的。
Ticket={VER，AL，UserID，ValidDate，other，[hash(VER，AL，UserID，ValidDate，other)]Sign}
其中，VER是票據的版本號，AL是算法的標識（如 RSA, MD5等），UserID是用戶編號，ValidDate 是票據的有效截至日期，other是指其他信息，hash()是單向散列函數（如MD5、SHA等），[]Sign是對[]中的數據的簽名值，認證中心成為安全域的信任端。各應用系統不能解密票據信息，只能簡單的把票據傳給認證中心，由認證中心對票據解析驗證，并做相關日志記錄（以備行為追蹤和統計用）。
本博客為學習交流用，凡未注明引用的均為本人作品，轉載請注明出處，如有版權問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學習進步。