有沒有哪位大神可以詳細講解一下sso?萬分感謝。？

sso的定義與實現。

當前的大中型Web互聯網應用基本都是多系統組成的應用群，由多個web系統協同為用戶提供服務。

多系統應用群，必然意味著各系統間既相對獨立，又保持著某種聯繫。

獨立，意味著給用戶提供一個相對完整的功能服務，比如C2C商城，比如B2C商城。聯繫，意味著從用戶角度看，不管企業提供的服務如何多樣化、系列化，在用戶看來，仍舊是一個整體，用戶體驗不能受到影響。

譬如用戶的賬號管理，用戶應該有一個統一賬號，不應該讓用戶在每個子系統分別註冊、分別登錄、再分別登出。系統的複雜性不應該讓用戶承擔。

登錄用戶使用系統服務，可以看做是一次用戶會話過程。在單Web應用中，用戶登錄、登錄狀態判斷、用戶登出等操作，已有很常規的解決方案實現。

在多系統應用群中，這個問題就變得有些複雜，以前本不是問題的問題，現在可能就變成了一個重大技術問題。我們要用技術手段，屏蔽系統底層本身的技術複雜性，給用戶提供自然超爽的用戶體驗。

這就是我們所說的單點登錄問題，即SSO(Single Sign On)。當然，我們這裡主要討論的是Web系統，確切地講，應該叫Web SSO

實際案例

下面我們來看一個現實中SSO的例子，例如阿里系統：

阿里目前給用戶提供的服務很龐大，種類也很繁多，我們看幾個典型系統應用：淘寶應用、 天貓應用、阿里旅遊。這些應用，當用戶訪問時，都需要登錄

顯然，對用戶來說，他不希望每個子應用分別登錄，因為這都是阿里服務，在用戶看來，就相當於一個大系統。

當我在一個應用如淘寶上登錄後，再訪問阿里旅遊、天貓等其它系統，我們發現，系統都顯示已登錄狀態。

當在任意一系統退出登錄後，再刷新訪問其它系統，均已顯示登出狀態。

可以看出，阿里實現了SSO。實際上，幾乎所有提供複雜服務的互聯網公司，都實現了SSO，如阿里、百度、新浪、網易、騰訊、58...

SSO問題，是大中型Web應用經常碰到的問題，是Java架構師需要掌握的必備技能之一，中高級以上Web工程師都應對它有個了解。

SSO技術難點

SSO有啥技術難點？為什麼我們不能像解決單Web應用系統登錄那樣自然解決？為說清楚這一問題，我們得先了解下單應用系統下，用戶登錄的解決方案。

我們討論的應用是Web應用，大家知道，對於Web應用，系統是Browser/Server架構，Browser和Server之間的通信協議是HTTP協議。

HTTP是一個無狀態協議。即對伺服器來說，每次收到的瀏覽器HTTP請求都是單一獨立的，伺服器並不考慮兩次HTTP請求是否來自同一會話，即HTTP協議是非連接會話狀態協議。

對於Web應用登錄，意味著登錄成功後的後續訪問，可以看做是登錄用戶和服務端的一次會話交互過程，直到用戶登出結束會話。

如何在非連接會話協議之上，實現這種會話的管理？ 我們需要額外的手段。

通常有兩種做法，一種是通過使用HTTP請求參數傳遞，這種方式對應用侵入性較大，一般不使用。

另一種方式就是通過cookie。

cookie是HTTP提供的一種機制，cookie代表一小撮數據，服務端HTTP響應設置好後，瀏覽器下次請求會自動攜帶上返回給服務端。

利用這個機制，我們可以實現應用層的登錄會話狀態管理。例如在登錄成功後，服務端可以創建一個唯一登錄會話，並把會話標識ID通過cookie返回給瀏覽器，瀏覽器下次訪問時會自動帶上這個ID，服務端根據ID即可判斷是此會話中的請求，從而判斷出是該用戶，這種操作直到登出銷毀會話為止。

令人高興的是，我們使用的Web應用伺服器一般都會提供這種會話基礎服務，如Tomcat的Session機制。也就是說，應用開發人員不必利用Cookie親自代碼實現會話的創建、維護和銷毀等整個生命周期管理，這些內容伺服器Session已經提供好了，我們只需正確使用即可。

當然，為了靈活性和效率，開發人員也可直接使用cookie實現自己的這種會話管理。

對於Cookie，處於安全性考慮，它有一個作用域問題，這個作用域由屬性Domain和Path共同決定的。也就是說，如果瀏覽器發送的請求不在此Cookie的作用域範圍內，請求是不會帶上此Cookie的。

Path是訪問路徑，我們可以定義/根路徑讓其作用所有路徑，Domain就不一樣了。我們不能定義頂級域名如.com，讓此Cookie對於所有的com網站都起作用，最大範圍我們只能定義到二級域名如.http://taobao.com，而通常，企業的應用群可能包含有多個二級域名，如http://taobao.com、http://tmail.com、http://alitrip.com等等。

這時，解決單系統會話問題的Cookie機制不起作用了，多系統不能共享同一會話，這就是問題的所在！

當然，有的同學會說：我把所有的應用統一用三級域名來表示，如http://a.taobao.com、http://b.taobao.com、http://c.taobao.com或乾脆用路徑來區分不同的應用如淘寶網 - 淘！我喜歡a、淘寶網 - 淘！我喜歡、淘寶網 - 淘！我喜歡c，這樣cookie不就可以共享了么？

事實是成立的，但現實應用中，多域名策略是普遍存在的，也有商業角度的考慮，這些我們必須要面對。

退一步講，即使cookie可以共享了，服務端如何識別處理這個會話？這時，我們是不能直接使用伺服器所提供的Session機制的，Session是在單一應用範圍內，共享Session需要特殊處理。

更複雜的情況是，通常這些子系統可能是異構的，session實現機制並不相同，如有的是Java系統，有的是PHP系統。共享Session對原系統入侵性很大。

至此，SSO技術問題這裡講清楚了。那我們有沒有更好的通用解決方案？答案肯定是有的，但比較複雜。總體來說，我們需要一個中央認證伺服器，來統一集中處理各子系統的登錄請求。這是入門，後續會有系列文章深層次探討。

後續總結

對SSO你至少需要了解以下內容：

1. 大中型Web應用基本都是多系統組成的應用群，SSO是必須面對的基本問題。

2. Cookie有作用域限制，頂級域名Cookie不能共享，故登錄會話不能共享。

3.直接改造各子系統共享Session，通用性靈活性不強，或對原系統入侵性大，不是解決SSO根本辦法。