簡單梳理一下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:/services
6. 原理探究
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：
）這個服務票據是臨時一次性的，有效期非常的短，也就是說，服務端發出 ST，用戶端拿
到ST，用戶端要立刻到服務端去校驗，如果中間出現某個環節時間過長，則票據驗證失敗。
）用戶端到服務端校驗 ST 後，服務端傳回的是個 XML,最終封裝成一個
信任對象（Assertion）儲存到用戶端浏覽器的 session 中,
該信任對象（Assertion）是用戶端服務保持對浏覽器信任的重要對象。
也就是說，一旦用戶端的 Session 中有了該對象，
那麼浏覽器通路該用戶端的資源無需再到CAS服務端認證了。
6.2. 單點登入的流程分析
- 下圖是通路資源時統一身份認證的大流程圖：
sso單點登入簡單剖析 - 第一次浏覽器通路用戶端 A頁面
- 浏覽器通路用戶端B 的頁面免登入流程(用戶端A登入狀态)
sso單點登入簡單剖析 - 浏覽器僞造 ST 通路用戶端 A
sso單點登入簡單剖析 - 浏覽器在用戶端 A 靠 session 中的信任對象維持認證
sso單點登入簡單剖析
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
退出的流程圖