簡單梳理一下SSO的實現大概流程,供需者參考.
1.什麼是 SSO？
SSO（Single Sign On），中文翻譯爲單點登錄.簡單說就是,用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
2.單系統單模到現在的多系統多模塊用戶的體驗
1.>我們發現若多個系統每次都需要登錄退出會極大的造成用戶體驗很差
2.>我們想要達到的效果就是,若一個系統登錄或退出,其它的系統自動實現登錄退出的效果.
3.>舉例說明,想要達到的效果如,登錄到了淘寶,然後直接訪問天貓的時候,天貓會自動登錄
3.SSO的優缺點
優點
1.>提高用戶體驗及效率
2.>提高開發人員的開發效果
3.>簡化管理
缺點
1.>不利於重構,設計系統過多.重構必然要兼容所有的系統
2.>無人看守桌面,因爲只需登錄一次,所有授權的應用系統都可以訪問,坑導致一些很重要的信息泄露
4. 什麼是CAS
隨着 SSO 技術的流行，相關產品也比較多，其中 CAS 就是一套方案CAS（CentralAuthentication Service），中文翻譯爲統一身份認證服務或中央身份服務，它由服務端和客戶端組成，實現了 SSO，並且容易進行企業應用的集成。
4.1. CAS 具有以下特點：
- 開源的企業級單點登錄解決方案。
- CAS Server 爲需要獨立部署的 Web 應用。
- CAS Client 支持非常多的客戶端(這裏指單點登錄系統中的各個 Web 應用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
4.2 有了CAS,系統架構就演變成了下圖這樣
4.3 CAS包含兩個部分
CAS Server(服務端) 和 CAS Client(客戶端)。CAS Server 需要獨立部署，主要負責對用戶的認證工作；CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。
CAS Server需要將war包部署在tomcat中,tomcat的版本爲8以上
5. 註冊可以訪問的客戶端
- 客戶端接入 CAS 首先需要在服務端進行註冊，否則客戶端訪問將提示“未認證授權的服務”
註冊步驟
修改服務文件: 在部署的位置找到WEB-INF/classes/services/HTTPSandXXXXXX.json 文件,這裏的值支持正則表達式，因此，也可以限定某個或某些具體的域名或 ip 才能訪問服務端。如^http://localhost.*$，是隻允許本地所有的客戶端的訪問。
相關屬性說明（瞭解）：
@class：必須爲 org.apereo.cas.services.RegisteredService 的實現類
serviceId：對服務進行描述的表達式，可用於匹配一個或多個 URL 地址
name： 服務名稱
id：全局唯一標誌
evaluationOrder：定義多個服務的執行順序- 第二步：修改 application.properties 文件，告知 CAS 服務端從本地加載服務定義文件的位置等，將下面的配置複製到配置文件的最後：(修改完成後，需要重啓服務端才能生效！)
#開啓識別 json 文件，默認 false
cas.serviceRegistry.initFromJson=true
#自動掃描服務配置，默認開啓
#cas.serviceRegistry.watcherEnabled=true
#120 秒掃描一遍
#cas.serviceRegistry.repeatInterval=120000
#延遲 15 秒開啓
#cas.serviceRegistry.startDelay=15000
#資源加載路徑
#cas.serviceRegistry.config.location=classpath:/services6. 原理探究
6.1 CAS專業術語
TGT(Ticket Granting ticket,票據授予的票據)：CAS 服務端根據登錄成功的用戶信息生成的一張大票據，該票據封裝了 TGC 和對應的用戶信息等，也用來簽發 ST(票據，TGC 可以生成 ST 票據)。換句話說，如果服務端上有 TGT，則證明某用戶正在登錄中或曾經登錄過。它之所以叫這個名字，是因爲該票據可以簽發（授予）ST。該票據存放於 CAS 服務端中，默認在內存緩存中（InMemoryService）。默認有效期爲 120 分鐘
TGC (Ticket-granting cookie, 票據授予的 Cookie)：就是一個 cookie，用來存放用戶身份相關信息（加密過的）， 數據結構是個數組對象。它是由 CAS 服務端生成，寫入瀏覽器的 cookie 中。默認有效期爲 120 分鐘，瀏覽器關閉時銷燬。
ST(Service ticket, 服務票據)：是 TGT 簽發給某個客戶端服務的一次性票據，數據結構是一個長字符串,當客戶端服務拿到該票據後，要立刻回過頭來找 CAS 服務端驗證真僞（TGT 有能力驗證）。
驗證通過，則可以訪問該客戶端請求的資源；驗證不通過，則拋出異常，提示不識別票據。
PS：
1）這個服務票據是臨時一次性的，有效期非常的短，也就是說，服務端發出 ST，客戶端拿
到ST，客戶端要立刻到服務端去校驗，如果中間出現某個環節時間過長，則票據驗證失敗。
2）客戶端到服務端校驗 ST 後，服務端返回的是個 XML,最終封裝成一個
信任對象（Assertion）保存到客戶端瀏覽器的 session 中,
該信任對象（Assertion）是客戶端服務保持對瀏覽器信任的重要對象。
也就是說，一旦客戶端的 Session 中有了該對象，
那麼瀏覽器訪問該客戶端的資源無需再到CAS服務端認證了。6.2. 單點登錄的流程分析
下圖是訪問資源時統一身份認證的大流程圖：
第一次瀏覽器訪問客戶端 A頁面
瀏覽器訪問客戶端B 的頁面免登錄流程(客戶端A登錄狀態)
瀏覽器僞造 ST 訪問客戶端 A
瀏覽器在客戶端 A 靠 session 中的信任對象維持認證
7. 單點登錄退出
實現方式
- 在任意客戶端應用的瀏覽器中點擊退出按鈕,瀏覽器會自動跳轉到 CAS 服務端提供的一個註銷成功頁面
- 如果想和淘寶一樣，退出後跳轉到登錄頁面，再次登錄後，還能回到某個應用的頁面，則需要修改服務端的配置文件。操作如下：打開服務端的\cas\WEB-INF\classes\application.properties 文件，在文件最後添加一行,修改完畢後需要重啓 cas 的服務端的服務
##
#Logout 退出
#
#是否允許退出後跳轉到登錄頁面並指定再次登錄後跳轉的頁面，
默認是 false，即登錄不重定向到 service 參數指定的頁面
cas.logout.followServiceRedirects=true- 註銷登出相關的官方配置項參考如下
##
#Logout 退出
#
#是否允許退出後跳轉到登錄頁面並指定再次登錄後跳轉的頁面，
默認是 false，即登錄不重定向到 service 參數指定的頁面
# cas.logout.followServiceRedirects=false
#退出後再次登錄需指定的頁面的參數名，默認是 service
# cas.logout.redirectParameter=service
#退出時是否先跳轉到確認頁面，默認是 false
#cas.logout.confirmLogout=false
#cas.logout.removeDescendantTickets=false
退出的流程圖
