單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業(yè)業(yè)務整合的解決方案之一。SSO的定義是在多個應用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統(tǒng)。

SSO在大型網站里使用得非常頻繁，例如像阿里巴巴這樣的網站，在網站的背后是成百上千的子系統(tǒng)，用戶一次操作或交易可能涉及到幾十個子系統(tǒng)的協(xié)作，如果每個子系統(tǒng)都需要用戶認證，不僅用戶會瘋掉，各子系統(tǒng)也會為這種重復認證的邏輯搞瘋掉。

實現單點登錄說到底就是要解決如何產生和存儲信任，再就是其他系統(tǒng)如何驗證這個信任的有效性，單點登錄有不同的實現方式，本次，我們將一起解讀一下目前業(yè)界常見的幾種單點登錄的實現技術。

表單代填

表單代填單點登錄，是基于表單的單點登錄功能。由IAM系統(tǒng)模擬已認證的用戶，將已認證的用戶的用戶名和密碼，通過程序自動輸入應用系統(tǒng)的登錄表單中，并自動提交，完成應用系統(tǒng)的登錄。

表單代填單點登錄的原理如下：

說明：

1、 用戶登錄IAM系統(tǒng)。

2、 用戶在IAM系統(tǒng)中點擊應用系統(tǒng)圖標，IAM系統(tǒng)模擬用戶自動幫助用戶完成應用系統(tǒng)的用戶名/密碼的輸入并提交。

3、 業(yè)務系統(tǒng)完成用戶名密碼的校驗，完成登錄。

基于Cookie

基于共享同域的Cookie是Web剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞Cookie機制，實現兩個域名之間系統(tǒng)令牌傳遞問題

基于Cookie的單點登錄的實現原理如下：

說明：

1、 用戶輸入用戶名/密碼（para/password）登錄到。

2、 處理登錄邏輯，并且將用戶信息通過cookie的方式返回到客戶端（加密用戶信息）。

3、 用戶訪問mail.paraview.cn，瀏覽器自動將用戶信息攜帶到mail.paraview.cn，通過過濾器（filter）處理用戶的登錄請求。

4、 過濾器從cookie中獲取用戶信息，登錄，返回用戶訪問界面。這樣用戶就只登錄一次，就訪問了兩個網站了。

LTPA

LTPA（Lightweight Third-Party Authentication）是IBM的技術標準，在IBM Websphere和Domino等系列產品中使用到該單點登錄技術。

LTPA單點登錄方式，其實也是基于Cookie的實現方式，在用戶登錄成功后，系統(tǒng)會生成LTPA的cookie，該Cookie的名稱為LtpaToken及LtpaToken2，利用該Ltpa Cookie，可實現在系統(tǒng)間的單點登錄。

一個有效的LTPA Cookie能夠在同一個認證域中所有服務器被自動認證。此Cookie中包含認證信息和時間戳。這些信息通過共享的3DES Key進行了加密。使用公共密鑰/私有密鑰進行簽名。

LTPA單點登錄的機制與基于Cookie的單點登錄方式的機制及過程一致，在此就不再重復說明。

SAML

SAML（Security Assertion Markup Language，安全斷言標記語言）是一個基于XML的開源標準數據格式，它在當事方之間交換身份驗證和數據，尤其是在身份提供者和服務提供者之間交換。

SAML是OASIS安全服務技術委員會的一個產品，始于2001年。其最近的主要更新發(fā)布于2005年，但協(xié)議的增強仍在通過附加的可選標準穩(wěn)步增加。

SAML協(xié)議單點登錄過程如下圖：

說明：

1、 用戶訪問應用（SP）。

2、 應用（SP）檢測用戶未認證，將用戶重定向到IDP進行認證。

3、 用戶在IAM（IDP）完成認證，IAM（IDP）生成SAML Token，并將用戶重定向到應用（SP）。

4、 應用（SP）得到SAML Token并解析，得到用戶身份后，幫助用戶完成登錄，從而實現單點登錄。

WS-Federation

WS-Federation屬于Web Services Security 的一部分，是由OASIS發(fā)布的標準協(xié)議，其主要貢獻者是Microsoft 和 IBM。

WS-Federation 1.1 版本發(fā)布于2003年, 的1.2版本標準發(fā)布于2009年。該協(xié)議主要應用在企業(yè)服務，并且是在微軟自己的產品中主推，其他廠家的產品可能更愿意選擇SAML。另外，該標準是基于SOAP的，整個協(xié)議雖然功能強大，細節(jié)考慮周全，但實現起來會比較重，只有為了能和微軟的服務整合，才會優(yōu)先考慮該協(xié)議。

WS-Federation單點登錄的機制與SAML的單點登錄機制基本一致，在此也不再過多說明，具體可參考SAML的單點登錄過程。

CAS

CAS是Central Authentication Service的縮寫，認證服務，一種獨立開放指令協(xié)議。

CAS 是 Yale 大學發(fā)起的一個開源項目，旨在為 Web 應用系統(tǒng)提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。

CAS協(xié)議單點登錄過程如下圖：

CAS實現說明：

1、 訪問服務： SSO 客戶端發(fā)送請求訪問應用系統(tǒng)提供的服務資源。

2、 定向認證： SSO 客戶端會重定向用戶請求到 SSO 服務器。

3、 用戶認證：用戶身份認證。

4、 發(fā)放票據： SSO 服務器會產生一個隨機的 Service Ticket 。

5、 驗證票據： SSO 服務器驗證票據 Service Ticket 的合法性，驗證通過后，允許客戶端訪問服務。

6、 傳輸用戶信息： SSO 服務器驗證票據通過后，傳輸用戶認證結果信息給客戶端。

OAuth

OAUTH（Open Authorization）協(xié)議為用戶資源的提供了一個安全的、開放而又簡易的標準。OAUTH的不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的，因此OAUTH是安全的。

OAuth的實現如案例如下圖：

說明：

1、 用戶訪問業(yè)務系統(tǒng)。

2、 業(yè)務系統(tǒng)判斷用戶沒有登錄，把用戶重定向到IAM進行認證。

3、 用戶在IAM系統(tǒng)中完成登錄認證，IAM為用戶的此次請求創(chuàng)建OAuth code，并帶OAuth code返回應用回調地址。

4、 應用獲取OAuth code并請求校驗，獲取Access Token。

5、 應用通過Access Token調用用戶接口獲取用戶信息。

6、 應用得到用戶身份，完成用戶登錄。

OpenID Connect（OIDC）

OpenID Connect是OpenID和Oauth2的合集。除了遵循Oauth2的規(guī)范外還要返回ID_Token來驗證身份。

ID_Token是符合JWT格式的數據，包含用戶身份認證的信息，一般在只需要實現單點登錄的情況下，只需要得到ID_Token即可。

ID_Token取得信息一般是不夠的，所以一般還會用Access Token去取用戶相關的profile信息。

OpenID Connect的實現原理與OAuth2.0基本一致，具體如下：

說明：

1、 用戶訪問業(yè)務系統(tǒng)。

2、 業(yè)務系統(tǒng)判斷用戶沒有登錄，把用戶重定向到IAM進行認證。

3、 用戶在IAM系統(tǒng)中完成登錄認證，IAM為用戶的此次請求創(chuàng)建碼，并帶碼返回應用回調地址。

4、 應用獲取碼并請求校驗，獲取ID Token及Access Token。

5、 應用通過得到ID Token及Access Token，通過Access Token調用用戶接口獲取用戶信息（一般在只需要實現單點登錄的業(yè)務場景下下，只需要得到ID_Token即可，不需要Access Token獲取用戶的profile）。

6、 應用得到用戶身份，完成用戶登錄。