cas單點登陸認證的場景演示與分析

概念：

CAS爲用戶簽發登陸票據，CAS認證成功後，將TGT對象放入本身的緩存，CAS生成cookie即TGC，自後
登陸時若是有TGC的話，則說明用戶以前登陸過，若是沒有，則用戶須要從新登陸。
TGC （Ticket-granting cookie）：存放用戶身份認證憑證的cookie，在瀏覽器和CAS Server用來明確用戶身份的憑證。
ST（Service Ticket）：CAS服務器經過瀏覽器分發給客戶端服務器的票據。一個特定服務只能有一個惟一的ST

安裝CAS服務端

一、經過git下載
git clone -b 5.1 https://github.com/apereo/cas...
二、maven命令打war包
解壓後 cd cas-overlay-template 
mvn clean package
三、tomcat部署
從target下找到war放到tomcat的webapps裏，啓動便可

配置cas服務端
War包web-inf的application.properties文件

一、配置靜態密碼
原cas.authn.accept.users=casuser::Mellon改成
cas.authn.accept.users=admin::111111
二、增長受權，支持http
增長cas.tgc.secure=false
cas.serviceRegistry.initFromJson=true
關於ssl的都屏蔽
修改servicesHTTPSandIMAPS-10000001.json，修改成https|imaps|http

---

自有應用接入示例

基於springboot應用程序，改造原登陸代碼，實現cas服務端登陸後當前程序不須要登陸。
本例沒有使用cas官方客戶端，即本例僅經過跳轉到cas服務端建立登陸cookie。而後登陸成功後返回當前的應用的固定方法，由其根據返回的TICKET經過get請求去cas服務端確認是不是正常的票據，並取的登陸帳號，而後根據帳號進入系統。
這裏業務系統的登陸權限控制仍使用自帶的。即只有第一次登陸涉及到cas，後續全部請求不在與cas有關係。
如下是兩個系統，入口地址
系統1：casapp1.com:8081/xit1/loginSsoValidate
系統2：casapp2.com:8082/xt2/loginSsoValidate

第一次在瀏覽器輸入系統1的入口地址
因爲此時在瀏覽器沒有ca服務給寫入的tgc cookie。會經過代碼重定向到casserver進行登陸認證。
認證成功後會根據前期提供的service地址，再回調，並給客戶端生成tgc cookie。
核心程序以下：

@RequestMapping(value={"/loginSsoValidate"}
  public String loginSso(HttpServletRequest request, HttpServletResponse response, Model model, LoginBean loginBean)
  {
      String ticket= request.getParameter("ticket");
//第一次登陸，直接重定向到casserver
      if(ticket==null||"".equals(ticket)){
          return "redirect:"+"http://casserver.com:8080/cas/login?service=http%3a%2f%2fcasapp1.com%3a8081%2fepm%2floginSsoValidate"; 
      }
//登陸成功後回調，從server端根據票據獲取登陸信息。有了登陸帳號再去進行本身的登陸受權控制。
            ResponseEntity<String> resp = template.exchange(
              "http://casserver.com:8080/cas/serviceValidate?service=http://casapp1.com:8081/epm/loginSsoValidate&ticket="+ticket,
                HttpMethod.GET, null, String.class);
        String body = resp.getBody();
        Document document;
        String portalname="";
        try {
            document = DocumentHelper.parseText(body);
            Node userNode=document.selectSingleNode("//cas:user");
            if(userNode!=null){
                //根據節點對象獲取登陸帳號      
                portalname=userNode.getText();
            }else{
                portalname="";                
            }
        } catch (DocumentException e1) {
            e1.printStackTrace();
        }

單點登陸進程分析（對應上面程序）

圖片爲重定向到casserver的效果

一、重定向到casserver登陸界面
=============================================================
WHO: audit:unknown
WHAT: [event=success,timestamp=Thu Aug 08 15:25:30 CST 2019,source=RankedAuthenticationProviderWebflowEventResolver]
ACTION: AUTHENTICATION_EVENT_TRIGGERED
APPLICATION: CAS
WHEN: Thu Aug 08 15:25:30 CST 2019
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
二、登陸認證
=============================================================
WHO: admin
WHAT: Supplied credentials: [admin]
ACTION: AUTHENTICATION_SUCCESS
APPLICATION: CAS
WHEN: Thu Aug 08 15:27:50 CST 2019
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
三、Tgc-cookie生成
=============================================================
WHO: admin
WHAT: TGT-**********************************************DXpPUQE1bK-lenovo-PC
ACTION: TICKET_GRANTING_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 08 15:27:50 CST 2019
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
四、st(tiket票據)生成
=============================================================
WHO: admin
WHAT: ST-7-asvaBsIRu1qPlNcPVbAJ-lenovo-PC for http://casapp1.com:8081/epm/loginSsoValidate
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 08 15:27:50 CST 2019
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
=============================================================
四、st(tiket票據)驗證
=============================================================
WHO: admin
WHAT: ST-7-asvaBsIRu1qPlNcPVbAJ-lenovo-PC
ACTION: SERVICE_TICKET_VALIDATED
APPLICATION: CAS
WHEN: Thu Aug 08 15:27:50 CST 2019
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1

單點登陸到第二個系統的時候
一、重定向cas登陸控制，此時發現瀏覽器已經存在tgc，則不須要登陸
=============================================================
WHO: audit:unknown
WHAT: [event=success,timestamp=Thu Aug 08 15:31:48 CST 2019,source=InitialAuthenticationAttemptWebflowEventResolver]
ACTION: AUTHENTICATION_EVENT_TRIGGERED
APPLICATION: CAS
WHEN: Thu Aug 08 15:31:48 CST 2019
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
二、st(tiket票據)生成
=============================================================
WHO: admin
WHAT: ST-8-TT6YJMhAWk22lIUyZHC5-lenovo-PC for http://casapp2.com:8082/cepm/loginSsoValidate
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 08 15:31:48 CST 2019
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
三、st(tiket票據)驗證
=============================================================
WHO: admin
WHAT: ST-8-TT6YJMhAWk22lIUyZHC5-lenovo-PC
ACTION: SERVICE_TICKET_VALIDATED
APPLICATION: CAS
WHEN: Thu Aug 08 15:31:49 CST 2019
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1

Tgc cookie在瀏覽器的狀況

總結概括

Request1
　　　　【第一步】終端第一次訪問CAS—Client1，AuthenticationFilter會截獲此請求：
　　　　一、首先，檢測本地Session沒有緩存有用戶信息；
　　　　二、而後，檢測到請求信息中沒有ST；
　　　　三、因此，CAS—Client1將請求重定向到CAS—Server，並傳遞 Service （也就是要訪問的目的資源地址，以便登陸成功事後轉回該地址），例：【https://cas:8443/cas/login?service=http0%3A8081%2F】
　　　　【第二步】終端第一次訪問CAS—Server：
　　　　一、CAS—Server檢測到請求信息中沒有TGC，因此跳轉到本身的登陸頁；
　　　　二、終端輸入用戶名、密碼登陸CAS—Server，認證成功後，CAS—Server會生成登陸票據—TGT（集成了用戶信息與ST），並隨機生成一個服務票據—ST與CAS會話標識—TGC。TGT實際上就是Session，而TGC就是這標識這個Session存到Cookie中的SessionID；ST即，根據Service生成Ticket。
　　　　三、而後，CAS—Server會將Ticket加在url 後面，而後將請求redirect 回客戶web 應用，例如URL爲【http://192.168.1.1:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZ】
　　　　【第三步】這時，終端攜帶ticket再次請求CAS—Client1：
　　　　一、這時客戶端的AuthenticationFilter看到ticket 參數後，會跳過，由其後面的TicketValidationFilter 處理；
　　　　二、TicketValidationFilter 會利用httpclient工具訪問cas 服務的/serviceValidate 接口, 將ticket 、service 都傳到此接口，由此接口驗證ticket 的有效性，即向CAS—Server驗證ST的有效性。
　　　　三、TicketValidationFilter若是獲得驗證成功的消息，就會把用戶信息寫入web 應用的session裏。至此爲止，SSO 會話就創建起來了。
　　Request2
　　　　上面說了SSO 會話已經創建起來了，這時用戶在同一瀏覽器裏第二次訪問此web 應用（CAS—Client1）時，AuthenticationFilter會在session 裏讀取到用戶信息，這就表明用戶已成功登陸，因此就不會去CAS 認證了。
　　Request3
　　　　【第一步】與Request1是徹底同樣的，以下：終端第一次訪問CAS—Client2，AuthenticationFilter會截獲此請求：
　　　　一、首先，檢測本地Session沒有緩存有用戶信息；
　　　　二、而後，檢測到請求信息中沒有ST；三、因此，CAS—Client1將請求重定向到CAS—Server，並傳遞 Service （也就是要訪問的目的資源地址，以便登陸成功事後轉回該地址），例：【https://cas:8443/cas/login?service=http0%3A8081%2F】
　　　　【第二步】而後，終端第二次訪問CAS—Server：此時，Request中會帶有上次生成的TGC，而後根據TGC（SessionID）去查找是否有對應的TGT（Session），若是有，表明此用戶已成功登陸過，因此此時用戶沒必要再去登陸頁登陸（SSO的體現），而CAS—Server會直接用找到的TGT簽發一個ST，而後重定向到CAS—Client2，剩下的如Request1中的【第三步】就徹底同樣了。