單點登陸（SSO）工做原理

單點登陸（SSO）工做原理

1、單點登陸的介紹

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

例如：百度旗下有不少的產品，好比百度貼吧、百度知道、百度文庫等，只要登陸百度帳號，在任何一個地方都是已登陸狀態，不須要從新登陸。

當用戶第一次訪問應用系統的時候，由於尚未登陸，會被引導到認證系統中進行登陸；根據用戶提供的登陸信息，認證系統進行身份校驗，若是經過校驗，應該返回給用戶一個認證的憑據－－ticket；用戶再訪問別的應用的時候，就會將這個ticket帶上，做爲本身認證的憑據，應用系統接受到請求以後會把ticket送到認證系統進行校驗，檢查ticket的合法性。若是經過校驗，用戶就能夠在不用再次登陸的狀況下訪問應用系統2和應用系統3了。

 

 

 

要實現SSO，須要如下主要的功能：

全部應用系統共享一個身份認證系統。
統一的認證系統是SSO的前提之一。認證系統的主要功能是將用戶的登陸信息和用戶信息庫相比較，對用戶進行登陸認證；認證成功後，認證系統應該生成統一的認證標誌（ticket），返還給用戶。另外，認證系統還應該對ticket進行效驗，判斷其有效性。
全部應用系統可以識別和提取ticket信息
要實現SSO的功能，讓用戶只登陸一次，就必須讓應用系統可以識別已經登陸過的用戶。應用系統應該能對ticket進行識別和提取，經過與認證系統的通信，能自動判斷當前用戶是否登陸過，從而完成單點登陸的功能。

2、單點登陸技術實現機制

在說單點登陸（SSO）的技術實現以前，咱們先說一說普通的登陸認證機制。

 

 

 

如上圖所示，咱們在瀏覽器（Browser）中訪問一個應用，這個應用須要登陸，咱們填寫完用戶名和密碼後，完成登陸認證。這時，咱們在這個用戶的session中標記登陸狀態爲yes（已登陸），同時在瀏覽器（Browser）中寫入Cookie，這個Cookie是這個用戶的惟一標識。下次咱們再訪問這個應用的時候，請求中會帶上這個Cookie，服務端會根據這個Cookie找到對應的session，經過session來判斷這個用戶是否登陸。若是不作特殊配置，這個Cookie的名字叫作jsessionid，值在服務端（server）是惟一的。

一、同域下的單點登陸

一個企業通常狀況下只有一個域名，經過二級域名區分不一樣的系統。好比咱們有個域名叫作：a.com，同時有兩個業務系統分別爲：app1.a.com和app2.a.com。咱們要作單點登陸（SSO），須要一個登陸系統，叫作：sso.a.com。

咱們只要在sso.a.com登陸，app1.a.com和app2.a.com就也登陸了。經過上面的登錄認證機制，咱們能夠知道，在sso.a.com中登陸了，實際上是在sso.a.com的服務端的session中記錄了登陸狀態，同時在瀏覽器端（Browser）的sso.a.com下寫入了Cookie。那麼咱們怎麼才能讓app1.a.com和app2.a.com登陸呢？

這裏有兩個問題：

1，Cookie是不能跨域的，咱們Cookie的domain屬性是sso.a.com，在給app1.a.com和app2.a.com發送請求是帶不上的。
2，sso、app1和app2是不一樣的應用，它們的session存在本身的應用內，是不共享的。

 

 

 

那麼咱們如何解決這兩個問題呢？

針對第一個問題，sso登陸之後，能夠將Cookie的域設置爲頂域，即.a.com，這樣全部子域的系統均可以訪問到頂域的Cookie。咱們在設置Cookie時，只能設置頂域和本身的域，不能設置其餘的域。好比：咱們不能在本身的系統中給baidu.com的域設置Cookie。

Cookie的問題解決了，咱們再來看看session的問題。咱們在sso系統登陸了，這時再訪問app1，Cookie也帶到了app1的服務端（Server），app1的服務端怎麼找到這個Cookie對應的Session呢？這裏就要把3個系統的Session共享，如圖所示。共享Session的解決方案有不少，例如：Spring-Session。這樣第2個問題也解決了。

同域下的單點登陸就實現了，但這還不是真正的單點登陸。

二、不一樣域下的單點登陸

同域下的單點登陸是巧用了Cookie頂域的特性。若是是不一樣域呢？不一樣域之間Cookie是不共享的，怎麼辦？

這裏咱們就要說一說CAS流程了，這個流程是單點登陸的標準流程。

下面的是這篇文章的重點！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

下面的是這篇文章的重點！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

1，用戶訪問app系統，app系統是須要登陸的，但用戶如今沒有登陸。
2，跳轉到CAS server，即SSO登陸系統，之後圖中的CAS Server咱們統一叫作SSO系統。 SSO系統也沒有登陸，彈出用戶登陸頁,
3，用戶填寫用戶名、密碼，SSO系統進行認證後，將登陸狀態寫入SSO的session，瀏覽器（Browser）中寫入SSO域下的Cookie。
4，SSO系統登陸完成後會生成一個ST（Service Ticket），而後跳轉到app系統，同時將ST做爲參數傳遞給app系統。
5，app系統拿到ST後，從後臺向SSO發送請求，驗證ST是否有效。
6，驗證經過後，app系統將登陸狀態寫入session並設置app域下的Cookie。
至此，跨域單點登陸就完成了。之後咱們再訪問app系統時，app就是登陸的。接下來，咱們再看看訪問app2系統時的流程。

1，用戶訪問app2系統，app2系統沒有登陸，跳轉到SSO。
2，因爲SSO已經登陸了，不須要從新登陸認證。
3，SSO生成ST，瀏覽器跳轉到app2系統，並將ST做爲參數傳遞給app2。
4，app2拿到ST，後臺訪問SSO，驗證ST是否有效。,
5，驗證成功後，app2將登陸狀態寫入session，並在app2域下寫入Cookie。
這樣，app2系統不須要走登陸流程，就已是登陸了。SSO，app和app2在不一樣的域，它們之間的session不共享也是沒問題的。

有的同窗問我，SSO系統登陸後，跳回原業務系統時，帶了個參數ST，業務系統還要拿ST再次訪問SSO進行驗證，以爲這個步驟有點多餘。他想SSO登陸認證經過後，經過回調地址將用戶信息返回給原業務系統，原業務系統直接設置登陸狀態，這樣流程簡單，也完成了登陸，不是很好嗎？

其實這樣問題時很嚴重的，如果我在SSO沒有登陸，而是直接在瀏覽器中敲入回調的地址，並帶上僞造的用戶信息，是否是業務系統也認爲登陸了呢？這是很可怕的。

上面的是這篇文章的重點！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

上面的是這篇文章的重點！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

總結

單點登陸（SSO）的全部流程都介紹完了，原理你們都清楚了。總結一下單點登陸要作的事情：

單點登陸（SSO系統）是保障各業務系統的用戶資源的安全 。
各個業務系統得到的信息是，這個用戶能不能訪問個人資源。
單點登陸，資源都在各個業務系統這邊，不在SSO那一方。 用戶在給SSO服務器提供了用戶名密碼後，做爲業務系統並不知道這件事。 SSO隨便給業務系統一個ST，那麼業務系統是不能肯定這個ST是用戶僞造的，仍是真的有效，因此要拿着這個ST去SSO服務器再問一下，這個用戶給個人ST是否有效，是有效的我才能讓這個用戶訪問。

3、單點登陸優缺點

優勢

1）提升用戶的效率。

用戶再也不被屢次登陸困擾，也不須要記住多個 ID 和密碼。另外，用戶忘記密碼並求助於支持人員的狀況也會減小。

2）提升開發人員的效率。

SSO 爲開發人員提供了一個通用的身份驗證框架。實際上，若是 SSO 機制是獨立的，那麼開發人員就徹底不須要爲身份驗證操心。他們能夠假設，只要對應用程序的請求附帶一個用戶名，身份驗證就已經完成了。

3）簡化管理。

若是應用程序加入了單點登陸協議，管理用戶賬號的負擔就會減輕。簡化的程度取決於應用程序，由於 SSO 只處理身份驗證。因此，應用程序可能仍然須要設置用戶的屬性（好比訪問特權）。

缺點

1）不利於重構

由於涉及到的系統不少，要重構必需要兼容全部的系統，可能很耗時。

2） 無人看守桌面

由於只須要登陸一次，全部的受權的應用系統均可以訪問，可能致使一些很重要的信息泄露。

 

 

原文地址：

https://www.toutiao.com/a6750917667814638091/?timestamp=1572360757&app=news_article_lite&group_id=6750917667814638091&req_id=201910292252360100140481410062922F