《淺談架構之路：單點登陸 SSO》

前言：SSO 單點登陸

　　「半吊子」的全棧工程師又來了，技術類的文章才發表了兩篇，原本想先將主攻的幾個系列都開個頭（Nodejs、Java、前端、架構、全棧等等），無奈博客起步太晚，寫博文的時間又沒有不少，只好不按順序亂髮一通，請你們見諒。

　　本篇文章介紹一下單點登陸，不像上一篇博文介紹的先後端分離，SSO 並不能算是一種架構吧，只能說是一個解決方案。因爲筆者參與過醫院集成平臺項目，負責其中單點登陸的設計研發工做，將經驗總結分享一下，也不必定是最優方案，正確與否那就「仁者見仁智者見智」了。

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

　　文章導讀：開篇先介紹一下筆者從事醫療行業出現單點登陸的項目需求，畢竟是需求驅動研發；再將整理的通用版的單點登陸知識進行分享；接着介紹一下筆者當前採用集成平臺單點登陸方案，最後是一些相關擴展。

單點登陸背景介紹

　　【醫療行業的需求】　　

　　隨着醫院信息化建設的深刻，信息化系統愈來愈多，五花八門多種多樣，初步統計目前醫院信息化子系統數量已經多達幾十個。這些系統的安裝維護不只讓信息中心花費大量心血，也讓多角色的用戶在使用系統時頭疼不已。他們在使用系統前首先要尋找系統圖標，要記住登陸各個系統的用戶與密碼進行登陸驗證。找圖標、記帳戶、記密碼、這些運用步驟已經讓用戶以爲醫院信息化給他們帶來必定的負擔。

        這時候單點登陸就應運而生，他能讓用戶在運用系統時能準確的尋找到他們須要運用的系統圖標，方便他們在安全驗證；只須要記住一個密碼就能夠實現全部有權限運用子系統的登陸驗證；用戶只須要登陸一次就能夠訪問全部相互信任的應用系統，即用戶只須要記住一組用戶名和密碼就能夠登陸全部有權限的系統。

 

　　【企業內部的需求】　　　

　　較大的企業內部，通常都有不少的業務支持系統爲其提供相應的管理和IT服務。這些不一樣的系統每每是在不一樣的時期建設起來的，運行在不一樣的平臺上；也許是由不一樣廠商開發，使用了各類不一樣的技術和標準。爲了下降管理的消耗，最大限度的重用已有投資的系統，不少企業都在進行着企業應用集成（EAI）。企業應用集成能夠在不一樣層面上進行：例如在數據存儲層面 上的「數據大集中」，在傳輸層面上的「通用數據交換平臺」，在應用層面上的「業務流程整合」，和用戶界面上的「通用企業門戶」等等。事實上，還用一個層面 上的集成變得愈來愈重要，那就是「身份認證」的整合，也就是「單點登陸」。

　　一般來講，每一個單獨的系統都會有本身的安全體系和身份認證系統。整合之前，進入每一個系統都須要進行登陸，這樣的局面不只給管理上帶來了很大的困難，在安全方面也埋下了重大的隱患。使用「單點登陸」整合後，只須要登陸一次就能夠進入多個系統，而不須要從新登陸，這不只僅帶來了更好的用戶體驗，更重要的是下降了安全的風險和管理的消耗。

　　另外，使用「單點登陸」仍是SOA時代的需求之一。在面向服務的架構中，服務和服務之間，程序和程序之間的通信大量存在，服務之間的安全認證是SOA應用的難點之一，應此創建「單點登陸」的系統體系可以大大簡化SOA的安全問題，提升服務之間的合做效率。

 

　　【實現機制（整理抽象版）】

       單點登陸的機制實際上是比較簡單的，用一個現實中的例子作比較。頤和園是北京著名的旅遊景點，也是我常去的地方。在頤和園內部有許多獨立的景點，例如「蘇州街」、「佛香閣」和「德和園」，均可以在各個景點門口單獨買票。不少遊客須要遊玩全部德景點，這種買票方式很不方便，須要在每一個景點門口排隊買票，錢包拿 進拿出的，容易丟失，很不安全。因而絕大多數遊客選擇在大門口買一張通票（也叫套票），就能夠玩遍全部的景點而不須要從新再買票。他們只須要在每一個景點門 口出示一下剛纔買的套票就可以被容許進入每一個獨立的景點。

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

 

集成平臺SSO機制詳解

　　【驗證機制】

　　當前筆者採用的集成平臺單點登陸的應用場景和傳統企業信息集成裏面的單點登陸稍有不一樣，這裏引進了三種驗證措施：集成平臺標識&憑證&令牌號，具體以下：

　　一、經過服務總線進行各第三方廠家系統的憑證校驗，確認消息發送方是可信任系統；

　　二、經過有時效性的令牌方式進行單次登陸操做校驗，登陸信息在校驗經過後由集成平臺返回；

　　三、第三方並不須要摒棄自身的登陸功能，由於咱們在單點登陸的時候，經過集成平臺標識來判斷進行的是單點登陸操做，不影響原有業務；

 

　　【用戶一致性】

       實現單點登陸的前提是員工信息一致性，咱們經過員工對照功能保證其信息的一致性。

       關於員工對照使用的惟一信息，對於公司的系統，咱們採用員工內部序號；而對於其餘廠商的外部系統，咱們提供「工做牌號」或者「工做牌號+員工姓名」的組合等方式來識別員工，經過程序去適配。

       經過員工對照後，系統，科室，角色等其餘信息均可以經過接口方式獲取，不須要和第三方進行任何對照和關聯。在實現員工對照後，其餘廠商的系統便可像公司系統那樣，按咱們的接口文檔改造後，順利接入集成平臺。

 

　　【界面展現】

　　集成平臺的SSO集成在統一工做門戶上，做爲一個組件展現，醫護人員只須要登陸門戶，就能夠方便的進入全部平常須要使用到的醫療系統。

 

　　【實現機制與流程】

　　集成平臺單點登陸的應用場景和傳統企業信息集成裏面的單點登陸稍有不一樣，平臺和第三方系統的對接都是經過WS方式完成，而不是由平臺直接操做子系統數據庫完成；採用消息中間件的總線方式進行接口管理與操做，加強了數據準確性和流程可控性；同時引進了憑證號，令牌號和集成平臺標識這三種驗證機制，充分保證了系統的安全性。

　　單點登陸流程： 

　　1）用戶登陸門戶，門戶程序會經過服務總線遍歷不一樣廠商的接口，採集該員工在不一樣子系統擁有的權限，並在SSO組件框中顯示子系統列表。

　　2）用戶若須要進入某系統，則點擊相應圖標，選擇登陸科室和角色等信息（經過接口獲取），此時會在平臺這邊生成令牌，同時在本地打開相應業務系統，並傳遞令牌號和集成平臺標識。

　　3）該業務系統識別集成平臺標識後，使用令牌來調用平臺的令牌驗證接口，若是驗證成功則利用返回的信息進行登陸，錯誤則給予提示。

　　PS：上面說的流程是程序實現流程，醫護人員使用流程僅僅是登陸門戶，單擊系統直接進入便可，just so so。

　　關於流程，筆者畫了一張簡圖表示，有點粗糙，湊活着看。

　　

 

擴展：爲什麼採用這種實現方式？

　　爲何不採用目前流行的Active Directory或者CAS方式實現單點登陸？

　　關於這點，主要出於下面兩點考慮：

        a）鑑於醫院集成平臺單點登陸的特殊性（同時要對接BS和CS系統），純web的cookie和session以及CAS等方式不適用。

        b）集成平臺SSO建設在服務總線基礎之上，藉助消息中間件，進行全部第三方系統的接口管理，使用令牌和憑證來保證對接及時安全性，同時經過員工主索引的也實現了醫院員工統一管理和惟一性確認，在集成平臺這樣的大背景下，咱們爲什麼還要選擇須要額外用戶權限配置的Active Directory方式呢？

擴展：統一受權機制

　　嗯，這裏爲何忽然提到統一受權，這邊不是單點登陸專題嗎？

　　其實，在實現了單點登陸解決方案後，特別是在保證員工一致性、和不一樣第三方之間系統交互模式建設後，爲統一受權也提供了實現方案。

　　簡單介紹一下統一受權的背景：因爲全院信息化產品很是豐富，每一個獨立廠商產品都有獨立的系統受權方式。沒法給員工統一受權讓客戶的管理工做人員十分苦惱。若是咱們能夠將第三方和本公司的產品全部權限都收集到集成平臺中進行統一受權，那將大大增長了咱們全院信息化的統一性，同時大幅減輕咱們客戶管理人員的工做壓力。

　　受權內容：受權登陸科室，受權使用系統，受權使用系統菜單，受權報表權限，受權一些特定業務權限。

　　所以，單點登陸系統同時集成了統一受權的功能，爲不一樣系統提供代理受權功能，能夠直接在單點登陸上爲不一樣系統進行角色員工權限分發等工做。

　　PS：整合了統一受權後，單點登陸有了高大上的新名字，「統一登陸平臺」，囧。。。

　　PS_2：因爲這不是統一受權專場，這邊不過多介紹，有時間會再開相應博文。

編後語

      單點登陸介紹差很少了，每一個人對單點登陸的理解和實現都各不相同，正所謂：「橫當作嶺側成峯，遠近高低各不一樣」。

　　咱們不用去在乎這些，拋開實現，其實最重要的仍是掌握單點登陸的這種思路，並用來解決實際生產生活中的適用的問題。