單點登入原理

一、單系統登入機制

1、http無狀態協議

web應用採用browser/server架構，http作為通訊協議。http是無狀態協議，瀏覽器的每一次請求，伺服器會獨立處理，不與之前或之後的請求產生關聯，這個過程用下圖說明，三次請求/響應對之間沒有任何聯絡

但這也同時意味著，任何使用者都能通過瀏覽器訪問伺服器資源，如果想保護伺服器的某些資源，必須限制瀏覽器請求；要限制瀏覽器請求，必須鑑別瀏覽器請求，響應合法請求，忽略非法請求；要鑑別瀏覽器請求，必須清楚瀏覽器請求狀態。既然http協議無狀態，那就讓伺服器和瀏覽器共同維護一個狀態吧！這就是會話機制

2、會話機制

瀏覽器第一次請求伺服器，伺服器建立一個會話，並將會話的id作為響應的一部分傳送給瀏覽器，瀏覽器儲存會話id，並在後續第二次和第三次請求中帶上會話id，伺服器取得請求中的會話id就知道是不是同一個使用者了，這個過程用下圖說明，後續請求與第一次請求產生了關聯

伺服器在記憶體中儲存會話物件，瀏覽器怎麼儲存會話id呢？你可能會想到兩種方式

1.請求引數

2.cookie

將會話id作為每一個請求的引數，伺服器接收請求自然能解析引數獲得會話id，並藉此判斷是否來自同一會話，很明顯，這種方式不靠譜。那就瀏覽器自己來維護這個會話id吧，每次傳送http請求時瀏覽器自動傳送會話id，cookie機制正好用來做這件事。cookie是瀏覽器用來儲存少量資料的一種機制，資料以”key/value“形式儲存，瀏覽器傳送http請求時自動附帶cookie資訊

tomcat會話機制當然也實現了cookie，訪問tomcat伺服器時，瀏覽器中可以看到一個名為“JSESSIONID”的cookie，這就是tomcat會話機制維護的會話id，使用了cookie的請求響應過程如下圖

3、登入狀態

有了會話機制，登入狀態就好明白了，我們假設瀏覽器第一次請求伺服器需要輸入使用者名稱與密碼驗證身份，伺服器拿到使用者名稱密碼去資料庫比對，正確的話說明當前持有這個會話的使用者是合法使用者，應該將這個會話標記為“已授權”或者“已登入”等等之類的狀態，既然是會話的狀態，自然要儲存在會話物件中，tomcat在會話物件中設定登入狀態如下

	1	 HttpSession session = request.getSession();
	2    session.setAttribute("isLogin", true);

使用者再次訪問時，tomcat在會話物件中檢視登入狀態

	1	 HttpSession session = request.getSession();
	2 	 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的受保護資源，系統1發現使用者未登入，跳轉至sso認證中心，並將自己的地址作為引數

2.sso認證中心發現使用者未登入，將使用者引導至登入頁面

3.使用者輸入使用者名稱密碼提交登入申請

4.sso認證中心校驗使用者資訊，建立使用者與sso認證中心之間的會話，稱為全域性會話，同時建立授權令牌

5.sso認證中心帶著令牌跳轉會最初的請求地址（系統1）

6.系統1拿到令牌，去sso認證中心校驗令牌是否有效

7.sso認證中心校驗令牌，返回有效，註冊系統1

8.系統1使用該令牌建立與使用者的會話，稱為區域性會話，返回受保護資源

9.使用者訪問系統2的受保護資源

10.系統2發現使用者未登入，跳轉至sso認證中心，並將自己的地址作為引數

11.sso認證中心發現使用者已登入，跳轉回系統2的地址，並附上令牌

12.系統2拿到令牌，去sso認證中心校驗令牌是否有效

13.sso認證中心校驗令牌，返回有效，註冊系統2

14.系統2使用該令牌建立與使用者的區域性會話，返回受保護資源

使用者登入成功之後，會與sso認證中心及各個子系統建立會話，使用者與sso認證中心建立的會話稱為全域性會話，使用者與各個子系統建立的會話稱為區域性會話，區域性會話建立之後，使用者訪問子系統受保護資源將不再通過sso認證中心，全域性會話與區域性會話有如下約束關係

1.區域性會話存在，全域性會話一定存在

2.全域性會話存在，區域性會話不一定存在

3.全域性會話銷燬，區域性會話必須銷燬

你可以通過部落格園、百度、csdn、淘寶等網站的登入過程加深對單點登入的理解，注意觀察登入過程中的跳轉url與引數

2、登出

單點登入自然也要單點登出，在一個子系統中登出，所有子系統的會話都將被銷燬，用下面的圖來說明

sso認證中心一直監聽全域性會話的狀態，一旦全域性會話銷燬，監聽器將通知所有註冊系統執行登出操作

下面對上圖簡要說明

1.使用者向系統1發起登出請求

2.系統1根據使用者與系統1建立的會話id拿到令牌，向sso認證中心發起登出請求

3.sso認證中心校驗令牌有效，銷燬全域性會話，同時取出所有用此令牌註冊的系統地址

4.sso認證中心向所有註冊系統發起登出請求

5.各註冊系統接收sso認證中心的登出請求，銷燬區域性會話

6.sso認證中心引導使用者至登入頁面

四、部署圖

單點登入涉及sso認證中心與眾子系統，子系統與sso認證中心需要通訊以交換令牌、校驗令牌及發起登出請求，因而子系統必須整合sso的客戶端，sso認證中心則是sso服務端，整個單點登入過程實質是sso客戶端與服務端通訊的過程，用下圖描述

sso認證中心與sso客戶端通訊方式有多種，這裡以簡單好用的httpClient為例，web service、rpc、restful api都可以。