單點登入原理

一、單系統登入機制

1、http無狀態協議
　　web應用採用browser/server架構，http作為通訊協議。http是無狀態協議，瀏覽器的每一次請求，伺服器會獨立處理，不與之前或之後的請求產生關聯，這個過程用下圖說明，三次請求/響應對之間沒有任何聯絡（解釋： 主要就是因為http是無狀態的協議）
　　
　　但這也同時意味著，任何使用者都能通過瀏覽器訪問伺服器資源，如果想保護伺服器的某些資源，必須限制瀏覽器請求；要限制瀏覽器請求，必須鑑別瀏覽器請求，響應合法請求，忽略非法請求；要鑑別瀏覽器請求，必須清楚瀏覽器請求狀態。既然http協議無狀態，那就讓伺服器和瀏覽器共同維護一個狀態吧！這就是會話機制
　　
2、會話機制
　　瀏覽器第一次請求伺服器，伺服器建立一個會話，並將會話的id作為響應的一部分傳送給瀏覽器，瀏覽器儲存會話id，並在後續第二次和第三次請求中帶上會話id，伺服器取得請求中的會話id就知道是不是同一個使用者了，這個過程用下圖說明，後續請求與第一次請求產生了關聯
　　(解釋： 登入的使用者在session裡面是可以查詢到的已經儲存的isLogin屬性設定為true)
　　
　　伺服器在記憶體中儲存會話物件，瀏覽器怎麼儲存會話id呢？你可能會想到兩種方式：
①請求引數
②通過cookie實現
　　將會話id作為每一個請求的引數，伺服器接收請求自然能解析引數獲得會話id，並藉此判斷是否來自同一會話，很明顯，這種方式不靠譜。
　　那就瀏覽器自己來維護這個會話id吧，每次傳送http請求時瀏覽器自動傳送會話id，cookie機制正好用來做這件事。cookie是瀏覽器用來儲存少量資料的一種機制，資料以”key/value“形式儲存，瀏覽器傳送http請求時自動附帶cookie資訊

tomcat會話機制當然也實現了cookie（解釋： 就是當客戶端訪問tomcat的時候，tomcat也可以給客戶端傳送一個cookie），訪問tomcat伺服器時，瀏覽器中可以看到一個名為“JSESSIONID”的cookie，這就是tomcat會話機制維護的會話id，使用了cookie的請求響應過程如下圖
　　
　　3、登入狀態
　　有了會話機制，登入狀態就好明白了，我們假設瀏覽器第一次請求伺服器需要輸入使用者名稱與密碼驗證身份，伺服器拿到使用者名稱密碼去資料庫比對，正確的話說明當前持有這個會話的使用者是合法使用者，應該將這個會話標記為“已授權”或者“已登入”等等之類的狀態，既然是會話的狀態，自然要儲存在會話物件中，tomcat在會話物件中設定登入狀態如下
　　
　　實現了登入狀態的瀏覽器請求伺服器模型如下圖描述
　　
　　　每次請求受保護資源時都會檢查會話物件中的登入狀態，只有 isLogin=true 的會話才能訪問，登入機制因此而實現。

二、多系統的複雜性

web系統早已從久遠的單系統發展成為如今由多系統組成的應用群，面對如此眾多的系統，使用者難道要一個一個登入、然後一個一個登出嗎？就像下圖描述的這樣

web系統由單系統發展成多系統組成的應用群，複雜性應該由系統內部承擔，而不是使用者。無論web系統內部多麼複雜，對使用者而言，都是一個統一的整體，也就是說，使用者訪問web系統的整個應用群與訪問單個系統一樣，登入/登出只要一次就夠了

雖然單系統的登入解決方案很完美，但對於多系統應用群已經不再適用了，為什麼呢？

單系統登入解決方案的核心是cookie，cookie攜帶會話id在瀏覽器與伺服器之間維護會話狀態。但cookie是有限制的，這個限制就是cookie的域（通常對應網站的域名）(解釋： 就是說一個伺服器產生的cookie只能在該伺服器下使用，不能在其他伺服器使用，而我們的分散式多系統就不一樣了，有可能這個請求打到這臺伺服器上，下一個請求就打到另一臺伺服器上了，所以某一個伺服器產生的cookie不能在所有其他伺服器上起作用)，瀏覽器傳送http請求時會自動攜帶與該域匹配的cookie，而不是所有cookie,意思就是說該伺服器產生的cookie，那麼cookie的key就是這個伺服器的域名（解釋：也就是說客戶端可以有很多個cookie,然後在負載均衡的情況下訪問不同的伺服器的時候，雖然每次訪問都帶了很多的cookie訪問某一臺伺服器，但是瀏覽器可以攔截其他的cookie,只用本伺服器產生的cookie)
　　
　　既然這樣，為什麼不將web應用群中所有子系統（一個web應用的功能可能被分割成多個模組）的域名（解釋： 每個模組可能有不同的域名，但是所有模組的功能總和組成了一整個web應用）統一在一個頂級域名下，例如“*.baidu.com”，然後將它們的cookie域設定為“baidu.com”，這種做法理論上是可以的，甚至早期很多多系統登入就採用這種同域名共享cookie的方式。（解釋： 一個伺服器產生的cookie只能在該伺服器下使用，為了讓瀏覽器訪問各個子模組的時候都能夠把共同的cookie帶過去，那只有一種情況，那就是cookie的名字或者域名都是一個頂級域名，能夠進行各個子模組的通配，從而各個子模組都可以接收這個cookie）
　　下圖是我對這段話的理解：
　　

然而，可行並不代表好，共享cookie的方式存在眾多侷限。首先，應用群域名得統一；其次，應用群各系統使用的技術（至少是web伺服器）要相同，不然cookie的key值（tomcat為JSESSIONID）不同（小疑問：就算web伺服器相同，就一定能保證cookie的key值相同嗎？還有不是說各個子模組的頂級域名已經相同了嗎，為什麼還有保證key值一樣 啊？可能是說域名相同，只是能夠確保能夠讓所有伺服器都能夠接收到這個cookie,但是接收到以後還要根據key值來取value值，所以key值最好是一樣的，這樣更方便些，而如果web伺服器相同的話，那麼key的值就相同（例如：tomcat為JSESSIONID）），無法維持會話，共享cookie的方式是無法實現跨語言技術平臺登入的，比如java、php、.net系統之間；第三，cookie本身不安全。

因此，我們需要一種全新的登入方式來實現多系統應用群的登入，這就是單點登入

三、單點登入

什麼是單點登入？單點登入全稱Single Sign On（以下簡稱SSO），是指在多系統應用群中登入一個系統，便可在其他所有系統中得到授權而無需再次登入，包括單點登入與單點登出兩部分
　　1、登入
　　相比於單系統登入，sso需要一個獨立的認證中心，只有認證中心能接受使用者的使用者名稱密碼等安全資訊，其他系統不提供登入入口，只接受認證中心的間接授權。間接授權通過令牌（tokens）實現，sso認證中心驗證使用者的使用者名稱密碼沒問題，建立授權令牌，在接下來的跳轉過程中，授權令牌作為引數傳送給各個子系統，子系統拿到令牌，即得到了授權，可以藉此建立區域性會話，區域性會話登入方式與單系統的登入方式相同。這個過程，也就是單點登入的原理，用下圖說明
解釋： 瀏覽器首先訪問系統1，系統1檢測到使用者沒有登入。於是帶上系統1的地址轉發到sso認證中心，也發現沒有登入，於是帶上系統1的地址來到登入頁面進行登入，登入完畢之後，sso認證中心就開始建立全域性會話（
小疑問：是如何建立全域性會話的？
答：sso認證中心校驗使用者資訊，建立使用者與sso認證中心之間的會話，稱為全域性會話），建立授權令牌tokens,接著有了tokens令牌之後就可以跳轉到系統1的地址了，這個時候系統1向sso認證中心校驗令牌有效，sso認證中心把系統1的地址註冊到sso認證中心上，然後返回給系統1，令牌有效，於是瀏覽器就可以訪問系統1了。
再接著如果瀏覽器要訪問系統2的話，在系統2上一驗證，發現沒有登入，這個時候就帶著系統2的地址跳去sso認證中心，sso認證中心上驗證已經登入，於是把令牌tokens傳送給系統2，這個時候系統2再次帶著系統2的地址和令牌來到sso認證中心驗證時，令牌肯定是有效的，然後sso中心把系統2的地址註冊到本地上，接著告訴系統2，令牌有效，於是瀏覽器就可以和系統2進行區域性會話了

　　下面給出最詳細的權威的解釋：
　　2、登出
　　單點登入自然也要單點登出，在一個子系統中登出，所有子系統的會話都將被銷燬，用下面的圖來說明
　　
　　

四、部署圖

單點登入涉及sso認證中心與眾多子系統，子系統與sso認證中心需要通訊以交換令牌、校驗令牌及發起登出請求，因而子系統必須整合sso的客戶端，sso認證中心則是sso服務端，整個單點登入過程實質是sso客戶端與服務端通訊的過程，用下圖描述
　　小疑問： 如果不加網路防火牆會怎麼樣？ 防火牆怎麼配置呢？有配置檔案嗎？還是隻需要dos命令就行

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

五、實現

只是簡要介紹下基於java的實現過程，不提供完整原始碼，明白了原理，我相信你們可以自己實現。sso採用客戶端/服務端架構，我們先看sso-client與sso-server要實現的功能（下面：sso認證中心=sso-server）
　　
　　1、sso-client攔截未登入請求
　　java攔截請求的方式有servlet、filter、listener三種方式，我們採用filter。在sso-client中新建LoginFilter.java類並實現Filter介面，在doFilter()方法中加入對未登入使用者的攔截
　　
　　2、sso-server攔截未登入請求
　　攔截從sso-client跳轉至sso認證中心的未登入請求，跳轉至登入頁面，這個過程與sso-client完全一樣
　　3、sso-server驗證使用者登入資訊
　　使用者在登入頁面輸入使用者名稱密碼，請求登入，sso認證中心校驗使用者資訊，校驗成功，將會話狀態標記為“已登入”

4、sso-server建立授權令牌
　　授權令牌是一串隨機字元，以什麼樣的方式生成都沒有關係，只要不重複、不易偽造即可，下面是一個例子
　　
　　5、sso-client取得令牌並校驗
　　sso認證中心登入後，跳轉回子系統並附上令牌，子系統（sso-client）取得令牌，然後去sso認證中心校驗，在LoginFilter.java的doFilter()中新增幾行

小疑問： httpclient的引數是這樣嗎？不解，httpPost括號裡面的引數

6、sso-server接收並處理校驗令牌請求
　　使用者在sso認證中心登入成功後，sso-server建立授權令牌並儲存該令牌，所以，sso-server對令牌的校驗就是去查詢這個令牌是否存在以及是否過期，令牌校驗成功後，sso-server將傳送校驗請求的系統註冊到sso認證中心（就是儲存起來的意思）

令牌與註冊系統地址通常儲存在key-value資料庫（如redis）中，redis可以為key設定有效時間也就是令牌的有效期。redis執行在記憶體中，速度非常快，正好sso-server不需要持久化任何資料。

令牌與註冊系統地址可以用下圖描述的結構儲存在redis中，可能你會問，為什麼要儲存這些系統的地址？如果不儲存，登出的時候就麻煩了，使用者向sso認證中心提交登出請求，sso認證中心登出全域性會話，但不知道哪些系統用此全域性會話建立了自己的區域性會話，也不知道要向哪些子系統傳送登出請求登出區域性會話
　　小疑問： 下面這幅圖看不明白？？？
　　7、sso-client校驗令牌成功建立區域性會話
　　令牌校驗成功後，sso-client將當前區域性會話標記為“已登入”，修改LoginFilter.java，新增幾行（解釋： 因為瀏覽器可能會訪問多個子模組，從而產生多個區域性會話，相當於瀏覽器與每個子模組伺服器之間都有一個session）
　　
　　sso-client還需將當前會話id（sessionID）與令牌繫結（解釋： 因為一旦登出，那麼就可以根據sessionID來取出令牌，最後到sso認證中心上檢測存在該令牌，然後銷燬全域性會話，從而銷燬所有的令牌），表示這個會話的登入狀態與令牌相關，此關係可以用java的hashmap儲存，儲存的資料用來處理sso認證中心發來的登出請求（解釋：就是說一個點發起了登出請求之後，sso認證中心接收到了之後，從而銷燬全域性會話，然後取出所有web應用各個模組系統的註冊令牌並銷燬，然後通知各個模組，令牌失效，各區域性session全部銷燬，這樣一來，使用者就不能和各子模組再次互動通訊了）
　　重點： 本質上只有一個全域性session會話（就是瀏覽器與sso認證中心的會話），其他的都是區域性session，一旦消除全域性session，那麼區域性session也會被通知由於各自的令牌銷燬從而導致本區域性session也要銷燬
　　
　　8、登出過程
　　使用者向子系統傳送帶有“logout”引數的請求（登出請求），sso-client攔截器攔截該請求，向sso認證中心發起登出請求
　　
　　　sso認證中心也用同樣的方式識別出sso-client的請求是登出請求（帶有“logout”引數），sso認證中心登出全域性會話
　　　
　　　解釋： 全域性session（瀏覽器跟sso認證中心之間的session）登出之後觸發LogoutListener，在LogoutListener中還要銷燬所有的各個web系統的子模組的令牌

sso認證中心有一個全域性會話的監聽器，一旦全域性會話登出，將通知所有註冊系統登出