采用CAS原理構建單點登錄

企業的信息化過程是一個循序漸進的過程，在企業各個業務網站逐步建設的過程中，根據各種業務信息水平的需要構建了相應的應用系統，由於這些應用系統一般是在不同的時期開發完成的，各應用系統由於功能側重、設計方法和開發技術都有所不同，也就形成了各自獨立的用戶庫和用戶認證體系。隨著新的業務網站不斷的增加，用戶在每個應用系統中都有獨立的賬號，這樣就造成在訪問不同的應用系統時，需要記錄對應的用戶名和密碼，多個用戶名密碼極易記混，如果忘記或記錯了某一個業務網站的用戶名或密碼就無法進行登錄，耽誤工作，影響工作效率，隨著局內信息化進程的推進還會有新的應用系統產生，如果不引入單一用戶登錄的解決方案，全公司工作人名特別是承擔審批權限的各級領導很難記清各類應用系統的用戶名和密碼，嚴重影響由信息化帶來快捷性和高效性。此外，多個應用平臺就有多個用戶管理，這也為系統管理員維護人員系統帶來巨大的工作量，例如，一次變更10個人員，即使只有5個應用系統，也需要重復維護50個人員信息，而企業的每次人員調整遠不至10人，這種幾何增長的維護工作量，會浪費大量的精力和時間，減弱了信息化系統帶來方便快捷，為此，需建立一套統一的、完善的、科學的單點登錄系統，每個用戶只需記錄一個用戶名密碼，登錄一個平臺後即可實現各應用系統的透明跳轉，而且實行統一的用戶信息管理系統，系統管理員只需維護一套人員信息，更改信息通過平臺接口同步更新至各個應用系統，實現人員系統單次維護全公司同步變更，大大提高工作效率。

新的應用系統在不斷開發，早一天規劃設計出單點登錄的規範接口，就可以為新開發的系統提出的一種整合的標準，在開發初期無論哪個開發商，無論采用哪種技術開發，只要遵循單點登錄的規範標準，新的系統開發完成之後即可無縫整合的到單點登錄平臺中，從而減少了系統開發完成後再整合到單點登錄改動而造成資源的浪費。

從信息共享角度看現有的各個業務系統都使用各自的數據存儲方式，不經過基礎的用戶名和密碼認證後，相互之間無法傳遞有效信息。為避免信息孤島的產生，因此需要建立一個連接各個業務系統的技術架構和標準，實現平臺統一化整合；通過對業務處理和異常處理實現監管透明；通過將業務流程從應用中抽離，實現業務流程的靈活安排，這樣就需要一套可以整合現有各個業務網站的信息共享平臺。

單點登錄的英文名稱為Single Sign-On，簡寫為SSO，它是一個用戶認證的過程，允許用戶一次性進行認證之後，就訪問系統中不同的應用；而不需要訪問每個應用時，都重新輸入密碼。IBM對SSO有一個形象的解釋“單點登錄、全網漫遊”。

SSO將一個企業內部所有域中的用戶登錄和用戶帳號管理集中到一起，SSO的好處顯而易見：

• 減少用戶在不同系統中登錄耗費的時間，減少用戶登錄出錯的可能性
• 實現安全的同時避免了處理和保存多套系統用戶的認證信息
• 減少了系統管理員增加、刪除用戶和修改用戶權限的時間
• 增加了安全性：系統管理員有了更好的方法管理用戶，包括可以通過直接禁止和刪除用戶來取消該用戶對所有系統資源的訪問權限

對於內部有多種應用系統的企業來說，單點登錄的效果是十分明顯的。很多國際上的企業已經將單點登錄作為系統設計的基本功能之一。

公司第一個版本的單點登陸系統從2005年運行以來，從幾十個應用系統擴展到現在的幾百個系統。在應用的過程中沒有很好的解決跨域名的問題，單點登陸客戶端代碼使用問題，應用系統的訪問規則問題等都沒有很好的解決。

SSO的實現機制不盡相同，大體分為Cookie機制和Session機制兩大類。

• WebLogic通過Session共享認證信息。Session是一種服務器端機制，當客戶端訪問服務器時，服務器為客戶端創建一個惟一的SessionID，以使在整個交互過程中始終保持狀態，而交互的信息則可由應用自行指定，因此用Session方式實現SSO，不能在多個瀏覽器之間實現單點登錄，但卻可以跨域。
• WebSphere通過Cookie記錄認證信息。Cookie是一種客戶端機制，它存儲的內容主要包括: 名字、值、過期時間、路徑和域，路徑與域合在一起就構成了Cookie的作用範圍，因此用Cookie方式可實現SSO，但域名必須相同。

目前大部分SSO產品采用的是Cookie機制，公司第一個版本的單點登陸系統也是如此，目前能夠找到的最好的開源單點登錄產品CAS也是采用Cookie機制。 CAS http://www.ja-sig.org/products/cas/，CAS單點登錄系統最早由耶魯大學開發。2004年12月，CAS成為JA-SIG中的一個項目。JA-SIG的全稱是Java Architectures Special Interest Group，是在高校中推廣和探討基於Java的開源技術的一個組織。CAS的優點很多，例如設計理念先進、體系結構合理、配置簡單、客戶端支持廣泛、技術成熟等等。這也是我們這次SSO改造的參照產品。

以CAS為例，使用Cookie實現單點登錄的原理圖如圖1所示。

• 首先，單點登錄分為“服務端”和“客戶端”。服務端就是單點登錄服務器，而客戶端通常是“函數庫”或者“插件”。需要使用單點登錄的應用程序，需要把客戶端插件安裝到自己的系統中，或者將客戶端函數庫包括在代碼中。單點登錄的客戶端通常替換了原來應用程序的認證部分的代碼。
• 某個應用程序首先要發起第1次認證。大部分情況下，應用程序中嵌入的客戶端會把應用程序原來的登錄畫面屏蔽掉，而直接轉到單點登錄服務器的登錄頁面。

圖 1 使用Cookie實現單點登錄的原理圖

• 用戶在單點登錄服務器的登錄頁面中，輸入用戶名和密碼。
• 然後單點登錄服務器會對用戶名和密碼進行認證。認證本身並不是單點登錄服務器的功能，因此，通常會引入某種認證機制。認證機制可以有很多種，例如自己寫一個認證程序，或者使用一些標準的認證方法，例如LDAP或者數據庫等等。在大多數情況下，會使用LDAP進行認證。這是因為LDAP在處理用戶登錄方面，有很多獨特的優勢，這在本文的後面還會比較詳細地進行介紹。
• 認證通過之後，單點登錄服務器會和應用程序進行一個比較復雜的交互，這通常是某種授權機制。CAS使用的是所謂的Ticket。具體這點後面還會介紹。
• 授權完成後，CAS把頁面重定向，回到Web應用。Web應用此時就完成了成功的登錄（當然這也是單點登錄的客戶端，根據返回的Ticket信息進行判斷成功的）。
• 然後單點登錄服務器會在客戶端創建一個Cookie。註意，是在用戶的客戶端，而不是服務端創建一個Cookie。這個Cookie是一個加密的Cookie，其中保存了用戶登錄的信息。
• 如果用戶此時希望進入其他Web應用程序，則安裝在這些應用程序中的單點登錄客戶端，首先仍然會重定向到CAS服務器。不過此時CAS服務器不再要求用戶輸入用戶名和密碼，而是首先自動尋找Cookie，根據Cookie中保存的信息，進行登錄。登錄之後，CAS重定向回到用戶的應用程序。

這樣，就不再需要用戶繼續輸入用戶名和密碼，從而實現了單點登錄。

註意，這種單點登錄體系中，並沒有通過http進行密碼的傳遞（但是有用戶名的傳遞），因此是十分安全的。

CAS被設計為一個獨立的Web應用，目前是通過若幹個Java servlets來實現的。CAS必須運行在支持SSL的web服務器至上。應用程序可以通過三個URL路徑來使用CAS，分別是登錄URL（login URL），校驗URL（validation URL）和登出URL（logout URL）。

• 應用程序一開始，通常跳過原來的登陸界面，而直接轉向CAS自帶的登錄界面。當然也可以在應用程序的主界面上增加一個登錄之類的按鈕，來完成跳轉工作。
• 如果用戶喜歡的話，也可以手工直接進入CAS的登錄界面，先進行登錄，在啟動其他的應用程序。不過這種模式主要用於測試環境。
• CAS的登錄界面處理所謂的“主體認證”。它要求用戶輸入用戶名和密碼，就像普通的登錄界面一樣。
• 主體認證時，CAS獲取用戶名和密碼，然後通過某種認證機制進行認證。通常認證機制是LDAP。
• 為了進行以後的單點登錄，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完成主體認證後，會使用下面URL進行重定向http://www.itil.com/authenticate.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。
• 收到ticket之後，應用程序需要驗證ticket。這是通過將ticket 傳遞給一個校驗URL來實現的。校驗URL也是CAS服務器提供的。
• CAS通過校驗路徑獲得了ticket之後，通過內部的數據庫對其進行判斷。如果判斷是有效性，則返回一個NetID給應用程序。
• 隨後CAS將ticket作廢，並且在客戶端留下一個cookie。
• 以後其他應用程序就使用這個cookie進行認證（當然通過CAS的客戶端），而不再需要輸入用戶名和密碼。

采用.NET 來實現CAS原理的SSO系統，在第一個版本的SSO系統基礎上羅列一些問題，有的已經是第一個版本的SSO系統中采用的方式。有些問題需要澄清的，

很多人談論單點登錄時，常常和統一用戶，以及單一用戶管理混淆了，要麽誤認為單點登錄自然實現了單一用戶管理；要麽誤認為統一用戶或者單一用戶管理就是單點登錄。實際上，這三個概念是有明確的區別的。

統一用戶就是指不同的系統，使用同一套用戶處理的機制。

• 用戶ID全局惟一，用戶登錄名，密碼全局唯一，並且統一存儲在單一系統中。
• 用戶的一些屬性，如姓名、電話、地址、郵件等，統一存儲在單一系統中。盡管各應用系統還可以自行增加一些屬性，但是基本的屬性應該統一存儲和管理。
• 應用系統不應該直接對用戶信息的進行增加、修改和刪除，但是可以進行查詢。對用戶信息的增加、修改和刪除，應該由專門的系統進行統一的管理。

很顯然，統一用戶是單點登錄的基礎，但是統一用戶並不意味著實現了單點登錄。

單一用戶管理則指所有的用戶管理工作都在唯一的地方進行處理，而每個應用程序不再保留自己的用戶管理功能。單一用戶管理和統一用戶管理的最大區別在於，統一用戶管理之後，每個應用程序仍然保留自己的用戶管理功能，用於額外的屬性設置；而單一用戶管理時，每個應用程序不再保留自己的用戶管理功能。

在企業應用場景下，所有的用戶信息來自HR系統，HR系統中包含的戶信息和部門信息，同時這些信息會存在於公司的活動目錄中。公司采用的是LDAP和數據庫連接方式相結合,正式員工登陸OA系統並不采用LDAP方式認證，采用的RSA的token方式認證，也就是數據庫方式認證。對於忘記帶token卡和客戶服務部的外聘人員沒有token卡的，通過白名單方式允許他們通過LDAP方式認證。第一個版本的單點登陸系統使用的HTTP，新版本的集成子系統使用https方式通訊。

術語解釋：

• HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容請看SSL。它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP數據傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，現在它被廣泛用於萬維網上安全敏感的通訊。
• LDAP（全稱是Lightweight Directory Access Protocol），一般都簡稱為LDAP。它是基於X.500標準的，但是簡單多了並且可以根據需要定制。與X.500不同，LDAP支持TCP/IP，這對訪問Internet是必須的。LDAP的核心規範在RFC中都有定義，所有與LDAP相關的RFC都可以在LDAPman RFC網頁中找到。

簡單說來，LDAP是一個得到關於人或者資源的集中、靜態數據的快速方式。LDAP協議是跨平臺的和標準的協議，因此應用程序就不用為LDAP目錄放在什麽樣的服務器上操心了。實際上，LDAP得到了業界的廣泛認可，因為它是Internet的標準。產商都很願意在產品中加入對LDAP的支持，因為他們根本不用考慮另一端（客戶端或服務端）是怎麽樣的。LDAP服務器可以是任何一個開發源代碼或商用的LDAP目錄服務器（或者還可能是具有LDAP界面的關系型數據庫），因為可以用同樣的協議、客戶端連接軟件包和查詢命令與LDAP服務器進行交互。

[轉]采用CAS原理構建單點登錄