保留原系統(tǒng)賬號登錄的CAS單點登錄改進方法

董恒競 宮大偉 雷遠東

摘要：隨著企業(yè)信息化的不斷發(fā)展和應用系統(tǒng)規(guī)模的不斷擴大，企業(yè)逐漸出現(xiàn)了對多應用系統(tǒng)實現(xiàn)單點登錄（SSO）功能的需求。CAS是一款開源的單點登錄產品，基于CAS對企業(yè)應用系統(tǒng)進行單點登錄改造，可以達到單點登錄的目的。但由于各種歷史原因，企業(yè)應用系統(tǒng)都有著不同的賬號體系，賬號又與業(yè)務流程、數(shù)據存儲緊密聯(lián)系。所以在單點登錄改造過程中，許多應用系統(tǒng)都希望保留原來的賬號體系?；诖藛栴}，該文提出了一種對CAS產品進行改進的方法，在不改變原系統(tǒng)賬號體系的條件下，使得用戶可以使用多種應用系統(tǒng)的賬號進行登錄，降低了企業(yè)應用系統(tǒng)單點登錄改造的復雜度，使得單點登錄在企業(yè)內更易于實現(xiàn)。

關鍵詞：企業(yè)信息化；單點登錄；中心認證服務；輕量目錄訪問協(xié)議；企業(yè)門戶

中圖分類號： TP311 文獻標識碼 ： A 文章編號：1009-3044（2018）12-0235-04

Abstract： With the enterprise informatization， there are more and more applications in enterprises. Many enterprises have the requirement to realize the single sign-on functions. CAS is an open-source product to fix this requirement. However， due to various historical reasons， enterprise applications have different account systems. And the accounts have a close contact with the business processes， data storage， and so on. So many applications hope to retain the original account systems. Based on this problem， this paper proposes a method to make CAS to accept the original system accounts， the applications use old system accounts easily， to make the applications to have lest changes. The practice proved that this strategy makes single sign-on easier for the enterprise to realize.O

Key words： Informatization； Single Sign-On （SSO）； Central Authentication Service （CAS）； Lightweight Directory Access Protocol （LDAP）； Enterprise Portal

1 背景

隨著企業(yè)信息化的不斷推進，企業(yè)應用系統(tǒng)的數(shù)量越來越多，這些應用系統(tǒng)一般是在不同時期，采用不同的技術、架構開發(fā)的，都有著獨立的用戶信息庫和認證體系。用戶在使用不同系統(tǒng)時，需要輸入不同的賬號（密碼）進行登錄。單點登錄（Single Sign-on，SSO）概念的提出是企業(yè)信息化不斷深化以及網絡應用不斷推廣的必然結果[1]。

單點登錄是一種方便用戶訪問多個應用系統(tǒng)的技術。在對企業(yè)應用系統(tǒng)進行單點登錄改造后，用戶只需登錄一次，就可以在多個應用系統(tǒng)間自由切換[2-3]。單點登錄是企業(yè)門戶建設需要解決的首要問題[4]。

實現(xiàn)單點登錄的技術有很多，有基于經紀人、基于代理人、基于網關、基于Cookie及基于SAML等，針對不同架構系統(tǒng)使用不同的認證方式[5]?；诓煌夹g，存在很多單點登錄軟件。其中，開放源碼的單點登錄軟件有， SUN支持的OpenSSO，JOSSO，美國Internet2高級網絡聯(lián)盟（MACE）小組開發(fā)的Shibboleth系統(tǒng)以及Yale大學發(fā)起的CAS項目等等[6]。

2 CAS產品

2.1 CAS簡介

CAS（Central Authentication Service）是由Yale大學發(fā)起的，并在2004年12月正式成為JA—SIG的一個項目。CAS產品為Web應用系統(tǒng)提供了一種可靠的單點登錄實現(xiàn)方法，是目前比較流行的服務于企業(yè)單點登錄的解決方案之一[7]。

CAS包含兩個部分：CAS Server和CAS Client。CAS Server獨立部署，負責對用戶信息的認證工作。CAS服務器提供了一套易于定制的用戶認證器接口.用戶可以根據自身企業(yè)的在線系統(tǒng)的認證方式，來定制自己的認證邏輯。CAS Client負責處理對客戶端受保護資源的訪問請求，需要登錄時重定向到CAS Server[8]。

2.2 CAS的基本協(xié)議

如圖1，CAS訪問流程主要有以下6個步驟[8-9]：

1）訪問服務（CAS Client）：用戶通過客戶端瀏覽器發(fā)送請求，訪問應用系統(tǒng)提供的服務資源。

2）重定向（Service）認證：CAS 客戶端收到用戶請求后，重定向用戶請求到CAS服務器。

3）用戶認證：用戶輸入信息進行身份認證。

4）發(fā)放票據（Service Ticket）：CAS 服務器會產生一個隨機Service Ticket。

5）驗證票據：CAS 服務器驗證票據Service Ticket的合法性，驗證通過后，允許用戶訪問服務。

6）傳輸用戶信息（Principal）：CAS 服務器驗證票據通過后，傳輸用戶認證結果信息給用戶。

CAS基本的協(xié)議過程如下[9]：

和CAS Client安放在一起的是受保護的客戶端應用系統(tǒng)，利用Filter請求進行過濾方式。若受保護的資源被每個Web 請求訪問，則CAS Client 就會對該請求進行立即分析，對Http請求中是否包含Service Ticket進行查看，并將請求向CAS Server登錄地址發(fā)送，并且將Service傳遞（也就是要訪問的目的資源地址），而一旦登陸成功，則可向該地址轉回。

用戶則在第3步中將認證信息輸入，CAS Server就會隨機將一個字符數(shù)生成，Service Ticket是不可再造的、唯一的，為了將來驗證需要進行延緩，之后對Service所在的地址，系統(tǒng)自動重新登陸，并將一個Ticket Granted Cookie配置到客戶端瀏覽器配置，在拿到Service和新生成的Ticket 之后，CAS Client 在第5、6步中與CAS Server 進行身份驗證，對Service Ticket的正確性提供保障。全部與CAS的交互在這個協(xié)議中，都利用SSL協(xié)議，進而對ST和TGC的安全性提供保障。在工作過程中，該協(xié)議將兩次重新回到Service所在的地址，驗證用戶能夠見到CAS Client與CAS Server之間進行Ticket驗證的過程。

2.3 CAS的優(yōu)點

CAS開源產品具有如下優(yōu)點[10]：

1）配置簡單：CAS Server基于Spring Framework編寫，對其管理，大多只需通過配置即可；

2）支持多種認證接口：CAS Server提供了一套易于定制的用戶認證器接口，不論是傳統(tǒng)的用戶名/密碼方式、還是采用LDAP服務器，都可以通過對驗證器模板稍加修改，便可使用；

3）松散耦合：CAS被設計成可獨立部署的B/S Web應用，Server與Client分開實現(xiàn)，降低了認證模塊與應用系統(tǒng)的耦合度，提供了更好的SOA設計和更彈性的安全策略；

4）多語言支持：CAS Client支持多種語言的客戶端，如Java、.NET、PHP、Perl、Ruby等；

5）安全性高：在CAS協(xié)議中，所有與CAS的交互均采用SSL協(xié)議，保證了系統(tǒng)安全性；

6）支持復雜環(huán)境應用：CAS 2.0協(xié)議擴展了Proxy（代理）認證，Web應用可作為代理，訪問其他的Web應用。從而使CAS可支持更高級、更復雜的應用場景。

3 問題分析

基于CAS對企業(yè)應用系統(tǒng)進行改造，可以實現(xiàn)用戶單點登錄的目的[11]。對于新上線的應用系統(tǒng)，則可以完成由CAS服務器來接管用戶身份的認證。對于已經上線運行的應用系統(tǒng)，由于這些系統(tǒng)往往有著獨立的賬號數(shù)據和認證機制，而且企業(yè)有很多業(yè)務流程涉及用戶信息，單點登錄的實現(xiàn)應該盡量不要影響到這些應用系統(tǒng)的原認證模塊和具體的業(yè)務流程[12]。

論文[7]通過用戶映射（見圖2），將CAS人員信息與這些業(yè)務系統(tǒng)的人員信息關聯(lián)起來，當用戶在經過CAS認證之后，這些業(yè)務系統(tǒng)就可以正確識別用戶的身份并進行授權，以實現(xiàn)單點登錄的目的。這種模擬登錄機制是針對那些基于Form表單方式登錄的Web應用系統(tǒng)設計的，它不需要對應用系統(tǒng)的原有認證模塊做任何修改。

建立用戶映射表之后，實現(xiàn)應用系統(tǒng)模擬登錄的方式有：

1）提供一種應用登錄插件，并在CAS認證客戶端安裝該插件。通過插件的接口支持來完成自動填寫用戶名和密碼，并提交應用系統(tǒng)的登錄Form結果，以實現(xiàn)模擬登錄。

2）由應用系統(tǒng)提供Web Service接口，CAS認證中心只負責提供當前通過認證的用戶映射信息，登錄由該Web Service接口實現(xiàn)，該方式適用于企業(yè)內部，安全性要求不高的應用。

然而，在本企業(yè)中，因為應用系統(tǒng)的密碼都是密文存儲，而且企業(yè)信息安全制度也不允許建立這樣包含明文密碼的數(shù)據表。這樣使得通過用戶/密碼映射模擬用戶登錄的方法，在本企業(yè)中很難應用。

于是，該文提出了另一種較安全、保留原系統(tǒng)賬號登錄的CAS單點登錄改進方法。

4 CAS改進方法

4.1改進的總體設計

該文的設計目的是在單點登錄服務器中不存儲用戶賬號/密碼的條件下，允許由用戶選擇采用具體哪一套應用系統(tǒng)的賬號、密碼進行單點登錄。

設計模型圖見圖3。

根據該設計，在單點登錄服務器的數(shù)據庫中存儲根據App1和App2（及更多）本身賬號庫建立的賬號映射表。在用戶通過Web瀏覽器訪問App1的受保護資源時，App1會通過CAS Server進行用戶登錄、驗證。CAS Server根據用戶的輸入會選擇時通過App1的賬號庫進行驗證（或選擇App2的賬號庫），驗證通過后，會給App1應用系統(tǒng)返回根據賬號映射表構造的用戶信息。

基于CAS開源產品，進行保留原系統(tǒng)賬號登錄的單點登錄改進方法有如下特點：

1）通過賬號同步程序，定時同步用戶賬號信息，不同步賬號密碼，避免密碼泄露的問題。這種方法可以適用于密碼加密，或密碼不可讀的應用系統(tǒng)，也比模擬各應用系統(tǒng)登錄的方式更加安全。

2）在應用系統(tǒng)（CAS Client）中，增加了賬號過濾器，使得應用系統(tǒng)直接獲得本應用系統(tǒng)的賬號（登錄），避免了對應用系統(tǒng)原業(yè)務流程的干擾，使得單點登錄改造更簡單化。

3）對于分配給部門、傳真等不能映射到具體人員的賬號，或者管理員賬號，允許使用原賬號進行登錄。這樣，不需要再給這些賬號設立假的單點登錄標準賬號（一般是工號或者LDAP賬號）。使得這種僅用于個別系統(tǒng)的不針對具體個人的賬號，不擴散，仍然限制在本應用系統(tǒng)中。

4.2 CAS Server的改進

給每個應用系統(tǒng)的賬號庫（也可能多個應用系統(tǒng)采用一個賬號庫），分配一個賬號類型，如WORKNO， LDAP， OA等等。在應用系統(tǒng)賬號庫中增加賬號信息的關鍵字段，如工號（或者LDAP賬號，應用系統(tǒng)維護該關鍵字段的數(shù)據）等，關鍵字段唯一標識該賬號屬于哪一個人。

設計同步程序，從各應用系統(tǒng)中同步賬號，并根據關鍵字段構建賬號映射表（見表1）。關鍵字段可以為空，這時該賬號不與其它應用系統(tǒng)的賬號關聯(lián)，單點登錄后僅能使用本系統(tǒng)。同時，因為關鍵字段可以為空，所以才不能使用關鍵字段作為單點登錄的ID（在Principal中）。

在CAS Server的開源代碼中，修改認證憑據類、驗證處理類。在驗證憑據類中增加賬號類型屬性。在驗證處理類中增加一個“支持驗證的賬號類型”的屬性，并重寫其supports函數(shù)，使得一個處理類實例只處理特定類型的賬號類型的登錄輸入。改造后的CAS Server驗證處理流程如圖4。

這樣，在客戶端登錄時，需要向服務器傳送賬號、密碼、賬號類型三個屬性。CAS Server根據接收的賬號類型，分別交由不同驗證處理類的實例進行驗證，驗證通過后，由Principal解析器解析用戶信息（通過用戶映射表）向客戶端提供用戶信息（在Principal的attributes屬性，賬號類型到賬號的映射）。

實現(xiàn)結果，該企業(yè)中有多個驗證處理器，其中OA系統(tǒng)的驗證處理器配置文件如下XML配置。這樣，在用戶登錄選擇OA系統(tǒng)賬號進行登錄時，驗證過程將由本驗證處理器承接。具體驗證過程為：通過sql語句到MSSQL_OA的數(shù)據源中比較加密后的用戶輸入密碼與存儲密碼是否一致。

class="AccountTypeQueryDatabaseAuthenticationHandler">

4.3 CAS Client的改進

進行CAS Client代碼改造，主要是新建賬號過濾器，由該過濾器實現(xiàn)從Principal對象中解析用戶信息。建立賬號登入/登出處理接口，用戶只用特定的配置（賬號管理器的注冊）和實現(xiàn)（賬號登入/登出處理接口的實現(xiàn)），就可以實現(xiàn)對原用戶驗證過程的替代。具體過程如下：

1）在應用系統(tǒng)配置文件（例如J2EE Web工程的web.xml文件）中，注冊賬號過濾器（在CAS原過濾器之后）。并給過濾器設置兩個參數(shù)，一個是應用系統(tǒng)賬號類型（如OA），一個是賬號登入/登出處理器。

2）在賬號過濾器中，從“_const_cas_assertion_”的session變量中解析用戶信息（Principal），從用戶信息的用戶映射Map（Principal的attributes屬性）中，根據賬號類型（如：OA），取出當前應用系統(tǒng)的賬號（如：zhangsf）。

3）在賬號過濾器中，調用賬號登入/登出處理器。處理器一般是通過設置session等變量進行用戶登入，然后進行登入日志記錄等后續(xù)操作。

4）在登出時，賬號過濾器同樣調用賬號登入/登出處理程序，進行session等變量的擦除，進行登出后日志記錄等后續(xù)操作。

4.4 對于一系統(tǒng)多賬號的支持

對于一些應用系統(tǒng)，特別是開發(fā)時間較長的應用系統(tǒng)，由于其不是基于角色開發(fā)的。而在實際企業(yè)中，存在一些人兼職的可能。這樣在系統(tǒng)管理中，往往最簡便的方法是給這些人多開一個賬號。這樣，在同一個系統(tǒng)中就存在同一個人對應多個賬號的情況。

我們的設計策略是，在CAS Server的Principal解析器中將同一個人的多個賬號，通過分隔符組成一個字符串。例如，對應于表1中的OA系統(tǒng)的賬號（返回給Client）是zhangsf：：zhangsf1。通過解析，客戶端的賬號過濾器將獲得兩個賬號，分別是zhangsf和zhangsf1。在門戶系統(tǒng)中，顯示一個由CAS服務器提供的應用系統(tǒng)列表。默認，應用系統(tǒng)鏈接處不顯示賬號信息。但在存在多個賬號時，應用系統(tǒng)鏈接默認是使用第一個賬號登錄，鏈接后會顯示詳細的賬號名，可以由用戶支持采用哪個賬號進行登錄。具體用哪個賬號登錄，由賬號過濾器根據傳遞的參數(shù)（賬號順序號）進行選擇。

4.5 對于驗證且總放行頁面的支持

對于CAS客戶端的頁面，默認是分為保護資源和非保護資源。訪問保護資源時，需要進行單點登錄驗證。驗證通過，就放行，讓Web瀏覽器繼續(xù)訪問受保護資源。如果驗證不通過，則跳轉到CAS服務器的登錄頁面。

然而，在實際的應用中，存在一種需要驗證但總放行的情況。也就是在用戶未登錄時，也允許訪問，但需要獲得用戶的是否登錄及登錄信息。例如門戶頁面，在用戶未登錄時，可以訪問，顯示的是新聞類內容；在用戶登錄后，不僅顯示新聞類內容，還要顯示賬號信息和待辦事宜等等。

默認的CAS訪問保護機制是不支持這種情況的。我們通過以下兩項開發(fā)解決該問題：

1）在CAS Server上，參考默認的驗證流程（參考：login-webflow.xml文件），新建了一個驗證并返回的流程。在通過該流程進行驗證時，無論是否驗證通過，都進行到原資源的跳轉（默認是到CAS的登錄頁面）。

2）在CAS Client上，新建了一種驗證并返回的過濾器，在沒有登錄時，過濾器才起作用。根據session中的一個BOOL型變量的值，判斷是否進行驗證跳轉。在沒有登錄時，如果變量值為FALSE，先將值改為TRUE，再進行到CAS服務器的驗證跳轉；如果值為TRUE，則直接訪問系統(tǒng)頁面。

這樣，用戶在訪問該類頁面時，實際會進行兩次訪問。第一次進行用戶的驗證，第二次無論是否驗證通過都放行。頁面就可以根據用戶是否登錄，進行不同頁面內容的顯示。

4.6 其他建議與應用

1）雖然該文給出了使用各應用系統(tǒng)原賬號進行單點登錄的方法，但仍建議建立企業(yè)的LDAP服務器，將LDAP賬號作為單點登錄的首選賬號，將其他應用系統(tǒng)的賬號作為備選賬戶。這樣做，是由于用戶習慣一個賬號后，就會逐漸忘記其他登錄方式，而大家優(yōu)先使用LDAP賬號，便于企業(yè)推進統(tǒng)一的賬號管理。建議企業(yè)新上線的應用系統(tǒng)，使用LDAP的賬號管理，不要再新建更多的賬號庫。

2）對于WebSphere集群部署的應用，原代碼存在單點登出失敗的可能，可以通過修改CAS服務器代碼得以解決。在Java類org.jasig.cas.util.HttpClient的登出代碼中增加JSESSIONID，使得WebSphere集群能夠將登出請求分配到正確的節(jié)點。

3）對于基于Lotus Domino開發(fā)的Web應用的單點登錄改造，可以通過DSAPI（Domino Web Server AppIication Programming Interface）技術進行開發(fā)[10]。開發(fā)過程這里就不再敘述了。

論文中的改進方法，已在作者企業(yè)中得到了實際應用，單點登錄登入界面如圖5。其中，本企業(yè)采用工號作為用戶登錄的首選賬號類型，同時允許其他系統(tǒng)原賬號的登錄。

5 結束語

CAS（Central Authentication Service）是一款很好的開源單點登錄軟件，基于它可以很好的實現(xiàn)企業(yè)級的WEB應用系統(tǒng)單點登錄功能。但結合自身企業(yè)的不同特點，還需要對其進行一定程度的改進。該文介紹了如何進行對應用系統(tǒng)影響較小的，支持應用系統(tǒng)原賬號登錄的CAS開發(fā)改進方法。

在該企業(yè)進行應用的過程，證明了論文闡述的方法可以在遵守企業(yè)信息安全制度的條件下，有效降低企業(yè)應用系統(tǒng)單點登錄改造的難度，增強用戶的可接受程度。這應該對其他企業(yè)單點登錄實踐有一定的參考意義。

參考文獻：

[1] 吳曉潔. 基于CAS的單點登錄系統(tǒng)的實現(xiàn)[J]. 科技信息， 2013（26）： 289-200.

[2] 林滿山， 郭荷清. 單點登錄技術的現(xiàn)狀及發(fā)展[J]. 計算機應用， 2004， 24（z1）： 248-250.

[3] 沈杰， 朱程榮. 基于Yale-CAS的單點登錄的設計與實現(xiàn)[J]. 計算機技術與發(fā)展， 2007， 17（12）： 144-146， 150.

[4] 譚立球， 費耀平， 李建華， 等. 企業(yè)信息門戶單點登錄系統(tǒng)的實現(xiàn)[J]. 計算機工程， 2005， 31（17）： 102-104.

[5] 駱嘉偉， 唐國英. 區(qū)域衛(wèi)生信息化中單點登錄系統(tǒng)的設計與實現(xiàn)[J]. 計算機應用， 2012， 32（6）： 1782-1786.

[6] 李小雪， 吳中福， 鐘將， 等. 數(shù)字化校園中統(tǒng)一身份認證系統(tǒng)研究[J]. 計算機應用， 2008， 28（5）： 1146-1148， 1151.

[7] 張齊， 鐘觀寶. 基于用戶映射的CAS單點登錄系統(tǒng)設計與實現(xiàn)[J]. 信息通信技術， 2009， 3（4）： 6-10.

[8] 姚文權. 基于CAS單點登錄技術的研究與實現(xiàn)[J]. 企業(yè)技術開發(fā)， 2015（16）： 82， 84.

[9] 景民昌， 唐弟官. 開放源碼的CAS單點登錄系統(tǒng)研究[J]. 現(xiàn)代情報， 2009， 29（3）： 125-127.

[10] 朱吉軍， 王志敏. 基于SUN AM的Domino系統(tǒng)單點登錄設計與實現(xiàn)[J]. 計算機系統(tǒng)應用， 2010， 19（8）： 247-250.

[11] 趙向梅. 基于Java EE的單點登錄技術研究與實現(xiàn)[J]. 電子設計工程， 2015， 23（10）： 138-140.