集成基於CAS協議的單點登錄

　　相信你們對單點登錄（SSO，Single Sign On）這個名詞並不感到陌生吧？簡單地說，單點登錄容許多個應用使用同一個登錄服務。一旦一個用戶登錄了一個支持單點登錄的應用，那麼在進入其它使用同一單點登錄服務的應用時就再也不須要從新登錄了。而CAS協議則正是各單點登錄產品所須要實現的協議，其全稱爲Central Authentication Service。

　　那爲何要寫這篇博客呢？這是由於在爲公司的產品集成SSO的時候，我發現若是軟件開發人員不瞭解CAS協議，那麼他在集成出現錯誤的時候將徹底沒有辦法對出錯的緣由進行分析。

 

單點登錄簡介

　　若是您不知道單點登錄是什麼，那麼先來體會一次單點登錄。首先，請在一個全新瀏覽器（或者清除了登陸信息緩存的瀏覽器）的地址欄中鍵入www.hotmail.com，並進入您的hotmail郵箱。接下來，咱們再訪問www.msn.com。請看網頁的右上角，您會發現您已經成功地經過剛剛的hotmail郵箱登入了www.msn.com：

　　這就是單點登陸：即便hotmail和msn的域名代表它們完徹底全就是兩個不一樣的網站，可是因爲它們使用了同一個單點登陸服務，所以在登錄hotmail以後再登錄msn，您剛剛輸入的用戶身份憑證依然有效。

　　這種在一處登陸就能直接訪問其它應用的功能在企業級應用中是很是有用的。試想這樣一個情景：在天天的工做中，咱們總須要經過瀏覽器訪問幾十個系統。如在瀏覽器中閱覽公司郵件，在須要撰寫Wiki的時候須要登陸到公司的Wiki系統。而報銷，請假，公司共享文件服務器等都須要用戶登錄。並且若是一個公司的IT部門對安全比較重視，那麼他們還會要求員工在必定時間內更換一次密碼。試想一下，若是公司內部有幾十個系統，那麼每一個員工都須要維護幾十個密碼，而且每隔幾天就須要針對一個系統更改一個密碼。這種密碼管理的開銷不管對於員工自己仍是對於IT開銷都是巨大的。

　　反過來，若是這些系統都使用同一個用戶登陸服務，那麼咱們就能夠免除在每次登入一個系統時都要輸入密碼的開銷，並且每一個員工只須要管理一個密碼。

　　所以，若是但願本身的企業級應用可以成功地進入各個大型企業，那麼這個產品就必須支持標準的單點登陸協議，即CAS協議。而只有在正確地理解了CAS協議的基礎之上，咱們才能在咱們的產品中正確地添加對單點登陸的支持。而這也即是我寫這篇文章的真正緣由。

 

CAS協議的工做流程

　　如今咱們知道了單點登陸給咱們所帶來的好處，可是咱們並不知道它是如何工做的。因爲CAS協議的執行流程較爲複雜，所以，讓咱們首先來看一個生活中的與單點登陸類似的事例，以輔助咱們對單點登陸運行流程的理解。

　　假設公司立刻就要來一位新同事，公司的行政人員須要在該同事到來前爲他置辦好平常工做所須要的各類辦公用品。這些辦公用品包括工做用的電腦以及一套全新的辦公桌椅。在置辦完這些辦公用品後，該行政人員還要拿着購買辦公用品時所開具的發票去公司的財務部報銷。爲了節省時間，該行政人員將會使用公司車輛在公司和賣場之間運送貨物。

　　因爲公司的司機經常在外奔波，所以他可能並不知道當天須要載着這位行政人員去購買辦公用品。在該行政人員找到他以後，他沒法確認行政人員的用車安排是否與公司的其它安排相沖突。所以司機會讓行政人員打電話給公司的領導確認他是否能夠用車。領導接到了該行政人員的電話並陳述用車的原因後，行政人員會將電話轉交給司機，讓司機本人與領導溝通。在獲得了領導的確定答覆後，司機就能夠放心地載着該行政人員去電腦城購買電腦了。

　　當該行政人員在當天再次找到該司機說須要購買辦公桌椅的時候，該司機就再也不須要打電話詢問領導。由於他已經打電話和領導詢問過是否該行政人員須要用車的事情。

　　在全部的辦公用品置辦完畢之後，該行政人員就會去公司的財務處報銷。在見到財務人員以後，該行政人員會直接說和領導以前已經溝經過並獲得過批准。在該財務人員直接打電話給該領導並簡單提起購買辦公用品的事情後，領導就會很快地確認須要爲一位新來的員工購買辦公用品的事情。在獲得了確定的答覆後，該財務人員將直接接受報銷申請並迅速進入結算程序。

　　在整個過程當中，行政人員都是資源的訪問者及使用者。在每次嘗試使用這些資源時，資源的管理者都須要領導的批准來給與該行政人員使用資源的權利。只是在不一樣時刻，因爲領導及資源管理者所獲得的信息量並不相同，所以產生了三種不一樣的使用資源的流程。

　　在第一次用車的時候，因爲司機和領導都不清楚當天該行政人員須要用車，所以該行政人員須要從領導那裏獲得能夠用車的許可，並將領導的許可轉交給司機，進而真正得到使用公司車輛的權利。在該過程當中，行政人員既須要與司機溝通，又須要與領導溝通，而司機也須要與領導溝通。

　　在第二次用車的時候，因爲司機已經知道領導對於車輛使用的受權，所以他再也不須要額外的溝通而直接容許該行政人員使用公司車輛。在該過程當中，行政人員只須要和司機溝通，而再也不須要與領導打招呼。

　　而在報銷的過程當中，因爲財務人員並不知道購買辦公用品是否已經得到了領導的贊成，所以須要詢問領導。而此時領導已經知道財務人員是爲了新入職的同事準備的辦公用品，所以將直接贊成對該筆款項進行報銷，也再也不須要行政人員再次向領導解釋公司未來一名新員工的事宜。在該過程當中，財務人員須要與行政人員以及領導溝通。

　　CAS協議的運行流程實際上與上面所舉示例的運行基本一致：第一次訪問一個應用時，系統將要求用戶轉到SSO系統，輸入表示本身身份憑證的用戶名和密碼，才能獲得訪問該應用的權限。而在第二次訪問同一應用的時候，因爲應用已經知道該用戶曾經得到了訪問權限，所以將直接容許用戶對該應用進行訪問。若是用戶訪問另外一個應用，那麼該應用將會根據用戶當前所獲得的身份憑證去SSO系統認證，從而得知用戶已經擁有了對該應用的訪問權限。

　　下面就是經過CAS協議第一次訪問應用併成功登陸的流程圖：

　　上面的流程圖列出了用戶在第一次登陸應用時所須要經歷的步驟。首先，用戶經過在瀏覽器的地址欄中鍵入https://app.ambergarden.com來嘗試訪問應用。因爲此時應用會話並無被建立，所以應用將拒絕用戶的登陸請求，並經過302響應將用戶重定向到https://sso.ambergarden.com以要求用戶首先經過SSO進行登陸。注意在該重定向所標明的地址中包含了一個額外的URL參數service。其標示了用戶本來想要訪問的應用所在的位置。在瀏覽器接收到了302響應後，其將自動跳轉到SSO。因爲SSO中也沒有與瀏覽器創建相應的會話，所以其將返回給用戶一個登陸界面，要求用戶經過輸入用戶名和密碼完成登陸。在用戶輸入了用戶名/密碼並點擊登陸按鈕後，頁面邏輯將發送一個POST請求到SSO中以創建會話。若是用戶登陸成功，那麼SSO將返回一個302重定向響應，而且該重定向響應中由Location所標明的地址還帶了一個額外的參數ticket。在瀏覽器接收到該重定向響應以後，其將向重定向地址發送一個GET請求，而且該請求中還包含了剛剛從SSO所返回的ticket參數。在應用接受到該請求後，其將使用ticket參數所標明的憑據向SSO發送請求以驗證該憑據的合法性。若是驗證成功，那麼應用將會認爲當前對應用的訪問是一個已經獲得SSO認證的合法用戶發起的，進而爲該用戶建立會話。

　　在瀏覽器再次訪問該應用的時候，因爲應用已經爲當前瀏覽器建立了相應的會話，所以應用將能識別出它是一個合法的通過SSO驗證的用戶：

　　相較於對應用的第一次訪問而言，第二次訪問的流程圖實際上就很是容易理解了。實際上，這就是在已經創建了會話以後再次訪問應用時的流程圖。

　　而在訪問其它應用時，CAS協議運行的流程圖將以下所示：

　　若是您已經理解了首次登陸流程，那麼該流程就很是容易理解了。首先，用戶嘗試訪問處於https://app2.ambergarden.com下的應用。因爲以前用戶並無登陸過該應用，所以該應用發送一個302請求來將用戶重定向到SSO服務。而這裏的URL參數service與首次登陸時候的意義同樣，用來在這一系列通訊中記錄登陸成功後所須要返回到的服務地址。

　　瀏覽器一旦接收到了302響應，那麼其將馬上執行重定向並訪問SSO服務。因爲用戶在以前訪問第一個應用的時候已經創建了SSO會話，所以SSO服務將當即返回一個302響應，並在響應的Location中使用URL參數ticket標示用戶從SSO所獲得的憑據。在接到302響應後，瀏覽器再次重定向，並訪問應用。應用一樣使用ticket所標示的憑據向SSO請求驗證。在驗證成功後，應用將會認爲當前訪問用戶是合法的，所以將爲該用戶建立會話。在該過程當中，用戶沒有輸入任何信息，而只通過了幾回瀏覽器跳轉就驗證了用戶的合法性。

 

CAS協議集成

　　好了，在瞭解了基於CAS協議的SSO是如何工做的以後，咱們就能夠開始考慮如何在應用中集成對CAS協議的支持了。

　　咱們所要作的第一步就是分析上面所講的各個流程中的每一步對CAS協議所定義的各接口，進行使用的方式。在分析的過程當中，咱們須要時刻提醒本身是在爲咱們的應用添加CAS協議支持，而不是實現一個基於CAS協議的SSO。這會致使咱們在查看CAS協議時的角度與實現一個基於CAS協議的SSO有如下幾點不一樣：

1. 沒必要要理解CAS協議中的全部接口以及各接口中的全部參數。CAS協議中列出的不少接口實際上都是用來在瀏覽器和SSO服務之間進行交互的。所以咱們沒必要要很是仔細地察看這些接口，而只須要知道這些接口所執行的功能以及產生的數據便可。並且即便是咱們會用到的接口中也會有一部分參數並不會被用到。咱們只須要關注在咱們的應用使用SSO流程中所可能涉及到的各個參數便可。
2. 須要注意在流程中瀏覽器與應用之間的交互。在前面所展現的各個流程圖中已經可以看到，應用是經過一系列302重定向響應等HTTP標準方法來完成將用戶重定向到SSO服務這一動做的。

　　那麼咱們回過頭來回憶一下用戶首次登錄成功的流程圖：

　　在該流程圖裏面，咱們須要關心的就是到底誰與應用產生了交互，以及在交互過程當中使用了什麼樣的接口及參數。能夠看到，在用戶經過瀏覽器第一次訪問應用的時候，應用須要返回給用戶一個302響應，而響應中所指定的地址就是SSO所提供的登錄接口。所以咱們要作得第一步就是要理解Login這個URL所作的工做。

　　從API文檔中能夠看到，Login這個URL能夠提供兩種服務：請求用戶輸入身份憑證（Credential Requester）以及驗證用戶的身份憑證（Credential Acceptor）。在這張流程圖裏面，咱們兩次向該URL發送請求。第一次請求所使用的是該URL的第一種服務，該服務將請求用戶輸入用戶的身份憑證，如顯示一個登錄頁面。而在用戶輸入了用戶名和密碼後，向該URL發送的請求就將使用第二種服務。在這兩次請求中，URL中的service參數用來標明用戶成功登錄後從SSO重定向出來時所須要跳轉到的地址。因爲咱們是在爲本身的應用添加SSO支持，那麼該服務天然須要指向咱們的應用。

　　OK，如今咱們就能夠開始第一步集成了。該步驟的工做就是：當一個用戶訪問應用的時候，若是應用中沒有該用戶所對應的會話，那麼返回302響應，並在響應中標示跳轉的地址爲SSO所在的地址，並在service參數中標明咱們的應用所在的地址。若是這一切功能都正確地實現，那麼對應用的訪問會自動跳轉到SSO服務，並在成功登錄後再次請求訪問咱們本身的應用。此時的訪問會傳入一個URL參數ticket以表示從SSO處獲得的憑證。

　　若是正確地完成了第一步的集成，那麼咱們就能夠開始集成的第二個步驟了，那就是向SSO服務驗證用戶。在第一步中，SSO最終驗證了用戶的身份並向瀏覽器中返回了一個302響應。瀏覽器接收到該302響應後，其便向302響應所標示的地址進行跳轉。在應用接受到了包含ticket參數的請求後，它須要使用該ticket參數所記錄的信息來訪問serviceValidate接口，以驗證所傳入的ticket參數是不是一個真正的從SSO所返回的憑據。一旦驗證成功，那麼該用戶就是一個合法用戶。此時應用就須要爲該用戶建立一個會話並將他重定向到程序的初始頁面，如應用的Dashboard等。

　　而在用戶再次訪問應用的時候，因爲應用中已經包含了該用戶所對應的會話，所以其不會再與SSO產生交互，所以也再也不須要爲SSO集成作任何工做。一樣的，因爲第三個流程也使用了一樣的接口，所以咱們也再也不須要作任何額外的工做。

　　就這樣，僅僅經過這兩步，咱們就能夠完成對SSO登錄功能的集成了。是否是很簡單？

　　除此以外，咱們還能夠選擇支持Single Logout（有些討論裏面叫Single Sign Off）。可是反對該功能的人也很多。其中的緣由就由於用戶經常認爲點擊Logout按鈕是從當前應用中安全地退出，可是這實際上致使用戶所登錄的全部使用該SSO服務的應用都將退出。所以在決定對該功能進行支持以前必定要考慮清楚該功能是否會真的爲用戶帶來好處。

 

須要注意的問題

　　就像你們在上面所看到的同樣，在應用中集成對SSO的支持實際上並不須要多少工做。甚至能夠說，一個有相關經驗的人能夠在幾個小時內就能完成。可是反過來講，若是在集成中沒有注意到一些問題，那麼這些問題可能會耽誤您幾天的時間。所以在本節中，我會簡單地說一下我在SSO集成中的一些經驗。

　　首先就是CAS協議的API文檔的閱讀方法。我一直認爲，對於這種側重於流程的協議，協議的運行流程以及在該流程中的數據流是關鍵。所以一上來就衝到API文檔中並嘗試理解每一個接口的含義，輸入及輸出並非一個好的辦法。可能對於外國人而言，先了解接口再弄懂運行流程是一種比較簡單的方式，可是彷佛這種方式並不太適合中國人的思惟。這也就是我爲何一上來就講解SSO的運行流程的緣由。

　　而在CAS協議的API文檔中，對ticket進行驗證的接口有好幾套，如初版中的/validate接口在第二版中演進爲/servicevalidate和/proxyvalidate兩個接口等。請根據須要選擇相應的一套接口便可。

　　一個須要注意的地方就是，不少SSO裏面都有一個Filter，用來標示容許使用該SSO服務的各個應用。該Filter會阻止非法應用從SSO服務登錄。不然該非法應用將能夠嘗試對SSO展開攻擊。舉一個最簡單的DDOS攻擊的例子。在個人一篇博客裏已經介紹過對用戶名/密碼對的驗證明際上是一個較爲耗時的行爲，所以該步是SSO服務中最爲脆弱的地方。若是一個惡意人員盯上了該SSO服務，並在一個用戶羣基數較大的網站上找到了漏洞，更改了它的SSO服務配置，那麼該網站的用戶就會在登錄該網站的時候跳轉到該SSO服務。接下來這些用戶就會嘗試用他們的用戶名/密碼對在該SSO服務上登錄，從而在這些用戶的幫助下展開了DDOS攻擊。所以在一般狀況下，SSO服務都會配置一個白名單。而在進行SSO集成以前，咱們則首先須要向該白名單中添加咱們的應用。

　　還有一個比較容易被忽略的問題就是會話的時效性問題。在整個SSO的使用中存在着兩種會話：用戶在應用程序中的會話以及用戶在SSO服務上的會話。在通常狀況下，SSO服務上的會話持續時間都會比應用程序中的會話時間略長。這樣在應用程序的會話過時時，用戶能夠直接經過刷新頁面等方式從SSO服務從新創建會話。可是在進行集成時，爲了調試方便，咱們經常會將應用會話時間調整得很長，甚至長於SSO服務上的會話時間，從而沒有測試應用程序會話過時進而經過SSO會話來刷新應用程序會話的狀況。

 

Reference

CAS協議：http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html

 

轉載請註明原文地址並標明轉載：http://www.cnblogs.com/loveis715/p/4491417.html

商業轉載請事先與我聯繫：silverfox715@sina.com