[AWS] SSO: Single sign-on

由單點登陸到aws的http服務。

 

---

 

From: https://www.jianshu.com/p/613e44d4a464

單點登陸SSO（Single Sign On）說得簡單點就是在一個多系統共存的環境下，用戶在一處登陸後，就不用在其餘系統中登陸，也就是用戶的一次登陸能獲得其餘全部系統的信任。

單點登陸在大型網站裏使用得很是頻繁，例如像阿里巴巴這樣的網站，在網站的背後是成百上千的子系統，用戶一次操做或交易可能涉及到幾十個子系統的協做，若是每一個子系統都須要用戶認證，不只用戶會瘋掉，各子系統也會爲這種重複認證受權的邏輯搞瘋掉。

實現單點登陸說到底就是要解決如何產生和存儲那個信任，再就是其餘系統如何驗證這個信任的有效性，所以要點也就如下兩個：

• 存儲信任
• 驗證信任

 

以Cookie做爲憑證媒介【安全有風險】

最簡單的單點登陸實現方式，是使用cookie做爲媒介，存放用戶憑證。
用戶登陸父應用以後，應用返回一個加密的cookie，當用戶訪問子應用的時候，攜帶上這個cookie，受權應用解密cookie並進行校驗，校驗經過則登陸當前用戶。

 

經過JSONP實現【有安全風險】

對於跨域問題，可使用JSONP實現。

 

經過頁面重定向的方式

最後一種介紹的方式，是經過父應用和子應用來回重定向中進行通訊，實現信息的安全傳遞。
父應用提供一個GET方式的登陸接口，

用戶經過子應用重定向鏈接的方式訪問這個接口，

 * 若是用戶尚未登陸，則返回一個的登陸頁面，用戶輸入帳號密碼進行登陸。

 * 若是用戶已經登陸了，則生成加密的Token，而且重定向到子應用提供的驗證Token的接口，經過解密和校驗以後，子應用登陸當前用戶。

Figure 01, Auth via redirect

這種方式較前面兩種方式，接解決了上面兩種方法暴露出來的安全性問題和跨域的問題，可是並無前面兩種方式方便。
安全與方便，原本就是一對矛盾。

 

隨之而來的問題

 

上圖中Figure 01, 我拿什麼來做爲重定向的請求？

 

 

 

 

單點登陸系統(SSO)-總結

利用公司現有的SSO服務器來配置客戶端開發用戶登陸接口從而和別的公司對接。

 

SSO服務器的處理大體流程就是：

 

用戶在A客戶端登陸---->

SSO服務器驗證用戶信息---->

 

驗證成功後在SSO服務器端會記下一個 TGC(Ticket Granted Cookie)票據 ，並且返回到A客戶端時還帶有一個 ticket參數 (它是惟一，不可僞造的參數),

在A客戶端拿到 Service 和新產生的 Ticket 事後，與 SSO服務器進行身份覈實，以確保 Service和Ticket 的合法性---->

 

退出登錄時,會向SSO服務器發送logout請求（清除Session），以後SSO服務器會廣播到其餘應用服務器的logout（清除Session）。

 

 

下面拿我作過的案例來講：

例如原始應用的網址是http://localhost:8080/cas-client/，在這個客戶端登陸頁面裏form表單包含登陸用戶名和密碼，一開始有以下語句，轉向CAS服務器的單點登陸頁面 https://sso.nubb.com/login?service=http://localhost:8080/cas-client/。

SSO服務器完成主體認證後，會使用下面URL進行重定向 http://localhost:8080/cas-client/?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。 收到ticket以後，應用程序須要驗證ticket。這是經過將ticket 傳遞給一個校驗URL來實現的。校驗URL也是SSO服務器提供的。

SSO服務器經過校驗路徑得到了ticket以後，經過內部的數據庫對其進行判斷。若是判斷是有效性，則返回一個NetID給應用程序。 隨後CAS將ticket做廢，而且在客戶端留下一個cookie。

之後其餘應用程序就使用這個cookie進行認證（固然經過CAS的客戶端），而再也不須要輸入用戶名和密碼。 

 

 

 

SSO單點登陸三種狀況的實現方式詳解

相見原文

 

---

 

本文涉及到：http服務負載均衡等任務，例如經過Nginx [ Nginx is a web server which can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache.]

如何利用aws將網站各個功能作成微服務的形式，這是往後的重點。