手撕公司SSO登陸原理
- 2019 年 11 月 7 日
- 筆記
Single Sign-on
SSO是老生常談的話題了，但部分同學對SSO可能掌握的也是雲里霧裡，一知半解。本次手撕公司的SSO原理，試圖以一種簡單，流暢的形式為你提供有用的SSO原理。
按照本人一貫行文風格，我們先說什麼是SSO，為什麼要提出SSO？
SSO： 在多個系統中，只需要登陸一次，就可以訪問其他相互信任的應用系統， 這個技術的提出解決了：
-
企業運行了多個服務，而帳號需要集中統一管理
-
終端用戶登陸一次，即可使用一個賬戶享受所有不同域名下服務。
SSO 與CAS（Central Authentication System）這個概念密切相關，賬戶集中由某個服務管理，SSO服務只負責登陸認證。
登陸認證與【服務端在瀏覽器上寫入的認證Cookie】密切相關， Cookie 有一系列重要屬性：Domain，Path， Expiration，HttpOnly 決定了該Cookie 在客戶端的作用域、作用範圍、有效時間、有效操作方式
原理
用戶首次訪問 website1
① 用戶訪問website1 系統，website1系統需要認證， 用戶當前沒有登陸
② website1給客戶端返回302重定向響應， 客戶端重定向到SSO服務頁
# 交互過程確實是臨時跳轉，下面傳參false， 返回302臨時重定向響應
context.Response.Redirect(ssoURL, false);
用戶並沒有登陸SSO系統，所以SSO系統會返回登陸介面
③ 用戶在SSO登陸介面輸出賬戶/密碼
④ 登陸成功，SSO會在客戶端寫入一個 cookie for sso併產生一個301重定向響應，客戶端將重定向到原website1地址，該請求附帶了SSO給與這次認證成功的 ticket
http://www.website1.com?ticket=XXXX-OOOO-XXXX-OOOO
⑤ website1收到以上重定向請求，解析QueryString中的ticket， 向SSO做一次ticket驗證； 驗證通過向客戶端寫入本站的 cookie for website
⑥ 上面第5步，瀏覽器地址會顯示：http://www.website1.com?ticket=XXXX-OOOO-XXXX-OOOO， 在本站驗證通過之後，最好再做一個重定向，返回業務首頁：www.website1.com， 本步驟不是SSO登陸的標準流程。
之後用戶訪問website2
① 用戶訪問website2， 用戶在website2並沒得到認證；跳轉回 SSO
② SSO服務檢測到該 用戶在SSO域下存在Cookie for sso， 認定該用戶已經登陸，故跳轉回website2， 如上也會攜帶認證ticket
③ 如上，website2收到 website2.com?ticket=XXXX-OOOO-XXXX-OOOO請求， 會做一次SSO驗證； 驗證成功，寫入本站cookie for website2
重難點解釋
① SSO認證成功，寫入的cookie for sso， 是登陸到其他系統的關鍵
② website1收到SSO認證成功的重定向請求，解析出 ticket=XXXX-OOOO-XXXX-OOOO， 為什麼還要做一次SSO驗證？
因為website1收到的來自SSO的重定向請求地址，有可能是偽造， 所以在website1中需要去SSO驗證一次。
③ 標準的CAS登陸流程有兩次302客戶端重定向， 分別由原站點website1和SSO啟動。
理論上 整個流程由服務端重定向也是可以的 ？？ 看官若發現有漏洞，可在評論區回復。
④ 退出SSO登陸， 要做兩件事情：
– 向SSO發起api請求，請求SSO刪除用戶在SSO域下的認證cookie for sso
– 移除本站的cookie for website1
⑤ 每個website，至少需要如下sso配置
"SsoOptions": { "BaseAddress": "https://sso-cas.sso.com", // 基地址 "LoginPath": "/login", // sso登陸地址 "LogoutPath": "/api/logout", // 退出sso登陸的api地址 "ValidateTGTPath": "/api/validate", // 驗證ticket的api地址 "UserInfoPath": "/api/v2/userinfo" // 從sso拿到登陸用戶資訊的api地址 },
That’ all，這是自己對SSO登陸的一些理解， 本圖文希望以流暢的思路記錄SSO流程， 各位看官不要吃快餐，知其然更知其所以然很關鍵。
