ERP與SSO的恩怨情仇--第10篇
用日誌記錄“開源軟體”的誕生
赤龍 ERP 開源地址：
點亮星標，感謝支援，與開發者交流 kzca2000
碼雲：https://gitee.com/redragon/redragon-erp
GitHub：https://github.com/redragon1985/redragon-erp
赤龍ERP官網：https://www.redragon-erp.com
為什麼要用單點登入
首先大部分系統都不是孤立存在的，尤其是資訊化系統。它們往往在一個大的平臺上，由多個獨立的系統組成。如果想訪問多個系統，那麼多次重複的進行登陸往往是不能接受的，那麼一個統一的登陸入口就變得必不可少。這就是單點登入。
單點登入的特點是：
（1）統一的登陸入口和登出入口
（2）共享的使用者資訊資料
（3）可實現跨域、跨多應用、跨多瀏覽器的認證
（4）可實現較高的安全認證機制
（5）可擴充套件的授權機制
是否需要實現自己的SSO
是否需要實現自己的SSO呢？要回答這個問題。首先要明白SSO是如何實現的。那我們先來看看登陸如何實現，常見的做法是，輸入使用者名稱、密碼、驗證碼，點選登陸驗證使用者名稱和密碼是否正確，驗證通過後獲取使用者資訊，並跳轉請求的頁面。登陸狀態和使用者資訊一般會儲存在session、cookie或本地快取；當然有時還會引入token驗證登陸狀態。
這個過程看似實現很簡單，但裡面有個致命的問題，不管session、cookie或本地快取，都是儲存在應用伺服器本地的，這就使得統一認證、共享狀態、跨域等多個問題變得不可能。下面我們來看看SSO是如何做的：
（1）當客戶端傳送請求訪問應用的某一路徑，應用會先判斷當前使用者本地的登陸狀態，如果當前使用者存在登陸狀態則正常訪問；如果使用者沒有登入則重定向到單點登入的服務端
（2）單點登入服務端會先通過cookie驗證當前使用者在服務端儲存的登陸狀態，如果存在則跳轉回應用路徑，並在客戶端儲存登陸狀態。如果當前使用者沒有登入，則進行使用者認證。（即輸入使用者名稱和密碼的登陸動作）
（3）伺服器認證成功後，會產生一個票據，帶著這個票據並設定cookie跳轉回客戶端的接收路徑
（4）客戶端會在接收路徑中重新訪問服務端，去驗證票據的合法性，成功後反饋使用者的認證資訊和相關資料給客戶端
現在明白了單點登入是如何實現的，下面來回答本節開始的問題。要看使用場景，如果是網際網路的專案我建議自己實現或優化此流程實現，但我現在研發的是一款開源ERP，在考慮安全性，可擴充套件性、時間成本等多方面的前提下，當然沒有必要自己開發，拿成熟的產品優化即可。下面來看看我做了哪些優化。
CAS與Shiro的整合
CAS是Apache的開源SSO，解決的是認證的問題；Shiro是安全性框架，解決的是授權和會話管理。這也是【赤龍ERP】使用的兩個技術。基本流程是：
（1）Cas先做使用者認證，並獲取使用者資訊（此過程通過SSL加密）。
（2）Shiro與Cas整合，在cas認證成功後交由shiro繫結認證狀態、使用者資訊，並在shiro中獲取使用者許可權，所有資訊均儲存在會話中。
（3）通過shiro配置實現對所有請求的攔截，並可以通過標籤控制頁面顯示的內容（shiro的授權都是通過角色和許可權兩級完成的）。
【赤龍ERP】對CAS和Shiro做了哪些優化
其實不管是Cas和Shiro本來的功能上都有一些欠缺，在【赤龍ERP】中我做了相關優化。
（1）cas的登入頁面的客戶化，cas本身的登陸頁面不好看，所以需要針對不同的場景做客戶化。
（2）cas的登入頁面更多資料的提交，本身登陸頁面只接受使用者名稱和密碼的提交，不支援其他欄位，但往往有時需要提交更多的欄位，比如：賬套。
（3）cas對於通過介面進行使用者驗證的功能比較欠缺，在此也做了彌補。
（4）cas記住密碼的功能在和Shiro整合後存在一些問題，在此已解決。
（5）cas使用者登出和Shiro整合後，存在一些情況下無法同步登出的問題，在此已解決。
（6）Shiro本身的會話儲存在Ehcache本地快取中，但整合Cas後會出現跨域、跨瀏覽器、跨應用的資料同步問題，優化後將會話儲存在Redis中。
希望您讀完本文可以幫助筆者進入【碼雲】或【GitHub】搜尋“赤龍ERP”點選星標。等待著您的支援！