淺談架構之路：單點登錄 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機制詳解
【驗證機制】當前筆者采用的集成平臺單點登錄的應用場景和傳統企業信息集成裏面的單點登錄稍有不同，這裏引進了三種驗證措施：集成平臺標識&憑證&令牌號，具體如下：
1、通過服務總線進行各第三方廠家系統的憑證校驗，確認消息發送方是可信任系統；
2、通過有時效性的令牌方式進行單次登錄操作校驗，登錄信息在校驗通過後由集成平臺返回；
3、第三方並不需要摒棄自身的登錄功能，因為我們在單點登錄的時候，通過集成平臺標識來判斷進行的是單點登錄操作，不影響原有業務；
【用戶一致性】實現單點登錄的前提是員工信息一致性，我們通過員工對照功能保證其信息的一致性。
關於員工對照使用的唯一信息，對於公司的系統，我們采用員工內部序號；而對於其他廠商的外部系統，我們提供“工作牌號”或者“工作牌號+員工姓名”的組合等方式來識別員工，通過程序去適配。
通過員工對照後，系統，科室，角色等其他信息都可以通過接口方式獲取，不需要和第三方進行任何對照和關聯。在實現員工對照後，其他廠商的系統即可像公司系統那樣，按我們的接口文檔改造後，順利接入集成平臺。
【界面展示】集成平臺的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：由於這不是統一授權專場，這邊不過多介紹，有時間會再開相應博文。
編後語
單點登錄介紹差不多了，每個人對單點登錄的理解和實現都各不相同，正所謂：“橫看成嶺側成峰，遠近高低各不同”。
我們不用去在意這些，拋開實現，其實最重要的還是掌握單點登錄的這種思路，並用來解決實際生產生活中的適用的問題。
淺談架構之路：單點登錄 SSO