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中。
帶你了解不一樣的【赤龍ERP】：https://www.redragon-erp.com（赤龍官網查看更多功能）