一、單系統登錄機制
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在會話對象中設置登錄狀態如下
1 2 | HttpSession session = request.getSession();session.setAttribute("isLogin", true); |
用戶再次訪問時，tomcat在會話對象中查看登錄狀態
1 2 | 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本身不安全。
因此，我們需要一種全新的登錄方式來實現多系統應用羣的登錄，這就是單點登錄
作者：凌承一
出處：http://www.cnblogs.com/ywlaker/
聲明：本文版權歸作者和博客園共有，歡迎轉載，但轉載必須保留此段聲明，並在文章頁面明顯位置給出原文鏈接，否則作者將保留追究法律責任的權利