cas sso原理（轉）

採用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服務器進行交互。