背景

在企業(yè)發(fā)展初期,，企業(yè)使用的系統(tǒng)很少，通常一個或者兩個,，每個系統(tǒng)都有自己的登錄模塊,，運(yùn)營人員每天用自己的賬號登錄，很方便,。
但隨著企業(yè)的發(fā)展,，用到的系統(tǒng)隨之增多，運(yùn)營人員在操作不同的系統(tǒng)時,，需要多次登錄,，而且每個系統(tǒng)的賬號都不一樣，這對于運(yùn)營人員
來說,，很不方便,。于是,，就想到是不是可以在一個系統(tǒng)登錄，其他系統(tǒng)就不用登錄了呢,？這就是單點登錄要解決的問題,。

單點登錄英文全稱Single Sign On，簡稱就是SSO,。它的解釋是：在多個應(yīng)用系統(tǒng)中,，只需要登錄一次，就可以訪問其他相互信任的應(yīng)用系統(tǒng),。

如圖所示,，圖中有4個系統(tǒng)，分別是Application1,、Application2,、Application3、和SSO,。Application1,、Application2、Application3沒有登錄模塊,，而SSO只有登錄模塊,，沒有其他的業(yè)務(wù)模塊，當(dāng)Application1,、Application2,、Application3需要登錄時，將跳到SSO系統(tǒng),，SSO系統(tǒng)完成登錄,，其他的應(yīng)用系統(tǒng)也就隨之登錄了。這完全符合我們對單點登錄（SSO）的定義,。

技術(shù)實現(xiàn)

在說單點登錄（SSO）的技術(shù)實現(xiàn)之前,，我們先說一說普通的登錄認(rèn)證機(jī)制。

如上圖所示,，我們在瀏覽器（Browser）中訪問一個應(yīng)用,，這個應(yīng)用需要登錄，我們填寫完用戶名和密碼后,，完成登錄認(rèn)證,。這時，我們在這個用戶的session中標(biāo)記登錄狀態(tài)為yes（已登錄）,，同時在瀏覽器（Browser）中寫入Cookie,，這個Cookie是這個用戶的唯一標(biāo)識。下次我們再訪問這個應(yīng)用的時候，請求中會帶上這個Cookie,，服務(wù)端會根據(jù)這個Cookie找到對應(yīng)的session,，通過session來判斷這個用戶是否登錄。如果不做特殊配置,，這個Cookie的名字叫做jsessionid,，值在服務(wù)端（server）是唯一的。

同域下的單點登錄

一個企業(yè)一般情況下只有一個域名,，通過二級域名區(qū)分不同的系統(tǒng),。比如我們有個域名叫做：a.com，同時有兩個業(yè)務(wù)系統(tǒng)分別為：app1.a.com和app2.a.com,。我們要做單點登錄（SSO）,，需要一個登錄系統(tǒng)，叫做：sso.a.com,。

我們只要在sso.a.com登錄,，app1.a.com和app2.a.com就也登錄了。通過上面的登陸認(rèn)證機(jī)制,，我們可以知道,，在sso.a.com中登錄了，其實是在sso.a.com的服務(wù)端的session中記錄了登錄狀態(tài),，同時在瀏覽器端（Browser）的sso.a.com下寫入了Cookie,。那么我們怎么才能讓app1.a.com和app2.a.com登錄呢？這里有兩個問題：

• Cookie是不能跨域的,，我們Cookie的domain屬性是sso.a.com,，在給app1.a.com和app2.a.com發(fā)送請求是帶不上的。

• sso,、app1和app2是不同的應(yīng)用,，它們的session存在自己的應(yīng)用內(nèi)，是不共享的,。

那么我們?nèi)绾谓鉀Q這兩個問題呢？針對第一個問題,，sso登錄以后,，可以將Cookie的域設(shè)置為頂域，即.a.com,，這樣所有子域的系統(tǒng)都可以訪問到頂域的Cookie,。我們在設(shè)置Cookie時，只能設(shè)置頂域和自己的域,，不能設(shè)置其他的域,。比如：我們不能在自己的系統(tǒng)中給baidu.com的域設(shè)置Cookie。

Cookie的問題解決了，我們再來看看session的問題,。我們在sso系統(tǒng)登錄了,，這時再訪問app1，Cookie也帶到了app1的服務(wù)端（Server）,，app1的服務(wù)端怎么找到這個Cookie對應(yīng)的Session呢,？這里就要把3個系統(tǒng)的Session共享，如圖所示,。共享Session的解決方案有很多,，例如：Spring-Session。這樣第2個問題也解決了,。

同域下的單點登錄就實現(xiàn)了,，但這還不是真正的單點登錄。

不同域下的單點登錄

同域下的單點登錄是巧用了Cookie頂域的特性,。如果是不同域呢,？不同域之間Cookie是不共享的，怎么辦,？

這里我們就要說一說CAS流程了,，這個流程是單點登錄的標(biāo)準(zhǔn)流程。

上圖是CAS官網(wǎng)上的標(biāo)準(zhǔn)流程,，具體流程如下：

1. 用戶訪問app系統(tǒng),，app系統(tǒng)是需要登錄的，但用戶現(xiàn)在沒有登錄,。

2. 跳轉(zhuǎn)到CAS server,，即SSO登錄系統(tǒng)，以后圖中的CAS Server我們統(tǒng)一叫做SSO系統(tǒng),。 SSO系統(tǒng)也沒有登錄,，彈出用戶登錄頁。

3. 用戶填寫用戶名,、密碼,，SSO系統(tǒng)進(jìn)行認(rèn)證后，將登錄狀態(tài)寫入SSO的session,，瀏覽器（Browser）中寫入SSO域下的Cookie,。

4. SSO系統(tǒng)登錄完成后會生成一個ST（Service Ticket），然后跳轉(zhuǎn)到app系統(tǒng),，同時將ST作為參數(shù)傳遞給app系統(tǒng),。

5. app系統(tǒng)拿到ST后，從后臺向SSO發(fā)送請求,，驗證ST是否有效,。

6. 驗證通過后,，app系統(tǒng)將登錄狀態(tài)寫入session并設(shè)置app域下的Cookie。

至此,，跨域單點登錄就完成了,。以后我們再訪問app系統(tǒng)時，app就是登錄的,。接下來,，我們再看看訪問app2系統(tǒng)時的流程。

1. 用戶訪問app2系統(tǒng),，app2系統(tǒng)沒有登錄,，跳轉(zhuǎn)到SSO。

2. 由于SSO已經(jīng)登錄了,，不需要重新登錄認(rèn)證,。

3. SSO生成ST，瀏覽器跳轉(zhuǎn)到app2系統(tǒng),，并將ST作為參數(shù)傳遞給app2,。

4. app2拿到ST，后臺訪問SSO,，驗證ST是否有效,。

5. 驗證成功后，app2將登錄狀態(tài)寫入session,，并在app2域下寫入Cookie,。

這樣，app2系統(tǒng)不需要走登錄流程,，就已經(jīng)是登錄了,。SSO，app和app2在不同的域,，它們之間的session不共享也是沒問題的,。

有的同學(xué)問我，SSO系統(tǒng)登錄后,，跳回原業(yè)務(wù)系統(tǒng)時,，帶了個參數(shù)ST，業(yè)務(wù)系統(tǒng)還要拿ST再次訪問SSO進(jìn)行驗證,，覺得這個步驟有點多余,。他想SSO登錄認(rèn)證通過后，通過回調(diào)地址將用戶信息返回給原業(yè)務(wù)系統(tǒng),，原業(yè)務(wù)系統(tǒng)直接設(shè)置登錄狀態(tài)，這樣流程簡單,，也完成了登錄,，不是很好嗎？

其實這樣問題時很嚴(yán)重的，如果我在SSO沒有登錄,，而是直接在瀏覽器中敲入回調(diào)的地址,，并帶上偽造的用戶信息，是不是業(yè)務(wù)系統(tǒng)也認(rèn)為登錄了呢,？這是很可怕的,。

總結(jié)

單點登錄（SSO）的所有流程都介紹完了，原理大家都清楚了,?？偨Y(jié)一下單點登錄要做的事情：

• 單點登錄（SSO系統(tǒng)）是保障各業(yè)務(wù)系統(tǒng)的用戶資源的安全 。

• 各個業(yè)務(wù)系統(tǒng)獲得的信息是,，這個用戶能不能訪問我的資源,。

• 單點登錄，資源都在各個業(yè)務(wù)系統(tǒng)這邊,，不在SSO那一方,。 用戶在給SSO服務(wù)器提供了用戶名密碼后，作為業(yè)務(wù)系統(tǒng)并不知道這件事,。 SSO隨便給業(yè)務(wù)系統(tǒng)一個ST,，那么業(yè)務(wù)系統(tǒng)是不能確定這個ST是用戶偽造的，還是真的有效,，所以要拿著這個ST去SSO服務(wù)器再問一下,，這個用戶給我的ST是否有效，是有效的我才能讓這個用戶訪問,。