最強SSO單點登陸教程(二)單點登陸流程分析

1、簡介

單點登陸（Single Sign On），簡稱爲 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。

2、應用場景

如公司有多個系統，分別OA系統、CRM系統、財務管理系統、設備管理系統等，總不能訪問每一個系統都要登陸一遍吧，用戶會瘋掉的，應該咱們認證一遍，其餘系統便可訪問。網上不少項目都在使用SSO單點登陸,好比天貓,淘寶,CSDN,博客園.

3、流程分析

相比於單系統登陸，sso須要一個獨立的認證中心，只有認證中心能接受用戶的用戶名密碼等安全信息，其餘系統不提供登陸入口，只接受認證中心的間接受權。間接受權經過令牌實現，sso認證中心驗證用戶的用戶名密碼沒問題，建立受權令牌，在接下來的跳轉過程當中，受權令牌做爲參數發送給各個子系統，子系統拿到令牌，即獲得了受權，能夠藉此建立局部會話，局部會話登陸方式與單系統的登陸方式相同。這個過程，也就是單點登陸的原理，用下圖說明:

單點登陸原理

步驟分析:
1.用戶經過瀏覽器訪問WMS(進銷存)系統的受保護資源,訪問地址爲:http://www.wms.com/index,該資源爲受保護資源,因此須要先判斷一下用戶登錄了.(是否有局部會話)
2.WMS系統發現用戶並無登錄,此時重定向到統一認證中心,並把請求地址做爲參數傳過去.
3.此時瀏覽器發出一個請求查看統一認證中心是否已經登陸了?發現用戶並無登陸,轉發到統一認證中心的登錄頁面.
4.用戶輸入帳號密碼.
5.統一認證中心認證用戶信息.若是認證成功,建立瀏覽器與統一認證中心之間的會話，稱爲全局會話.同時建立受權令牌.重定向到WMS以前請求的地址,並把令牌信息帶上.http://www.wms.com/index?token=4KLdkEo9k7CXfle4
6.WMS拿到令牌後,須要到統一認證中心檢驗令牌是否有效.
7.統一認證中心認證令牌有效,返回有效,並註冊WMS的系統地址.
8.WMS獲得統一認證中心的響應,知道令牌是有效的,建立局部的會話.並放行請求
9.WMS後續的請求訪問的時候,發現WMS系統中有局部的會話,直接就放行了.
10.用戶訪問CRM(客戶關係管理)系統的受保護資源,訪問地址爲:http://www.crm.com/index
11.WMS系統發現用戶並無登錄(沒有局部會話),此時重定向到統一認證中心,並把請求地址做爲參數傳過去.
12.此時瀏覽器發出一個請求查看統一認證中心是否已經登陸了?發現用戶已經登陸了,從會話中取出令牌,重定向到CRM系統,並把令牌帶上.http://www.crm.com/index?token=SrEpDwAQlHLdkJIE
13.CRM拿到令牌後,須要到統一認證中心檢驗令牌是否有效.
14.統一認證中心認證令牌有效,返回有效,並註冊CRM的系統地址.
15.CRM獲得統一認證中心的響應,知道令牌是有效的,建立局部的會話.並放行請求
16.WMS後續的請求訪問的時候,發現WMS系統中有局部的會話,直接就放行了.

用戶登陸成功以後，瀏覽器會與統一認證中心及各個子系統創建會話，瀏覽器與統一認證中心創建的會話稱爲全局會話，瀏覽器與各個子系統創建的會話稱爲局部會話，局部會話創建以後，瀏覽器訪問子系統受保護資源將再也不經過統一認證中心，全局會話與局部會話有以下約束關係.

1.局部會話存在，全局會話必定存在
2.全局會話存在，局部會話不必定存在
3.全局會話銷燬，局部會話必須銷燬

同窗們花20分鐘時間把這張流程圖好好理解理解.

4、系統中的Cookie和Session存儲圖解

這個執行流程裏面很關鍵的點是統一認證中心和各個子系統的cookie和session是如何存儲的?若是把裏面的cookie和session搞清楚了,單點登陸原理基本已經理解90%了.
下面咱們就經過圖解的方式來看看,上面的訪問流程中每一個系統中的cookie和session是怎麼存儲的.

注意:如下圖解是方便同窗們理解所畫的,可能有細節和真實狀況有細微出入.可是不影響理解,但願不要鑽牛角尖,能看懂便可.

圖01:下圖中,咱們有三個服務器,分別是統一認證中心:www.sso.com,CRM客戶關係管理系統:www.crm.com,WMS經銷存系統:www.wms.com.每一個系統都有一個區域存儲session的地方,同窗們能夠暫時理解就是有個map來存儲session對象.這個map的key存的是session的id,value存的是session對象.
在瀏覽器本地會有三個目錄存儲對應域名的cookie.好比:訪問www.crm.com的時候會在瀏覽器本地的crm.com目錄找對應的cookie,並在請求的時候把這個目錄下的cookie請求一併的帶到服務器.(這個動做是瀏覽器完成的,不須要用戶操做.),並且www.crm.com服務器響應cookie的時候會寫入到瀏覽器本地的crm.com目錄.
目前咱們還沒發起請求,因此全部的內容都是空的.

單點登陸01

圖02:第一次訪問http://www.crm.com/employee,首先會在瀏覽器本地的crm.com目錄中尋找是否有對應的cookie,若是能夠沒有說明目前瀏覽器和服務器之間尚未創建會話,也就是說沒有局部的會話.
這時候咱們須要重定向到統一認證中心,查看是否有全局會話(若是有全局會話說明有其餘系統已經登陸了).
須要把請求訪問的地址做爲參數傳遞過去,由於待會得回調這個地址.
具體代碼以下:

String url = "http://www.sso.com/checkLogin?redirectUrl=http://www.crm.com/employee";
response.sendRedirect(url);

單點登陸02

圖03:由於重定向,瀏覽器會調用統一認證www.sso.com中的checkLogin方法,查看是否有全局的會話.
這時候是請求http://www.sso.com/checkLogin地址,瀏覽器會在本地的sso.com目錄找對應的cookie信息並在請求的時候一併得帶到服務器.
可是此次的請求,瀏覽器本地目錄sso.com中並無cookie信息,意味瀏覽器和統一認證中心之間尚未創建會話.
沒有會話說明並無登陸.此時要轉發到統一認證中心的登錄頁面.
須要把地址欄中的redirectUrl從地址欄中獲取出來.

request.getParamter("redirectUrl");

並把這個參數放入到request域中.由於在登錄成功以後要跳轉到用戶以前訪問的地址.

單點登陸03

圖04:轉發到統一認證中的登錄頁面.

單點登陸04

圖05:用戶在統一認證中心的登錄頁面輸入了帳戶名和密碼以後.統一認證中心服務器對用戶信息進行認證.認證經過須要作這幾個事情:
1.建立令牌,後續操做中得發給子系統,至關於間接受權.
2.建立全局會話,並把令牌存儲到全局會話中.
3.把令牌信息存儲到數據庫中的t_token表中.主要是後續客戶端校驗token的有效性須要查詢這種表.
4.重定向到以前用戶請求的地址redirectUrl.並把令牌發給該子系統.http://www.crm.com/employee?token=VcnVMguCDWJX5zHa

統一認證中心會把session的id(咱們也稱爲JSESSIONID)響應到客戶端瀏覽器本地目錄sso.com的cookie文件中.存儲的結構是key/value格式.key是固定的字符串JSESSIONID,value是服務器sessionid的字符串.
在後續訪問www.sso.com的時候都會帶上這個JSESSIONID

單點登陸05

圖06:由於重定向,瀏覽器訪問http://www.crm.com/employee?token=VcnVMguCDWJX5zHa,此時瀏覽器會在本地的crm.com把全部的cookie一併的帶上.
可是本地的crm.com目錄中沒有內容,說明瀏覽器尚未和CRM系統創建會話,說明沒有局部會話.
可是此次的請求中包含了token令牌的信息.
可是token是直接拼接在地址欄上的,存在被僞造的可能性.因此咱們須要對token令牌作有效性的校驗.

單點登陸06

圖07:CRM系統在接受到令牌token信息以後,須要去統一認證中心中校驗令牌信息是否有效.
咱們使用HttpUrlConnection發送http請求http://www.sso.com/verify?token=VcnVMguCDWJX5zHa
統一認證中心接受到這個請求後,拿到令牌token對應的值,在數據庫表t_token中查詢是否有這條記錄.若是能找到說明這個令牌是統一認證中心發放的,返回true給調用者.
若是找不到,說明不是統一認證中心產生的,咱們就該返回false給調用者.

單點登陸07

圖08:CRM系統發送的校驗請求以後,統一認證中心返回true的結果.說明令牌是有效的.此時須要作這幾件事情:
1.建立局部的會話,而且標記這個會話已登陸,設置isLogin=true
2.放行該次的請求.
服務器會把session的id響應到客戶端,存儲在瀏覽器本地目錄crm.com目錄的cookie文件中.在後續訪問www.crm.com的域名的時候會把該目錄下的cookie信息一併帶上.

到這一步其實咱們單個系統的登錄就已經完成了.

單點登陸08

圖09:後續的請求.好比請求http://www.crm.com/department,首先根據請求的域名在本地crm.com目錄中找到對應的cookie信息,在請求的時候會把這個JSESSIONID一併的帶上,經過這個JSESSIONID能夠找到服務中屬於該瀏覽器的會話對象,並查看isLogin屬性,若是爲true,就直接放行該次的請求.

單點登陸09

圖10:此時咱們訪問http://www.wms.com/orderBill地址,瀏覽器根據域名會在本地的wms.com目錄中把cookie信息在請求的時候一併帶上,可是並無cookie信息,說明瀏覽器尚未和WMS系統創建會話.
WMS沒有局部會話,咱們就要重定向到統一認證中心的checkLogin方法,查看是否有全局的會話(是否有其餘的系統登錄了).

單點登陸10

圖11:由於重定向的關係,瀏覽器發送請求:
http://www.sso.com/checkLogin?redirectUrl=http://www.wms.com/orderBill,
校驗是否有全局的會話,由於以前CRM已經登陸了,因此有全局會話.
須要作如事情:
1.從全局會話中取出令牌信息token
2.重定向到子系統以前訪問的地址,並把令牌信息帶上.
http://www.wms.com/orderBill?token=VcnVMguCDWJX5zHa

單點登陸11

圖12:由於重定向,瀏覽器發送請求:
http://www.wms.com/orderBill?token=VcnVMguCDWJX5zHa,
瀏覽器會根據域名找本地目錄中wms.com目錄中的cookie,並在請求的時候一併的帶上.
可是並無cookie信息,說明沒有局部會話,可是有令牌信息token.
須要到統一認證中心校驗令牌信息token的有效性.

單點登陸12

圖13:WMS系統後臺經過HttpUrlConnection的方式發送請求,校驗token是否有效.
統一認證中心接受到請求以後,拿到token在數據庫表中查看是否有這條記錄.並響應對應的結果信息到WMS系統中.

單點登陸13

圖14:若是認證中心的返回的校驗結果爲true,說明令牌有效.那就在WMS中建立局部的會話,並在會話中設置登錄屬性isLogin=true.
放行請求
瀏覽器會默認的被sessionid的信息經過cookie的方式響應到瀏覽器.
瀏覽器把sessionid信息存儲到wms.com目錄的cookie文件中.

單點登陸14

圖15:後去訪問WMS其餘的受保護資源.好比:http://www.wms.com/customer,瀏覽器會在本地wms.com目錄中找cookie,並在請求的時候一併的把cookie信息帶到服務器.
經過JSESSIONID找到數據該瀏覽器的會話對象,檢查isLogin屬性是否爲true.
放行請求.

單點登陸15

當這步結束以後,在CRM系統和WMS系統中都存在局部的會話,咱們訪問這兩個系統中的任何受保護資源都會直接放行.

5、總結

同窗們須要花點時間好好把上面的流程和cookie和session存儲圖解弄清楚了.代碼實現就變得So Easy.並且開源的單點登陸框架內部的實現和分析的流程基本上一致.

做者：叩丁狼教育
連接：https://www.jianshu.com/p/5cc... 來源：簡書 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。