本文原地址:http://blog.csdn.net/u011277123/article/details/53404269
一、單系統登錄機制
1、http無狀態協議
web應用採用browser/server架構,http作爲通信協議。http是無狀態協議,瀏覽器的每一次請求,服務器會獨立處理,不與之前或之後的請求產生關聯,這個過程用下圖說明,三次請求/響應對之間沒有任何聯繫
但這也同時意味着,任何用戶都能通過瀏覽器訪問服務器資源,如果想保護服務器的某些資源,必須限制瀏覽器請求;要限制瀏覽器請求,必須鑑別瀏覽器請求,響應合法請求,忽略非法請求;要鑑別瀏覽器請求,必須清楚瀏覽器請求狀態。既然http協議無狀態,那就讓服務器和瀏覽器共同維護一個狀態吧!這就是會話機制
2、會話機制
瀏覽器第一次請求服務器,服務器創建一個會話,並將會話的id作爲響應的一部分發送給瀏覽器,瀏覽器存儲會話id,並在後續第二次和第三次請求中帶上會話id,服務器取得請求中的會話id就知道是不是同一個用戶了,這個過程用下圖說明,後續請求與第一次請求產生了關聯
服務器在內存中保存會話對象,瀏覽器怎麼保存會話id呢?你可能會想到兩種方式
請求參數 cookie
將會話id作爲每一個請求的參數,服務器接收請求自然能解析參數獲得會話id,並藉此判斷是否來自同一會話,很明顯,這種方式不靠譜。那就瀏覽器自己來維護這個會話id吧,每次發送http請求時瀏覽器自動發送會話id,cookie機制正好用來做這件事。cookie是瀏覽器用來存儲少量數據的一種機制,數據以”key/value“形式存儲,瀏覽器發送http請求時自動附帶cookie信息
tomcat會話機制當然也實現了cookie,訪問tomcat服務器時,瀏覽器中可以看到一個名爲“JSESSIONID”的cookie,這就是tomcat會話機制維護的會話id,使用了cookie的請求響應過程如下圖
3、登錄狀態
有了會話機制,登錄狀態就好明白了,我們假設瀏覽器第一次請求服務器需要輸入用戶名與密碼驗證身份,服務器拿到用戶名密碼去數據庫比對,正確的話說明當前持有這個會話的用戶是合法用戶,應該將這個會話標記爲“已授權”或者“已登錄”等等之類的狀態,既然是會話的狀態,自然要保存在會話對象中,tomcat在會話對象中設置登錄狀態如下
HttpSession session = request.getSession; session.setAttribute("isLogin", true);
用戶再次訪問時,tomcat在會話對象中查看登錄狀態
HttpSession session = request.getSession; session.getAttribute("isLogin");
實現了登錄狀態的瀏覽器請求服務器模型如下圖描述
每次請求受保護資源時都會檢查會話對象中的登錄狀態,只有 isLogin=true 的會話才能訪問,登錄機制因此而實現。
二、多系統的複雜性
web系統早已從久遠的單系統發展成爲如今由多系統組成的應用羣,面對如此衆多的系統,用戶難道要一個一個登錄、然後一個一個註銷嗎?就像下圖描述的這樣
web系統由單系統發展成多系統組成的應用羣,複雜性應該由系統內部承擔,而不是用戶。無論web系統內部多麼複雜,對用戶而言,都是一個統一的整體,也就是說,用戶訪問web系統的整個應用羣與訪問單個系統一樣,登錄/註銷只要一次就夠了
雖然單系統的登錄解決方案很完美,但對於多系統應用羣已經不再適用了,爲什麼呢?
單系統登錄解決方案的核心是cookie,cookie攜帶會話id在瀏覽器與服務器之間維護會話狀態。但cookie是有限制的,這個限制就是cookie的域(通常對應網站的域名),瀏覽器發送http請求時會自動攜帶與該域匹配的cookie,而不是所有cookie
既然這樣,爲什麼不將web應用羣中所有子系統的域名統一在一個頂級域名下,例如“*.baidu.com”,然後將它們的cookie域設置爲“baidu.com”,這種做法理論上是可以的,甚至早期很多多系統登錄就採用這種同域名共享cookie的方式。
然而,可行並不代表好,共享cookie的方式存在衆多侷限。首先,應用羣域名得統一;其次,應用羣各系統使用的技術(至少是web服務器)要相同,不然cookie的key值(tomcat爲JSESSIONID)不同,無法維持會話,共享cookie的方式是無法實現跨語言技術平臺登錄的,比如java、php、.net系統之間;第三,cookie本身不安全。
因此,我們需要一種全新的登錄方式來實現多系統應用羣的登錄,這就是單點登錄
三、單點登錄
什麼是單點登錄?單點登錄全稱Single Sign On(以下簡稱SSO),是指在多系統應用羣中登錄一個系統,便可在其他所有系統中得到授權而無需再次登錄
1、登錄
相比於單系統登錄,sso需要一個獨立的認證中心,只有認證中心能接受用戶的用戶名密碼等安全信息,其他系統不提供登錄入口,只接受認證中心的間接授權。間接授權通過令牌實現,sso認證中心驗證用戶的用戶名密碼沒問題,創建授權令牌,在接下來的跳轉過程中,授權令牌作爲參數發送給各個子系統,子系統拿到令牌,即得到了授權,可以藉此創建局部會話,局部會話登錄方式與單系統的登錄方式相同。這個過程,也就是單點登錄的原理,用下圖說明
下面對上圖簡要描述
用戶訪問系統1的受保護資源,系統1發現用戶未登錄,跳轉至sso認證中心,並將自己的地址作爲參數 sso認證中心發現用戶未登錄,將用戶引導至登錄頁面 用戶輸入用戶名密碼提交登錄申請 sso認證中心校驗用戶信息,創建用戶與sso認證中心之間的會話,稱爲全局會話,同時創建授權令牌 sso認證中心帶着令牌跳轉會最初的請求地址(系統1) 系統1拿到令牌,去sso認證中心校驗令牌是否有效 sso認證中心校驗令牌,返回有效,註冊系統1 系統1使用該令牌創建與用戶的會話,稱爲局部會話,返回受保護資源 用戶訪問系統2的受保護資源 系統2發現用戶未登錄,跳轉至sso認證中心,並將自己的地址作爲參數 sso認證中心發現用戶已登錄,跳轉回系統2的地址,並附上令牌 系統2拿到令牌,去sso認證中心校驗令牌是否有效 sso認證中心校驗令牌,返回有效,註冊系統2 系統2使用該令牌創建與用戶的局部會話,返回受保護資源
用戶登錄成功之後,會與sso認證中心及各個子系統建立會話,用戶與sso認證中心建立的會話稱爲全局會話,用戶與各個子系統建立的會話稱爲局部會話,局部會話建立之後,用戶訪問子系統受保護資源將不再通過sso認證中心,全局會話與局部會話有如下約束關係
局部會話存在,全局會話一定存在 全局會話存在,局部會話不一定存在 全局會話銷燬,局部會話必須銷燬
2、註銷
單點登錄自然也要單點註銷,在一個子系統中註銷,所有子系統的會話都將被銷燬,用下面的圖來說明
sso認證中心一直監聽全局會話的狀態,一旦全局會話銷燬,監聽器將通知所有註冊系統執行註銷操作
下面對上圖簡要說明
用戶向系統1發起註銷請求 系統1根據用戶與系統1建立的會話id拿到令牌,向sso認證中心發起註銷請求 sso認證中心校驗令牌有效,銷燬全局會話,同時取出所有用此令牌註冊的系統地址 sso認證中心向所有註冊系統發起註銷請求 各註冊系統接收sso認證中心的註銷請求,銷燬局部會話 sso認證中心引導用戶至登錄頁面