SSO單點登錄詳解-------二、單點登錄流程解析

一、簡介

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

二、應用場景

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

三、流程分析

相比於單系統登錄，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.全局會話銷燬，局部會話必須銷燬

四、系統中的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系統中都存在局部的會話,我們訪問這兩個系統中的任何受保護資源都會直接放行.

五、總結

只要把上面的流程和cookie和session存儲圖解弄清楚了.代碼實現就變得So Easy.而且開源的單點登錄框架內部的實現和分析的流程基本上一致.

原文鏈接：https://www.jianshu.com/p/5cc9457942b5