技術(shù)干貨 | 常見(jiàn)單點(diǎn)登錄技術(shù)解讀

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

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

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

表單代填

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

表單代填單點(diǎn)登錄的原理如下：

說(shuō)明：

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

2、 用戶在IAM系統(tǒng)中點(diǎn)擊應(yīng)用系統(tǒng)圖標(biāo)，IAM系統(tǒng)模擬用戶自動(dòng)幫助用戶完成應(yīng)用系統(tǒng)的用戶名/密碼的輸入并提交。

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

基于Cookie

基于共享同域的Cookie是Web剛開(kāi)始階段時(shí)使用的一種方式，它利用瀏覽同域名之間自動(dòng)傳遞Cookie機(jī)制，實(shí)現(xiàn)兩個(gè)域名之間系統(tǒng)令牌傳遞問(wèn)題

基于Cookie的單點(diǎn)登錄的實(shí)現(xiàn)原理如下：

說(shuō)明：

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

2、 lifelimescreening.com處理登錄邏輯，并且將用戶信息通過(guò)cookie的方式返回到客戶端（最好加密用戶信息）。

3、 用戶訪問(wèn)mail.paraview.cn，瀏覽器自動(dòng)將用戶信息攜帶到mail.paraview.cn，通過(guò)過(guò)濾器（filter）處理用戶的登錄請(qǐng)求。

4、 過(guò)濾器從cookie中獲取用戶信息，登錄，返回用戶訪問(wèn)界面。這樣用戶就只登錄一次，就訪問(wèn)了兩個(gè)網(wǎng)站了。

LTPA

LTPA（Lightweight Third-Party Authentication）是IBM的技術(shù)標(biāo)準(zhǔn)，在IBM Websphere和Domino等系列產(chǎn)品中使用到該單點(diǎn)登錄技術(shù)。

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

一個(gè)有效的LTPA Cookie能夠在同一個(gè)認(rèn)證域中所有服務(wù)器被自動(dòng)認(rèn)證。此Cookie中包含認(rèn)證信息和時(shí)間戳。這些信息通過(guò)共享的3DES Key進(jìn)行了加密。使用公共密鑰/私有密鑰進(jìn)行簽名。

LTPA單點(diǎn)登錄的機(jī)制與基于Cookie的單點(diǎn)登錄方式的機(jī)制及過(guò)程一致，在此就不再重復(fù)說(shuō)明。

SAML

SAML（Security Assertion Markup Language，安全斷言標(biāo)記語(yǔ)言）是一個(gè)基于XML的開(kāi)源標(biāo)準(zhǔn)數(shù)據(jù)格式，它在當(dāng)事方之間交換身份驗(yàn)證和授權(quán)數(shù)據(jù)，尤其是在身份提供者和服務(wù)提供者之間交換。

SAML是OASIS安全服務(wù)技術(shù)委員會(huì)的一個(gè)產(chǎn)品，始于2001年。其最近的主要更新發(fā)布于2005年，但協(xié)議的增強(qiáng)仍在通過(guò)附加的可選標(biāo)準(zhǔn)穩(wěn)步增加。

SAML協(xié)議單點(diǎn)登錄過(guò)程如下圖：

說(shuō)明：

1、 用戶訪問(wèn)應(yīng)用（SP）。

2、 應(yīng)用（SP）檢測(cè)用戶未認(rèn)證，將用戶重定向到IDP進(jìn)行認(rèn)證。

3、 用戶在IAM（IDP）完成認(rèn)證，IAM（IDP）生成SAML Token，并將用戶重定向到應(yīng)用（SP）。

4、 應(yīng)用（SP）得到SAML Token并解析，得到用戶身份后，幫助用戶完成登錄，從而實(shí)現(xiàn)單點(diǎn)登錄。

WS-Federation

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

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

WS-Federation單點(diǎn)登錄的機(jī)制與SAML的單點(diǎn)登錄機(jī)制基本一致，在此也不再過(guò)多說(shuō)明，具體可參考SAML的單點(diǎn)登錄過(guò)程。

CAS

CAS是Central Authentication Service的縮寫，中央認(rèn)證服務(wù)，一種獨(dú)立開(kāi)放指令協(xié)議。

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

CAS協(xié)議單點(diǎn)登錄過(guò)程如下圖：

CAS實(shí)現(xiàn)說(shuō)明：

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

2、 定向認(rèn)證： SSO 客戶端會(huì)重定向用戶請(qǐng)求到 SSO 服務(wù)器。

3、 用戶認(rèn)證：用戶身份認(rèn)證。

4、 發(fā)放票據(jù)： SSO 服務(wù)器會(huì)產(chǎn)生一個(gè)隨機(jī)的 Service Ticket 。

5、 驗(yàn)證票據(jù)： SSO 服務(wù)器驗(yàn)證票據(jù) Service Ticket 的合法性，驗(yàn)證通過(guò)后，允許客戶端訪問(wèn)服務(wù)。

6、 傳輸用戶信息： SSO 服務(wù)器驗(yàn)證票據(jù)通過(guò)后，傳輸用戶認(rèn)證結(jié)果信息給客戶端。

OAuth

OAUTH（Open Authorization）協(xié)議為用戶資源的授權(quán)提供了一個(gè)安全的、開(kāi)放而又簡(jiǎn)易的標(biāo)準(zhǔn)。OAUTH的授權(quán)不會(huì)使第三方觸及到用戶的帳號(hào)信息（如用戶名與密碼），即第三方無(wú)需使用用戶的用戶名與密碼就可以申請(qǐng)獲得該用戶資源的授權(quán)，因此OAUTH是安全的。

OAuth的實(shí)現(xiàn)如案例如下圖：

說(shuō)明：

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

2、 業(yè)務(wù)系統(tǒng)判斷用戶沒(méi)有登錄，把用戶重定向到IAM進(jìn)行認(rèn)證。

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

4、 應(yīng)用獲取OAuth code并請(qǐng)求校驗(yàn)，獲取Access Token。

5、 應(yīng)用通過(guò)Access Token調(diào)用用戶接口獲取用戶信息。

6、 應(yīng)用得到用戶身份，完成用戶登錄。

OpenID Connect（OIDC）

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

ID_Token是符合JWT格式的數(shù)據(jù)，包含用戶身份認(rèn)證的信息，一般在只需要實(shí)現(xiàn)單點(diǎn)登錄的情況下，只需要得到ID_Token即可。

ID_Token取得信息一般是不夠的，所以一般還會(huì)用Access Token去取用戶相關(guān)的profile信息。

OpenID Connect的實(shí)現(xiàn)原理與OAuth2.0基本一致，具體如下：

說(shuō)明：

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

2、 業(yè)務(wù)系統(tǒng)判斷用戶沒(méi)有登錄，把用戶重定向到IAM進(jìn)行認(rèn)證。

3、 用戶在IAM系統(tǒng)中完成登錄認(rèn)證，IAM為用戶的此次請(qǐng)求創(chuàng)建授權(quán)碼，并帶授權(quán)碼返回應(yīng)用回調(diào)地址。

4、 應(yīng)用獲取授權(quán)碼并請(qǐng)求校驗(yàn)，獲取ID Token及Access Token。

5、 應(yīng)用通過(guò)得到ID Token及Access Token，通過(guò)Access Token調(diào)用用戶接口獲取用戶信息（一般在只需要實(shí)現(xiàn)單點(diǎn)登錄的業(yè)務(wù)場(chǎng)景下下，只需要得到ID_Token即可，不需要Access Token獲取用戶的profile）。

6、 應(yīng)用得到用戶身份，完成用戶登錄。