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
參考來源:
https://github.com/Jasig/java-cas-client
以下的示例採用我部落格的另外兩篇文章中搭建好的測試環境舉例
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伺服器配置詳解
測試
訪問“https://app1.hoau.com:8413/cas1”
會重定向到“https://proxy.sso.hoau.com/cas/login?service=https%3A%2F%2Fapp1.hoau.com%3A8413%2Fcas1”
然後輸入使用者明密碼(test01/psw01)
如果驗證成功,則會將瀏覽器重定向到app1的登陸成功頁面。
再次訪問“https://app1.hoau.com:8413/cas1”
可以直接進入登陸成功頁,而無需輸入使用者名稱密碼。
訪問另一應用
同樣可以通過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)