CAS (6) —— Nginx代理模式下瀏覽器訪問CAS伺服器網路順序圖詳解

CAS (6) —— Nginx代理模式下瀏覽器訪問CAS伺服器網路順序圖詳解

---

tomcat版本: tomcat-8.0.29

jdk版本: jdk1.8.0_65

nginx版本: nginx-1.9.8

cas版本: cas4.1.2
cas-client-3.4.1

參考來源:

jasig.github.io:CAS protocol

https://github.com/Jasig/java-cas-client

通過Proxy訪問其它Cas應用

CAS負載均衡配置——SSL篇

CAS負載均衡配置

CAS客戶端叢集

• 以下的示例採用我部落格的另外兩篇文章中搭建好的測試環境舉例

CAS (1) —— Mac下配置CAS到Tomcat（服務端）

CAS (2) —— Mac下配置CAS到Tomcat（客戶端）

CAS (3) —— Mac下配置CAS客戶端經代理訪問Tomcat CAS

Mac為nginx安裝nginx-sticky-module

【高可用HA】Nginx (1) —— Mac下配置Nginx Http負載均衡(Load Balancer)之101例項

Nginx (2) —— Mac下配置Apache Httpd的Https/SSL （待出）

目標架構

此代理非彼代理

在CAS官方網站上給出了一個“Proxy Web Flow Diagram”：

順序圖：(來源於http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html)

這個方案主要適用一種場景：

有兩個應用App1和App2，它們都是受Cas Server保護的，即請求它們時都需要通過Cas Server的認證。現需要在App1中通過Http請求訪問App2，顯然該請求將會被App2配置的Cas的AuthenticationFilter攔截並轉向Cas Server，Cas Server將引導使用者進行登入認證，這樣我們也就不能真正的訪問到App2了。針對這種應用場景，Cas也提供了對應的支援。通過Proxy訪問其它Cas應用

無論是用中文關鍵字在“度娘”，還是用英文關鍵字再“谷哥”上搜尋，多數文章都是描述上面這樣一個場景。

而我這裡介紹的“代理”，並非是上述場景——依靠代理去驗證ticket，“代理”在此的角色是：

• 只做分發反向代理（未來的負載均衡器）

* 注意：所以說“此代理非彼代理”

準備

要搭建上面這個環境會相對複雜，我們需要參照之前的文章準備以下必備的元件或環境：

CAS (5) —— Nginx代理模式下瀏覽器訪問CAS伺服器配置詳解

測試

1. 訪問“https://app1.hoau.com:8413/cas1”

   

   會重定向到“https://proxy.sso.hoau.com/cas/login?service=https%3A%2F%2Fapp1.hoau.com%3A8413%2Fcas1”

2. 然後輸入使用者明密碼（test01/psw01）

   如果驗證成功，則會將瀏覽器重定向到app1的登陸成功頁面。

   

3. 再次訪問“https://app1.hoau.com:8413/cas1”

   可以直接進入登陸成功頁，而無需輸入使用者名稱密碼。

4. 訪問另一應用

   同樣可以通過test01使用者直接進入登陸成功頁，而無需輸入使用者名稱密碼。

   

上面基本測試通過，我們接著分析網路順序。

代理下的網路順序分析

由於這個場景較為簡單，所以jasig官網上並沒有給出這個場景下的網路順序圖。於是我自己畫了一個。

仔細觀察可以發現：上圖與不通過nginx代理時，官網的序列圖類似，只有代理出多了轉發和反向的工作。

首次訪問

https://app1.hoau.com:8413/cas1

（0）使用者通過瀏覽器訪問上面地址

（1）瀏覽器訪問Protected App #1

（2）Protected App #1嘗試驗證身份

首次登陸，身份驗證未通過，返回重定向訊息

302 Location 
https://proxy.sso.hoau.com:443/cas/login
    ?service=https://app1.hoau.com:8413/cas1

（3）瀏覽器重定向以上地址至代理伺服器Proxy

（4）Proxy將次請求分發至CAS伺服器

https://sso.hoau.com:8433/cas/login
    ?service=https://app1.hoau.com:8413/cas1
    

CAS伺服器發現使用者沒有SSO的Session，然後返回CAS的登陸頁面內容

（5）返回CAS的登陸頁面內容至代理伺服器

（6）代理將響應的內容返回給瀏覽器

（7）瀏覽器為使用者呈現登陸頁面

（8）使用者提交使用者名稱和密碼

（9）瀏覽器提交Form內容至代理

（10）代理轉發提交的內容至CAS伺服器

（11）CAS伺服器驗證使用者身份

（12）CAS伺服器返回相應至代理

（13）代理將響應返回給瀏覽器

並且設定Cookie

CASTGC

由於身份驗證成功，此刻瀏覽器被要求重定向至Protected App #1的登陸頁

（14）瀏覽器被重定向至Protected App #1

並且攜帶ticket資訊。

*注意：以下（15）、（16）、（17）和（18）步為Protected App #1與CAS Server背後的互動。

Protected App #1 收到請求後，會再次訪問CAS Server以驗證ticket。

（15）（16）Protected App #1通過Proxy請求serviceValidate

（17）（18）CAS伺服器經由代理返回響應資訊

（19）如果CAS伺服器校驗通過

則會設定Cookie JSESSIONID，然後將重定向資訊返回到瀏覽器

（20）瀏覽器再次訪問Protected App #1

並攜帶有效的JSESSIONID，這時

（21）Protected App #1會校驗Session Cookie

如果驗證通過，則

（22）返回目標頁面的內容

再次訪問

https://app1.hoau.com:8413/cas1

另一個應用訪問

https://app2.hoau.com:8423/cas2

以上“再次訪問”和“另一應用訪問”不在贅述，大家可以自行測試，或參考無代理情況下的序列圖：

CAS (4) —— CAS瀏覽器SSO訪問順序圖詳解（CAS Web Flow Diagram by Example）

附一個Charles的http順序圖

結束