董恒競 宮大偉 雷遠(yuǎn)東

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

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

中圖分類號： TP311 文獻(xiàn)標(biāo)識碼 ： 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è)信息化的不斷推進(jìn)，企業(yè)應(yīng)用系統(tǒng)的數(shù)量越來越多，這些應(yīng)用系統(tǒng)一般是在不同時期，采用不同的技術(shù)、架構(gòu)開發(fā)的，都有著獨(dú)立的用戶信息庫和認(rèn)證體系。用戶在使用不同系統(tǒng)時，需要輸入不同的賬號（密碼）進(jìn)行登錄。單點(diǎn)登錄（Single Sign-on，SSO）概念的提出是企業(yè)信息化不斷深化以及網(wǎng)絡(luò)應(yīng)用不斷推廣的必然結(jié)果[1]。

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

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

2 CAS產(chǎn)品

2.1 CAS簡介

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

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

2.2 CAS的基本協(xié)議

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

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

2）重定向（Service）認(rèn)證：CAS 客戶端收到用戶請求后，重定向用戶請求到CAS服務(wù)器。

3）用戶認(rèn)證：用戶輸入信息進(jìn)行身份認(rèn)證。

4）發(fā)放票據(jù)（Service Ticket）：CAS 服務(wù)器會產(chǎn)生一個隨機(jī)Service Ticket。

5）驗(yàn)證票據(jù)：CAS 服務(wù)器驗(yàn)證票據(jù)Service Ticket的合法性，驗(yàn)證通過后，允許用戶訪問服務(wù)。

6）傳輸用戶信息（Principal）：CAS 服務(wù)器驗(yàn)證票據(jù)通過后，傳輸用戶認(rèn)證結(jié)果信息給用戶。

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

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

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

2.3 CAS的優(yōu)點(diǎn)

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

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

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

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

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

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

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

3 問題分析

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

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

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

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

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

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

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

4 CAS改進(jìn)方法

4.1改進(jìn)的總體設(shè)計(jì)

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

設(shè)計(jì)模型圖見圖3。

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

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

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

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

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

4.2 CAS Server的改進(jìn)

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

設(shè)計(jì)同步程序，從各應(yīng)用系統(tǒng)中同步賬號，并根據(jù)關(guān)鍵字段構(gòu)建賬號映射表（見表1）。關(guān)鍵字段可以為空，這時該賬號不與其它應(yīng)用系統(tǒng)的賬號關(guān)聯(lián)，單點(diǎn)登錄后僅能使用本系統(tǒng)。同時，因?yàn)殛P(guān)鍵字段可以為空，所以才不能使用關(guān)鍵字段作為單點(diǎn)登錄的ID（在Principal中）。

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

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

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

class="AccountTypeQueryDatabaseAuthenticationHandler">

4.3 CAS Client的改進(jìn)

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

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

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

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

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

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

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

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

4.5 對于驗(yàn)證且總放行頁面的支持

對于CAS客戶端的頁面，默認(rèn)是分為保護(hù)資源和非保護(hù)資源。訪問保護(hù)資源時，需要進(jìn)行單點(diǎn)登錄驗(yàn)證。驗(yàn)證通過，就放行，讓W(xué)eb瀏覽器繼續(xù)訪問受保護(hù)資源。如果驗(yàn)證不通過，則跳轉(zhuǎn)到CAS服務(wù)器的登錄頁面。

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

默認(rèn)的CAS訪問保護(hù)機(jī)制是不支持這種情況的。我們通過以下兩項(xiàng)開發(fā)解決該問題：

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

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

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

4.6 其他建議與應(yīng)用

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

2）對于WebSphere集群部署的應(yīng)用，原代碼存在單點(diǎn)登出失敗的可能，可以通過修改CAS服務(wù)器代碼得以解決。在Java類org.jasig.cas.util.HttpClient的登出代碼中增加JSESSIONID，使得WebSphere集群能夠?qū)⒌浅稣埱蠓峙涞秸_的節(jié)點(diǎn)。

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

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

5 結(jié)束語

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

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

參考文獻(xiàn)：

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

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

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

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

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

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

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

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

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

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

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