混合架構電網數據管控平臺的統一認證研究

馬凱 楊強 謝善益

摘 要：在電力企業內部網中，通過統一認證服務來實現多個Web系統間登錄用戶信息和狀態共享已經隨處可見，其中基于Apereo CAS的統一身份認證是比較常見的一種解決方式。但是Web系統單點登錄只是嚴格限制用于那些通過瀏覽器訪問的應用，在現如今的電力系統架構中，一套系統往往會比較復雜，可能既包含了某些Web應用，也可能會含有C/S架構的客戶端、服務器或服務模塊，這種混合架構場景下的統一身份認證通過基本的CAS是難以實現的。本文正是在混合結構模式下的配用電網數據管控平臺之上，在保留CAS原有SSO認證過程的前提下，對其進行一定擴展，實現了C/S端跳向B/S端的統一認證過程，由此擴展了CAS的使用范圍。

關鍵詞：CAS;統一身份認證;混合架構;單點登錄

DOI：10.16640/j.cnki.37-1222/t.2019.19.139

0 引言

近些年隨著互聯網技術和計算機技術的不斷發展，電力企業中的應用系統規模越來越大、復雜度也越來越高，對系統的安全訪問控制需求也越來越嚴格[4]。傳統的單系統獨立登錄認證的方式，在應用系統部署較多的情況下，使得在不同系統之間切換時需要不斷重復錄入用戶名和密碼，甚至有時用戶在不同系統間使用的是同一套認證信息，這無形中增加了系統使用者的麻煩，而且頻繁的錄入敏感信息，也增加了信息安全性風險[1-2]。因此，通過統一的認證服務來實現不同系統間用戶信息共享，將各應用系統的認證過程連接起來是必然的趨勢[4]。

另一方面，系統的組成也越來越來復雜，往往一套大系統內同時會包含多個子系統應用，子系統的架構類型也往往不同，一個子系統可能是瀏覽器/服務器（B/S）架構的Web應用，也可能為客戶端/服務器（C/S）類型，亦或是移動端類型應用，這對統一認證服務的功能性提出了更高要求。

在當今的互聯網應用系統中，系統的登錄認證過程可以通過Oauth2.0協議獲取微信、QQ、微博等等網絡應用的用戶信息和狀態，實現統一認證和用戶信息共享。但是在電力企業內部網絡中，受到網絡和安全管理等方面的限制，各應用系統不可能也不允許連接到外部互聯網上去，因此都是通過獨立部署中心認證服務器來實現單點登錄及統一認證服務。

配用電網數據管控平臺建立并維護配用電網全域統一信息模型，結合自組織設備接入和多源匯集規范化融合配用電業務領域系統數據，通過標準化服務為各應用提供綜合數據應用支持。配用電網數據管控平臺系統架構為混合架構，包含多個B/S和C/S子系統應用，平臺基于開源項目CAS來實現Web應用間的單點登錄[3]（Single Sign On，SSO），由于基于中心認證服務（Central Authentication Service，CAS）的單點登錄嚴格適用于使用Web瀏覽器訪問的應用程序，因此需要在CAS認證服務器源碼額外開發新的服務擴展接口來協調平臺的C/S端和B/S端之間的統一認證過程。

1 配用電網數據管控平臺架構

配用電網數據管控平臺完成系統部署范圍內配用電網數據標準化匯集、管理及發布，包括Web應用、系統控制臺及管理工具、后臺服務模塊服務器、Web認證服務器等幾部分。

平臺的Web應用系統基于CIM管控電網模型、實時、歷史等各類數據，實現數據瀏覽及管理、系統管理、任務監測、服務器狀態監測等系列功能。

系統控制臺（XFront）是平臺數據管理工具的啟動入口，通過系統控制臺窗口可以打開運行模型管理工具（XSchema）、數據管理工具（XStudio）等高級桌面維護工具，并且系統控制臺的主界面能夠顯示當前服務器群及服務模塊的實時狀態概要。

后臺服務模塊服務器包括模型服務器、數據服務器、UA服務器、總線服務器、數據匯集任務模塊等，為應用提供數據接口服務及運行保障。

配用電網數據管控平臺的認證需求：

Web應用能在同一個網絡內的任意計算機節點通過瀏覽器訪問，基于CAS的Web認證服務器為Web應用提供統一認證服務。

系統控制臺及其管理的高級管理工具是C/S模式的客戶端程序，由維護人員進行特殊維護時使用，需要安裝部署在指定的服務器，只有在指定的計算機節點才能使用。系統控制臺本身具有登錄訪問控制功能，登錄后才能啟動Xschema、Xstudio等高級維護工具，系統控制臺自身的登錄不受Web認證服務器管理。

系統控制臺同時也有鏈接按鈕能夠打開瀏覽器并跳轉到特定Web應用頁面，此時的系統控制臺登錄狀態需要與Web認證服務器進行聯動交互：當系統控制臺已經是登錄狀態時，跳轉訪問的Web應用也應該是登錄狀態，不需要在瀏覽器重新登錄驗證。

平臺混合架構示意圖如圖1所示。

2 CAS認證原理

開源框架Apereo CAS通常稱為CAS[5]，是一種針對Web的企業多語言單點登錄解決方案，并且能夠成為企業系統身份驗證和授權需求的綜合平臺。

CAS的系統架構由兩部分組成：CAS服務器和CAS客戶端，它們兩個之間通過各種協議進行通信來完成交互認證過程。

CAS服務器：CAS服務器是基于SpringMVC和Spring Webflow框架構建的Java Servlet，主要職責是進行用戶驗證，并通過生成和驗證Ticket（票證）來授予對CAS客戶端的訪問權限。CAS服務器需要獨立部署。

CAS客戶端：CAS客戶端通常來說就是指通過協議與CAS服務器進行通信的任何CAS支持的應用程序。CAS提供了一個軟件包，可以與各種軟件平臺和應用程序集成，以便通過某種身份驗證協議（如CAS，SAML，OAuth）與CAS服務器進行通信，比如Java平臺的Java Cas Client、.NET平臺的.NET CAS Client、Python的pycas等等[5]。CAS客戶端與受保護的客戶端應用集成部署到一起。

CAS的認證核心就是票據（Ticket）。CAS的主要Ticket[6]有TGT、ST、PGT、GPTIOU、PT，其中TGT、ST是配電網數據管控平臺應用中主要應用的票據，PGT、PGTIOU、PT是CAS2.0代理模式協議中用到的票據，這里不做說明。

當用戶開始對CAS客戶端（應用程序）某個資源進行訪問時，CAS客戶端判斷當前是否進行過身份認證，如果沒有經過認證，則會重定向到CAS服務器進行認證，客戶端以過濾器的方式來實現這個過程。CAS服務器返回給瀏覽器一個登錄認證頁面，用戶填寫正確的信息提交給CAS服務器，CAS服務器認證成功后，會在服務器生成一個票據TGT（Ticket Granting Ticket），并且將這個TGT存放在服務器緩存，不僅如此，服務器還會在用戶的瀏覽器生成一個Cookie TGC（Ticket Granting Cookie），TGT的ID以Cookie的形式放在這個TGC中。可以說TGT是CAS認證過程中最重要的票據，擁有TGT用戶就可以證明自己在CAS服務器中成功登錄過，每個登錄成功會話都只保存一份TGT，并且在TGT中保存了當前登錄用戶的信息。TGT的核心作用是為用戶簽發ST（Service Ticket），顧名思義，ST是CAS為用戶簽發的訪問某一服務的票據。如果用戶在登錄應用A成功后，再次提出訪問應用B的某項服務的請求，應用B將請求再一次轉向CAS服務器，此時CAS服務器會識別出這次請求中攜帶了TGC中的值，然后CAS服務器會根據這個值從服務器緩存中提取TGT，TGT簽發ST并將ST返回給應用B客戶端，B接收到ST后在后臺以特定協議再次發送給CAS服務器確認，服務器通過認證之后將用戶信息返回給應用B，應用B通過瀏覽器將用戶請求的資源返回。上面應用B跟CAS服務器之間的交互過程，對用戶來說是完全透明的，用戶在瀏覽器中看不到票據交互過程，對用戶來說只是看到了請求的頁面得以正確響應而已。

CAS的傳輸協議使用HTTPS安全協議，保證了Cookie傳輸過程中的安全性，由于認證過程中使用的Cookie對象TGC只是CAS認證服務器端進行過使用，所以使得Cookie的跨域問題得到了很好解決。

整個過程完整的時序流程[5]如圖2和圖3所示。

3 數據管控平臺Web系統的CAS應用實現

配用電網數據管控平臺的Web子應用使用Java語言進行開發，CAS提供了對Java語言的支持。對CAS的集成首先需要解決的是CAS服務器和CAS客戶端的集成。

CAS服務器是需要單獨部署的Web服務器，CAS提供了完整的服務器工程源碼，平臺根據需要修改了自己風格的登錄頁。

CAS服務器的適配修改主要有兩個步驟來實現：

（1）修改CAS服務器的用戶認證過程，轉換為平臺認證接口，由于在用戶登錄過程中，為了更好的保證數據傳輸時的安全性，Web應用在前端對密碼使用了RSA加密，所以在接收到密碼的Action首先需要進行密碼解密。

根據Webflow中的定義，服務器處理處理用戶提交的信息是在AuthenticationViaFormAction類的submit方法進行，解密后，將用戶提交信息封裝成特定格式對象傳遞給認證處理類。

CAS在Spring配置文件中定義了認證管理器bean：authenticationManager，認證管理器的屬性authenticationHandlers指定了認證用戶的具體處理類，添加應用自己的處理類XOAUsernamePasswordAuthenticationHandler實現父類方法，在方法內根據平臺自己的認證處理邏輯來進行用戶認證，如圖4所示。

（2）根據圖2、圖3流程圖知道，在CAS服務器通過serviceValidate服務校驗完CAS客戶端的ST票據后，如果校驗成功，需要向CAS客戶端返回一個XML格式的響應，響應里包含當前認證

的用戶以及一些需要傳遞的自定義屬性。

CAS服務器實現該過程的類是ServiceValidateController，在handleRequestInternal方法中校驗完成后，在casServiceValidationSuccess.jsp中定義了返回數據的XML格式，應用根據需要修改這個頁面文件就可以實現向客戶端返回數據。

CAS客戶端是CAS提供的一套軟件包，將jar包放到Web應用的classpath下，確保Web應用可以引用到。

平臺Web應用的安全訪問控制采用SpringSecurity實現，CAS客戶端的適配修改內容也主要參照CAS官方指導中與SpringSecurity的結合說明，一些細節配置不在此敘述，其中兩個較為關鍵的修改如下：

（1）未認證的用戶請求Web應用資源，經過過濾器攔截后跳轉到CAS認證服務器。在配用電網數據管控平臺運行環境中，認證服務器在啟動時已經向平臺的后臺XAgent代理模塊注冊，CAS客戶端同樣運行在平臺環境中，可以通過XAgent中注冊的認證服務器名動態獲取認證服務器IP地址進行跳轉。在調用解析認證服務器地址接口時，如果傳入原始Web應用請求IP，XAgent可以根據傳入IP更準確解析認證服務器地址，這在認證服務器是多IP服務器以及部署在內網進行了內外網IP映射時，解決跳轉認證服務器地址不正確的問題。

（2）涉及到與認證服務器交互的編碼過程都需要同上文一樣動態解析認證服務器地址，另外一個需要修改請求地址的位置是客戶端向認證服務器發送serviceValidate請求，以校驗客戶端ST的過程。CAS客戶端java庫使用Cas20ServiceTicketValidator類來發送該請求，在validate方法中解析認證服務器地址，然后進行轉發。

4 平臺混合架構下的CAS擴展方案

CAS只提供了Web應用的單點登錄支持，配用電網數據管控平臺需要在C/S端的系統控制臺XFront打開瀏覽器并訪問某個Web應用的資源。

CAS服務器的認證流程全部定義在Spring Webflow的配置文件中，流程起始位置是在認證服務器位置請求“/login”。創建一個為XFront認證服務的流程xfrontcheck，在這個新工作流中，流程的起始位置是在認證服務器位置請求“/xfrontcheck”。

由于沒有CAS客戶端與CAS認證服務的交互過程，而且由于在XFront客戶端已經完成了用戶的認證過程，所以不再需要CAS認證服務器常規的用戶名和密碼認證過程。代替的是圖1所示，XFront將請求跳轉到認證服務器，并且攜帶兩個參數，一個是已經由平臺認證后簽發的ticket憑證字符串，另一個是認證通過后請求的原始Web應用資源地址串。這個請求串的示意樣式為：https：//192.168.0.XXX：8043/xwebcas/xfrontcheck/？t=xxxxxxxxxx&s=https%3A%2F%2Fapp-a.example.com%2F，該請求在瀏覽器中傳遞，參數字符串需要進行轉碼傳輸。在CAS服務器接收到上面請求后，獲取到ticket并調用平臺校驗接口，平臺認證該ticket有效之后，CAS認證服務器認為認證成功，繼續生成TGC、TGT和簽發ST的過程，這個過程就與之前的過程完全一致了。

5 結論

本文基于Apereo CAS框架，實現了電力系統中配用電網數據管控平臺的Web系統單點登錄，實現了應用系統的統一管理，有效解決了用戶在多個應用系統之間頻繁登錄的問題，提高了系統操作便利性和系統安全性。

另外，在此基礎上，對CAS的SSO認證過程進行了擴展，改造了現有平臺認證模式，在平臺認證體系中增加用戶認證憑證概念，并由此實現了C/S端跳向B/S端的統一認證過程，擴展了CAS框架的使用范圍，為之后的混合架構下多端統一認證研究提供了一種可參考范例。

參考文獻：

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

[2]李建佳，王晶.基于JA-SIG CAS統一認證平臺（SSO）的設計與實現[J].廣東海洋大學學報，2013，33（03）：78-83.

[3]施正曄.SSO單點登錄模型的優化研究[J].計算機光盤軟件與應用，2012（S1）：190-191.

[4]呼和，張欽，陳國青，楊旸.基于Web服務的企業統一認證與授權系統[J].計算機應用，2011，31（02）：577-580.

[5]Aperea CAS.Enterprise Single Sign-On for All[DB/OL]. https：//apereo.github.io/cas/4.2.x/index.html.

[6]王永.基于CAS和Shibboleth的單點登錄研究與設計[D].成都：電子科技大學，2011.