SSO单点登录三种情况的实现方式详解
SSO單點登錄三種情況的實現方式詳解
單點登錄（SSO——Single Sign On）對于我們來說已經不陌生了。對于大型系統來說使用單點登錄可以減少用戶很多的麻煩。就拿百度來說吧，百度下面有很多的子系統——百度經驗、百度知道、百度文庫等等，如果我們使用這些系統的時候，每一個系統都需要我們輸入用戶名和密碼登錄一次的話，我相信用戶體驗肯定會直線下降。當然，對于個人博客這類系統來說根本就用不上單點登錄了。
假如，我們的系統很龐大，但是就是這一個系統，并沒有什么子系統。這時我們也不需要單點登錄。我們需要的是搭建集群環境，這里雖說只有一個系統，但是多臺主機負載均衡的話就涉及到session共享的問題了。Session共享問題較之于SSO來說將比較容易解決了。
好，我們不管不需要單點登錄的系統了。題目中已經標明了SSO單點登錄的三種情況，下面我們分別來介紹這三種情況。
在同一個域名下的不同站點是如何進行驗證的
我們知道，PHP表單驗證是完全依賴于Cookie的。因此說，如果兩個站點可以共享相同的驗證Cookie，這將很容易實現使用同一個用戶登錄多個站點。
按照HTTP協議規定，兩個站點是可以共享Cookie的。前提是這兩個站點是在同一個域名下面（或者是二級域名也可）。這種情況是屬于同域下的Cookie。瀏覽器會將Cookie以及該Cookie所屬的域存在本地。當你對該域下的任何子站點進行訪問的時候，瀏覽器都會將這些Cookie發送給站點系統。
假設我們有兩個站點
www.onmpw.com/site1 www.onmpw.com/site2
這兩個站點共享同一個主機地址，并且二者在同一域名下。加入你剛剛登錄了www.onmpw.com/site1，你的瀏覽器會有一個來自www.onmpw.com/site1的身份鑒證的cookie。當你點擊site1下的任何的子頁面的時候，這些cookie都會發送給site1。這是很容易理解的。同樣的，當你請求www.onmpw.com/site2的時候，對于site2下面的任何頁面這些cookie也同樣會隨著請求發送過去。為什么是這樣，因為在瀏覽器端存儲的cookie的域是www.onmpw.com。site1和site2兩個站點是同屬于該域的。所以對于該域下的cookie，兩個站點都可以得到。
這種情況，如果系統是PHP的話我們根本不需要進行什么特殊的處理。只需要按照正常的驗證方式進行驗證即可。因為二者的sessionId是相同的，只要它們的session信息是保存在同一個地方即可。
同一個域但是不同的子域如何進行單點登錄
假如我們的站點是按照下面的域名進行部署的
sub1.onmpw.com sub2.onmpw.com
這兩個站點共享同一域onmpw.com。
默認情況下，瀏覽器會發送cookie所屬的域對應的主機。也就是說，來自于sub1.onmpw.com的cookie默認所屬的域是.sub1.onmpw.com。因此，sub2.onmpw.com不會得到任何的屬于sub1.onmpw.com的cookie信息。因為它們是在不同的主機上面，并且二者的子域也是不同的。
這種情況，如果我們使用PHP來實現的話，可以設置二者的cookie信息在同一個域下。
第一 登錄sub1.onmpw.com系統
第二 登錄成功以后，設置cookie信息。這里需要注意，我們可以將用戶名和密碼存到cookie中，但是在設置的時候必須將這cookie的所屬域設置為頂級域 .onmpw.com。這里可以使用setcookie函數，該函數的第四個參數是用來設置cookie所述域的。
setcookie(‘username’,’onmpw’,null,’.onmpw.com’); setcookie(‘password’,’pwd’,null,’.onmpw.com’);
第三 訪問sub2.onmpw.com系統，瀏覽器會將cookie中的信息username和password附帶在請求中一塊兒發送到sub2.onmpw.com系統。這時該系統會先檢查session是否登錄，如果沒有登錄則驗證cookie中的username和password從而實現自動登錄。
第四 sub2.onmpw.com 登錄成功以后再寫session信息。以后的驗證就用自己的session信息驗證就可以了。
當然，先登錄sub2.onmpw.com的方式也是相同的。經過上面的步驟就可以實現不同二級域名的單點登錄了。
但是，這里存在一個問題就是sub1系統退出以后，除了可以清除自身的session信息和所屬域為.onmpw.com的cookie的信息。它并不能清除sub2系統的session信息。那sub2仍然是登錄狀態。也就是說，這種方式雖說可以實現單點登錄，但是不能實現同時退出。原因是，sub1和sub2雖說通過setcookie函數的設置可以共享cookie，但是二者的sessionId是不同的，而且這個sessionId在瀏覽器中也是以cookie的形式存儲的，不過它所屬的域并不是.onmpw.com。也就是說二者的sessionId是不同的。
那如何解決這個問題呢？我們知道，對于這種情況，只要是兩個系統的sessionId相同就可以解決這個問題了。也就是說存放sessionId的cookie所屬的域也是.onmpw.com。在PHP中，sessionId是在session_start()調用以后生成的。要想使sub1和sub2有共同的sessionId，那必須在session_start()之前設置sessionId所屬域。有兩種方式：
第一 使用php函數ini_set函數進行如下設置
ini_set('session.cookie_path', '/'); ini_set('session.cookie_domain', '.onmpw.com'); ini_set('session.cookie_lifetime', '0');
第二 直接修改php.ini 文件
session.cookie_path = / session.cookie_domain = '.onmpw.com' session.cookie_lifetime = 0
經過以上設置，sub1和sub2系統就會使用相同的session信息了。這樣既可以實現單點登錄，也可以實現同時退出。
不同域之間如何實現單點登錄
假設我們需要在以下這些站之間實現單點登錄
www.onmpw1.com www.onmpw2.com www.onmpw3.com
對于這種情況，我們有兩種實現方式，其中我們先來介紹實現比較簡單的方式。
方式一
為了實現單點登錄，當用戶登錄其中的任何一個站點時，我們需要針對其他每個站點在瀏覽器端設置cookie信息。
如果用戶在onmpw1站點進行登錄，登錄成功授權以后，瀏覽器將會存儲一份兒onmpw1站點的cookie信息。同時，為了可以登錄onmpw2和onmpw3，我們需要在設置onmpw1的cookie的同事也對onmpw2和onmpw3進行cookie設置。因此在對onmpw1進行響應之前，我們需要先跳轉到onmpw2和onmpw3站點去設置cookie信息。
下圖是對于兩個站點的單點登錄模型（三個的圖畫起來比較麻煩，為了節省時間，就用兩個來表示，但是原理是相同的）
此種情況的驗證步驟是這樣的：
一、用戶向www.onmpw1.com（以下簡稱onmpw1）請求一個需要驗證的頁面。
[狀態: 瀏覽器還沒有驗證的cookie信息]
二、瀏覽器向onmpw1發送請求（該請求沒有cookie信息，因為它還沒有存儲所屬域為onmpw1.com的cookie信息）。
[狀態: 瀏覽器還沒有驗證的cookie信息]
三、onmpw1發現在請求中沒有帶cookie信息，所以它將請求重定向到登錄頁面
[狀態: 瀏覽器還沒有驗證的cookie信息]
四、用戶提交了登錄所需驗證的信息并且點擊登錄按鈕，瀏覽器發送一個post請求到onmpw1。
[狀態: 瀏覽器還沒有驗證的cookie信息]
五、onmpw1收到提交的驗證信息，開始驗證這些信息。如果驗證成功，則標記該用戶已經登錄。然后會創建帶有登錄用戶信息的cookie，并將其加入響應信息中。
[狀態: 瀏覽器還沒有驗證的cookie信息]
六、onmpw1暫時還不去響應瀏覽器的請求。這時它將會向瀏覽器發送重定向到www.onmpw2.com（以下簡稱onmpw2）的命令，并且還帶有在onmpw2站點需要返回的url地址，該地址為最初onmpw1中的。因為cookie信息已經在響應信息中，所以這個cookie也被發送給瀏覽器了。
[狀態: 瀏覽器還沒有驗證的cookie信息]
七、瀏覽器接收道帶有驗證的cookie信息和重定向到onmpw2的命令的響應信息以后，將cookie信息的域設置為onmpw2存儲到本地，并且想onmpw2發送請求。這個請求中會帶有剛才的cookie信息。
[狀態：瀏覽器中已經有所屬域為onmpw2的cookie信息]
八、onmpw2立刻會重定向到需要返回的url地址，并且通過讀取瀏覽器發送的cookie信息，獲取到onmpw1的cookie。并將這cookie也一同發送給瀏覽器。
[狀態：瀏覽器中已經有所屬域為onmpw2的cookie信息]
九、瀏覽器在接受到這些信息以后，會將所屬域為onmpw1的cookie存儲在本地。并且再次向onmpw1發送一個帶有cookie信息的請求。
[狀態：瀏覽器中已經有所屬域為onmpw2和onmpw1的cookie信息]
十、onmpw1接收到驗證信息以后，知道驗證cookie已經設置成功。此時onmpw1會返回相應的請求界面，而不再是登錄界面。
[狀態：瀏覽器中已經有所屬域為onmpw2和onmpw1的cookie信息]
所以說，當用戶再次訪問onmpw2的時候，cookie信息已經存儲到瀏覽器中了。這時onmpw2會在cookie中讀取到登錄的用戶的信息，然后提供相應的界面給瀏覽器。
這樣，單點登錄就已經設置成功了。在本例中，按照上述步驟，登錄onmpw1以后，onmpw2和onmpw3就可以同時實現登錄了。
如何退出登錄
既然我們已經實現了單點登錄，但是我們還得考慮退出的問題。既然是同時登錄的，那總不能在退出的時候一個一個的退出吧！所以說我們還要設置單點退出。
要想實現單點退出，在本例中，我們需要做的是當在一個站點退出的時候，其他兩個站點的cookie同樣也需要在瀏覽器中清除。這樣才可以實現單點退出。
這樣其實也很簡單，在理解了上述單點登錄的流程以后，單點退出只是按照上面的步驟將設置驗證cookie改成從響應信息中移除cookie就可以實現了。
對于這種情況，不管是單點登錄也好，還是單點退出。都存在一個問題，在本例中我們只是有三個站點。如果說我們整個系統有10個20個或者更多站點，那像我們這樣來回的重定向會很影響效率。
方式二
接下來我們來介紹另一種方式。這種方式需要我們借助一個單獨的SSO服務，專門做驗證用。而且我們還需要對于不同的站點的用戶要有一個統一的用戶數據。相對于前一種方式——瀏覽器需要存儲每個站點的cookie——來說，這種方式瀏覽器只需要存儲SSO服務站點的cookie信息。將這個cookie信息用于其他站點從而實現單點登錄。我們暫且將這個SSO服務站點成為www.SSOsite.com（以下簡稱SSOsite）。
在這種模型下，針對任何站點的請求都將會先重定向到SSOsite去驗證一個身份驗證cookie是否存在。如果存在，則驗證過的頁面將會發送給瀏覽器。否則用戶將會被重定向到登錄頁面。
為了理解此種方式，現在假設我們來運用這種模型實現以下兩個站點的單點登錄。
www.onmpw1.com（以下簡稱onmpw1） www.onmpw2.com（以下簡稱onmpw2）
并且我們還有一個專門用來進行驗證的服務站點www.SSOsite.com（以下簡稱SSOsite） 。
第一部分
實現流程
·用戶請求onmpw1的一個需要驗證的頁面
·onmpw1向瀏覽器發送重定向到SSOsite的命令。并且在地址中添加一個返回地址（ReturnUrl）參數query string，該參數的值就是最初向onmpw1請求的地址。
·SSOsite會在請求中檢查是否有身份驗證cookie，或者任何用戶token。沒有這些信息，則會再次重定向到onmpw1，在重定向到onmpw1中的請求中會帶有參數讓用戶登錄的url參數和最初的瀏覽器請求onmpw1的地址——ReturnUrl。
·onmpw1會檢測從SSOsite重定向來的請求的參數。這時onmpw1了解到該用戶需要登錄，因此onmpw1會重定向到登錄界面，并且通知瀏覽器該請求不用再重定向到SSOsite。
第二部分
·用戶提供了身份驗證信息并且點擊了登錄按鈕。現在不會再去重定向到SSOsite。這時，onmpw1調用SSOsite 中的web/WCF服務去檢查用戶提供的身份驗證信息。成功驗證，會將帶有token屬性的用戶對象返回給onmpw1。而這個token是每一次用戶登錄都會生成的。
·onmpw1標記用戶已經登錄成功，然后會生成一個URL地址，該地址會帶有用戶token，重定向到SSOsite。
·SSOsite檢查收到的URL地址，會在其中發現用戶token。通過該token可以知道用戶已經成功登錄onmpw1了，所以SSOsite需要準備驗證的cookie信息。因此，它會使用token在緩存中取出用戶信息來生成cookie信息，而且還會在cookie中設置一些其他的信息（例如過期時間等）。然后把cookie加入到響應信息中。最后重定向到最初的ReturnUrl地址。同時token還是要被加在query string中帶過去的。
·瀏覽器得到重定向到onmpw1的命令，并且從SSOsite中得到cookie信息。因此瀏覽器將所屬域為SSOsite的cookie保存在本地。然后帶著token去請求onmpw1。
·現在onmpw1看到用戶token在query string 參數中，然后會再次通過web/WCF服務去在SSOsite上驗證token。驗證成功以后會將最初剛開始請求的頁面發送給瀏覽器用于向用戶輸出。
第三部分
·用戶現在去請求onmpw2。
·onmpw2重定向到SSOsite，同樣設置ReturnUrl為剛開始請求的onmpw2的頁面地址。
·瀏覽器接收到重定向的命令以后，因為本地存在SSOsite的cookie，所以會cookie加到請求中發送給SSOsite。
·SSOsite檢查接收到的請求中發現有cookie信息，首先會檢查該cookie信息是否過期，如果沒有過期，將會從cookie中提取出用戶token。然后帶著token重定向到最初的onmpw2中的地址。
·onmpw2發現請求中有用戶token，然后他會通過SSOsite的web/WCF服務驗證token的合法性。驗證成功以后，將最初瀏覽器請求onmpw2的頁面發送給瀏覽器用以向用戶輸出。
總結
哇哦，看起來有很多東西需要做。其實并沒有那么復雜。
起初，瀏覽器沒有所屬域為SSOsite的cookie信息。因此無論是點擊任何站點的需要驗證的界面都會跳轉到登錄頁（這個過程是由程序內部重定向到SSOsite來檢查是否存在cookie的）。一旦用戶登錄成功，所屬域為SSOsite的，并且帶有登錄用戶信息的cookie會被瀏覽器存儲在本地。
然后，當用戶再次訪問需要驗證的頁面的時候，同樣請求會在被重定向到SSOsite，并且瀏覽器會帶上先前已經保存的cookie信息。SSOsite檢索cookie，從中提取出用戶token，并帶著這個token重定向到最初請求的站點頁面。然后該站點會通過web/WCF服務去驗證token的合法性。然后將相應的頁面發送給客戶端。
一旦用戶通過該單點登錄模型登錄到站點上，請求任何需要驗證的頁面都會內部重定向到SSOsite驗證cookie和提取用戶token，然后將請求的頁面發送給瀏覽器輸出。
?
總結
以上是生活随笔為你收集整理的SSO单点登录三种情况的实现方式详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 创业互联网公司如何搭建自己的技术框架
- 下一篇： Maven最佳实践：版本管理