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

Richaaaard發表於2015-12-17

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 (6) —— Nginx代理模式下瀏覽器訪問CAS伺服器網路順序圖詳解

此代理非彼代理

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

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

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

順序圖:(來源於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

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

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

  2. 然後輸入使用者明密碼(test01/psw01)

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

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

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

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

  4. 訪問另一應用

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

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

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

代理下的網路順序分析

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

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

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

首次訪問

https://app1.hoau.com:8413/cas1
(0)使用者通過瀏覽器訪問上面地址

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

(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伺服器

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

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

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

(5)返回CAS的登陸頁面內容至代理伺服器
(6)代理將響應的內容返回給瀏覽器
(7)瀏覽器為使用者呈現登陸頁面

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

(8)使用者提交使用者名稱和密碼

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

(9)瀏覽器提交Form內容至代理
(10)代理轉發提交的內容至CAS伺服器
(11)CAS伺服器驗證使用者身份
(12)CAS伺服器返回相應至代理

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

(13)代理將響應返回給瀏覽器

並且設定Cookie

CASTGC

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

(14)瀏覽器被重定向至Protected App #1

並且攜帶ticket資訊。

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

*注意:以下(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

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

並攜帶有效的JSESSIONID,這時

如果驗證通過,則

(22)返回目標頁面的內容

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

再次訪問

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

另一個應用訪問

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

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

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

附一個Charles的http順序圖

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

結束

相關文章