一個安全的信息系統,合法身份檢查是必須環節。尤爲IM這種以「人」爲中心的社交體系,身份認證更是必不可少。php
一些PC時代小型IM系統中,身份認證可能直接作到長鏈接中(也就是整個IM系統都是以長鏈接爲中心:身份鑑權、數據收發、文件傳送等等)。但當前主流的IM(尤爲新一代的移動端IM)中,都是「長」(指TCP或UDP長鏈接)、「短」(是指Http短鏈接)相結合的方式。html
一個現代的移動端IM「長」、「短」鏈接配合內容大體以下:算法
1)短鏈接用途1:前置HTTP的SSO單點接口來實現身份認證;安全
2)短鏈接用途2:集羣式的IM中可能還會有獨立(或集成於SSO單獨登錄接口中)的SLB接口(即基於HTTP短鏈接拉取IM服務器集羣IP列表);服務器
3)短鏈接用途3:各類小文件的上傳、下載接口實現(頭像、圖片、語音、文件等)都會是基於Http實現;微信
4)長鏈接用途1:用戶的實時上、下線狀態通知;網絡
5)長鏈接用途2:實時的加友、加羣等指令收發;架構
6)長鏈接用途3:服務端發起的其它實時指令推送等。負載均衡
總之:當今主流的移動IM系統中,「長」、「短」鏈接分工明確,各自將自身的優點發揮到最大化,優勢是:系統分工明確、分層清晰、業務劃分合理、負載方案成本低、符合移動網絡的特性等。分佈式
針對上述主流移動IM系統中「長」、「短」鏈接的分工方式,其中最爲重要也是用戶最早接觸到的——就是基於Http的SSO單點登錄接口(有的系統裏可能並不叫SSO接口,本文討論的是其廣義:即實現身份認證功能的http接口),那麼這個SSO接口工做原理是什麼?能夠怎麼來實現?有無最佳實踐建議?
OK,帶着上述的這幾個疑問,讓咱們開啓本文的正文部分。
正文內容說明:正文部分介紹SSO單點登錄接口時,是以通用信息系統的角度來闡述原理、邏輯、最佳實踐,而非專門針對IM系統,但道理是如出一轍的,理解原理後徹底能夠設計出適合您IM系統的SSO接口。(話外音:實際上是懶的從新打字和畫圖 ^_^)。
學習交流:
- 即時通信開發交流羣:320837163 [推薦]
- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM》
(本文同步發佈於:http://www.52im.net/thread-1351-1-1.html)
▼ 帶着本文對SSO單點登錄(或者說身份認證)接口的知識,您將能更好的讀懂下述技術文章:
總之,以上幾篇精選的文章能夠跟本文的知識相輔相成,共同完善您的IM技術開發知識體系,但願對你有用。
▼ IM開發乾貨系列文章也適合做爲IM開發的系統性入門資料(本文是其第10篇):
《IM消息送達保證機制實現(一):保證在線實時消息的可靠投遞》
若是您正在查閱更多移動端IM開發資料,強烈推薦閱讀《新手入門一篇就夠:從零開發移動端IM》。
楊麗:擁有多年互聯網應用系統研發經驗,曾就任於古大集團,現任職中青易遊的系統架構師,主要負責公司研發中心業務系統的架構設計以及新技術積累和培訓。現階段主要關注開源軟件、軟件架構、微服務以及大數據。
張輝清:10 多年的 IT 老兵,前後擔任攜程架構師、古大集團首席架構、中青易遊 CTO 等職務,主導過兩家公司的技術架構升級改造工做。現關注架構與工程效率,技術與業務的匹配與融合,技術價值與創新。
假設一個場景:公司內部有財務、OA、訂單服務等各種相互獨立的應用系統,員工張三對這些系統有操做權限,若是張三想要登陸某個系統進行業務操做,那麼他須要輸入相應的帳號與密碼。
想象一下:當公司內部有 100 個應用系統,張三是否是要輸入 100 次用戶名和密碼進行登陸,而後分別才能進行業務操做呢?顯然這是很很差的體驗。
所以咱們須要引入一個這樣的機制:張三隻要輸入一次用戶名和密碼登陸,成功登陸後,他就能夠訪問財務系統、OA 系統、訂單服務等系統——這就是單點登陸。
單點登陸的英文全稱是 Single Sign On,簡稱是 SSO:
它的意思是說用戶只須要登陸一次,就能夠在我的權限範圍內,訪問全部相互信任應用的功能模塊,無論整個應用羣的內部有多麼複雜,對用戶而言,都是一個統一的總體。用戶訪問 Web 系統的整個應用羣與訪問單個系統同樣,登陸和註銷分別只要一次就夠了。
舉個簡單的例子,你登陸了百度網頁以後,點擊跳轉到百度貼吧,這時能夠發現你已經自動登陸了百度貼吧——這就是單獨登錄的原理。
針對本文上半部分的原理介紹,咱們以一個真實的信息系統爲例,理論聯繫實際來說解具體的SSO單點登錄技術實現(實際上,用IM系統的設計思路來看這個例子,可能有點複雜,但知識是相通的,它更有助於對SSO完整知識體系的理解。)
SSO 的技術實現要想作好並不容易,做者認爲需求優先級應該先是單點登陸和單點註銷功能,而後是應用接入的門檻,最後是數據安全性,安全性對於 SSO 也很是重要。SSO 的核心是認證中心,但要實現用戶一次登陸,處處訪問的效果,技術實現須要創建在用戶系統、認證中心、權限系統、企業門戶的基礎上。
各職責以下:
用戶系統:負責用戶名、密碼等賬戶信息管理,包括增長、修改、啓用、停用用戶賬號,同時爲認證中心提供對用戶名和密碼的校驗;
認證中心:負責憑證 token 的生成、加密、頒發、驗證、銷燬、登入 Login、登出 Logout。用戶只有擁有憑證並驗證經過才能訪問企業門戶;
權限系統:負責角色管理、資源設置、受權設置、鑑定權限,具體實現可參考 RBAC。權限系統可爲企業門戶提供用戶權限範圍內的導航;
企業門戶:做爲應用系統的集成門戶 (Portal),集成了多個應用系統的功能,爲用戶提供連接導航、用戶信息和登出功能等。
主要包含如下內容:
登陸認證:接收登陸賬號信息,讓用戶系統驗證用戶的登陸信息;
憑證生成:建立受權憑證 token,生成的憑證通常包含用戶賬號信息、過時時間等信息,它是一串加密的字符串,加密算法如 AES{憑證實文 +MD5 加信息},可採用 JWT 標準;
憑證頒發:與 SSO 客戶端通訊,發送憑證給 SSO 客戶端;
憑證驗證:接收並校驗來自 SSO 客戶端的憑證有效性,憑證驗證包括算法驗證和數據驗證;
憑證銷燬與登出:接收來自 SSO 客戶端的登出請求,記錄並銷燬憑證,跳轉至登陸頁面。
客戶端的實現邏輯大體以下:
1)請求攔截:攔截應用未登陸請求,跳轉至登陸頁面;
2)獲取憑證:接收並存儲由 SSO 服務端發來的憑證,憑證存儲的方式有 Cookie、Session、網址傳參、Header 等;
3)提交憑證驗證:與 SSO 服務端通訊,發出校驗憑證有效性的請求;
4)獲取用戶權限:獲取該憑證的用戶權限,並返回受保護資源給用戶;
5)憑證銷燬與登出:銷燬本地會話,而後跳轉至登出頁面。
用戶的單點登陸流程以下:
1)登陸:將用戶輸入的用戶名和密碼發送至認證中心,而後認證中心調用用戶系統來驗證登陸信息;
2)生成並頒發憑證:經過登陸信息的驗證後,認證中心建立受權憑證 token,而後把這個受權憑證 token 返回給 SSO 客戶端。SSO 客戶端拿到這個 token,進行存儲。在後續請求中,在 HTTP 請求數據中都得加上這個 token;
3)憑證驗證:SSO 客戶端發送憑證 token 給認證中心,認證中心校驗這個 token 的有效性。憑證驗證有算法驗證和數據驗證,算法驗證可在 SSO 客戶端完成。
以上是用戶的訪問流程,若是用戶沒有有效的憑證,認證中心將強制用戶進入登陸流程。對於單點註銷,用戶若是註銷了應用羣內的其中一個應用,那麼全局 token 也會被銷燬,應用羣內的全部應用將不能再被訪問。
例子中的應用接入與集成具體以下:
1)用戶系統:接入國內機票平臺的用戶系統,負責登陸認證;
2)權限系統:接入國內機票平臺的權限系統;
3)認證中心:負責生成並頒發憑證、銷燬憑證,改造國內機票平臺的登入、登出;
4)憑證驗證:在國內機票、國際機票應用系統中調用 SSO 客戶端組件實現憑證的驗證;
5)企業門戶:由國內機票平臺、國際機票平臺承擔。
JSON Web Token (JWT) 是目前應用最爲普遍的 token 格式,是爲了在網絡應用環境間傳遞聲明而執行的一種基於 JSON 的開放標準(RFC 7519)。該 token 設計緊湊且安全,特別適用於分佈式站點的單點登陸、API 網關等場景。
JWT 的聲明通常被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息,以便於從資源服務器獲取資源,也能夠增長一些額外的其它業務邏輯所必須的聲明信息。該 token 也可直接被用於認證,也可被加密。JWT 信息體由 3 部分構成:頭 Header+ 載荷 Payload+ 簽名 Signature。
JWT具體優勢以下:
JWT 支持多種語言,C#、Java、JavaScript、Node.js、PHP 等不少語言均可以使用;
JWT 能夠自身存儲一些和業務邏輯有關的所必要的非敏感信息,由於有了 Payload 部分;
利於傳輸,由於 JWT 的構成很是簡單,字節佔用很小;
不須要在服務端保存會話信息,不只省去服務端資源開銷,並且使得應用易於擴展。
(本文同步發佈於:http://www.52im.net/thread-1351-1-1.html)
[1] 有關IM架構設計:
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
>> 更多同類文章 ……
[2] 有關IM安全的文章:
《即時通信安全篇(一):正確地理解和使用Android端加密算法》
《即時通信安全篇(四):實例分析Android中密鑰硬編碼的風險》
《即時通信安全篇(五):對稱加密技術在Android平臺上的應用實踐》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯繫實際:一套典型的IM通訊協議設計詳解(含安全層設計)》
《微信新一代通訊安全解決方案:基於TLS1.3的MMTLS詳解》
《來自阿里OpenIM:打造安全可靠即時通信服務的技術實踐分享》
《Web端即時通信安全:跨站點WebSocket劫持漏洞詳解(含示例代碼)》
>> 更多同類文章 ……
[3] IM開發綜合文章:
《IM消息送達保證機制實現(一):保證在線實時消息的可靠投遞》
《開源IM工程「蘑菇街TeamTalk」的現狀:一場虎頭蛇尾的開源秀》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)》
《騰訊原創分享(一):如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(上篇)》
《騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(下篇)》
《如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《基於社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的?》
>> 更多同類文章 ……
(本文同步發佈於:http://www.52im.net/thread-1351-1-1.html)