身份管理系統(tǒng)（IDM）分析

HTTP Basic Auth

數(shù)字簽名/數(shù)字證書

OAuth協(xié)議方式（Token）

SSO（Token）

實(shí)現(xiàn)方式

客戶端在發(fā)送之前是以用戶名追加一個冒號然后串接上口令，并將得出的結(jié)果字符串再用Base64算法編碼。例如，提供的用戶名是Aladdin、口令是open  sesame，則拼接后的結(jié)果就是Aladdin:open  sesame，然后再將其用Base64編碼，得到QWxhZGRpbjpvcGVuIHNlc2FtZQ==。最終將Base64編碼的字符串發(fā)送出去，由接收者解碼得到一個由冒號分隔的用戶名和口令的字符串。

為每個接入方分配一個密鑰，并且規(guī)定一種簽名的計(jì)算方法。要求接入方的請求中必須加上簽名參數(shù)。同時為防范Replay***，需要在請求中添加時間戳。

OAUTH認(rèn)證授權(quán)有三個步驟，概括為：

1. 獲取未授權(quán)的Request  Token；

2. 獲取用戶授權(quán)的Request  Token；

3. 用授權(quán)的Request  Token換取Access  Token。

當(dāng)應(yīng)用拿到Access  Token后，就可以有權(quán)訪問用戶授權(quán)的資源了。

當(dāng)用戶第一次訪問應(yīng)用系統(tǒng)1的時候，因?yàn)檫€沒有登錄，會被引導(dǎo)到認(rèn)證系統(tǒng)中進(jìn)行登錄；根據(jù)用戶提供的登錄信息，認(rèn)證系統(tǒng)進(jìn)行身份校驗(yàn)，如果通過校驗(yàn)，應(yīng)該返回給用戶一個認(rèn)證的憑據(jù)－－ticket；用戶再訪問別的應(yīng)用的時候就會將這個ticket帶上，作為自己認(rèn)證的憑據(jù)，應(yīng)用系統(tǒng)接受到請求之后會把ticket送到認(rèn)證系統(tǒng)進(jìn)行校驗(yàn)，檢查ticket的合法性。如果通過校驗(yàn)，用戶就可以在不用再次登錄的情況下訪問應(yīng)用系統(tǒng)2和應(yīng)用系統(tǒng)3了。

適用范圍

適用于HTTP協(xié)議的請求。

適用于REST/SOAP接口。

例如：AWS  REST/SOAP API。

OAuth協(xié)議適用于為外部應(yīng)用授權(quán)訪問本站資源的情況。其中的加密機(jī)制與HTTP Digest身份認(rèn)證相比，安全性更高。需要注意，OAuth身份認(rèn)證與HTTP Digest身份認(rèn)證之間并不是相互取代的關(guān)系，它們的適用場景是不同的。OAuth協(xié)議更適合于為面向最終用戶維度的API提供授權(quán)，例如獲取隸屬于用戶的微博信息等等。如果API并不是面向最終用戶維度的，例如像七牛云存儲這樣的存儲服務(wù)，這并非是OAuth協(xié)議的典型適用場景。

適用于不同網(wǎng)頁或應(yīng)用之間，不需要用戶重復(fù)輸入用戶名密碼的場景。

優(yōu)點(diǎn)

簡單，容易理解和實(shí)現(xiàn)。

基本上所有流行的網(wǎng)頁瀏覽器都支持基本認(rèn)證。

簡單，容易理解和實(shí)現(xiàn)。

在使用中，OAuth不會使第三方網(wǎng)站或應(yīng)用接觸到用戶的帳號信息(如用戶名與密碼)，授權(quán)后的http通信中也不再傳輸用戶信息而是以數(shù)字簽名和訪問令牌(AccessToken)取代，即使截到數(shù)據(jù)包，也無法還原出用戶的登錄信息。這是OAuth最大的優(yōu)點(diǎn)，也是它得以逐漸成為現(xiàn)在通用的授權(quán)標(biāo)準(zhǔn)的原因。

改善系統(tǒng)易用性。對于終端用戶使用非常方便。只需記錄一組用戶名和密碼，而且只需輸入一次。

提高系統(tǒng)開發(fā)效率。對于開發(fā)人員來說，在一個好的SSO構(gòu)架中身份驗(yàn)證框架只有一個，各應(yīng)用系統(tǒng)開發(fā)人員可以專注于業(yè)務(wù)邏輯，無須自己再設(shè)計(jì)身份驗(yàn)證程序。

簡化管理員管理。對于系統(tǒng)管理員，有了SSO，用戶的賬戶和管理系統(tǒng)都只有一套，管理方便，減少負(fù)擔(dān)。

缺點(diǎn)

雖然基本認(rèn)證非常容易實(shí)現(xiàn)，但該方案建立在以下的假設(shè)的基礎(chǔ)上，即：客戶端和服務(wù)器主機(jī)之間的連接是安全可信的。特別是，如果沒有使用SSL/TLS這樣的傳輸層安全的協(xié)議，那么以明文傳輸?shù)拿荑€和口令很容易被攔截。該方案也同樣沒有對服務(wù)器返回的信息提供保護(hù)。

需要承擔(dān)安全保存密鑰和定期更新密鑰的負(fù)擔(dān)，還要注意防范replay***。而且不夠靈活，更新密鑰和升級簽名算法很困難。如果請求中添加時間戳，需要保證客戶端和服務(wù)端時間同步。

OAuth作為一個授權(quán)協(xié)議，而不是一個認(rèn)證協(xié)議，OAuth提供的是權(quán)限分配而非認(rèn)證，授權(quán)本身的實(shí)質(zhì)相當(dāng)于系統(tǒng)為第三方網(wǎng)站/應(yīng)用開了一個后門，而你的授權(quán)就是允許它們可以走后門進(jìn)來獲取你的隱私資料和使用權(quán)限。

詳見：http://www.oschina.net/news/31399/oauth30-road-to-hell

遭受******后的危害較大。因?yàn)樯矸蒡?yàn)證系統(tǒng)集中，如果***攻破這一系統(tǒng)，意味著可以危害整個應(yīng)用系統(tǒng)體系；竊取某一用戶在某個系統(tǒng)中的用戶名和密碼，就可以竊取該用戶在該SSO體系中所有系統(tǒng)中的資源。

忘記鎖定個人桌面的信息泄露。如果用戶忘記鎖定電腦，被他人看到，則該用戶在整個系統(tǒng)中的信息都將被泄露。對比多次登錄的系統(tǒng)，同樣的情況下，可能只有某個子系統(tǒng)的特定類型數(shù)據(jù)會被泄露。

OpenIDM

OpenAm

OpenDJ

功能

用戶管理功能，包括：用戶身份周期管理、用戶和組管理、密碼管理、角色管理、權(quán)限管理、策略管理、認(rèn)證和授權(quán)、同步功能等核心功能。

并提供REST接口進(jìn)行管理。

OpenIDM的用戶數(shù)據(jù)可以同步到OpenDJ。

OpenAM 是一個領(lǐng)先的開源認(rèn)證、授權(quán)的產(chǎn)品，可用于替換即將被取消的OpenSSO。

OpenAM 提供核心的標(biāo)識服務(wù)用來簡化實(shí)現(xiàn)在一個網(wǎng)絡(luò)架構(gòu)中的透明單點(diǎn)登錄，包括集中式或者分布式的單點(diǎn)登錄。主要的特性有：

·完全符合開源AAA產(chǎn)品；

·AAA協(xié)議：計(jì)算機(jī)安全領(lǐng)域的協(xié)議，AAA指：鑒權(quán)，授權(quán)，計(jì)費(fèi)（Authentication, Authorization, Accounting）；

·簡單易用、易配置；

·純Java開發(fā)；

·可輕松配置聯(lián)合認(rèn)證系統(tǒng)，并集成到已有項(xiàng)目中。

并提供REST接口進(jìn)行管理。

提供LDAP服務(wù)，并提供REST接口進(jìn)行方便的管理。

角色

IDM（用戶身份管理）

SSO（單點(diǎn)登錄）

LDAP（輕型目錄訪問協(xié)議）

適用范圍

用戶管理。

主要適用于單點(diǎn)登錄（SSO）的應(yīng)用場景。

LDAP應(yīng)用。

認(rèn)證機(jī)制

客戶端進(jìn)行認(rèn)證的時候，向OpenIDM提供用戶名密碼（明文傳輸），OpenIDM進(jìn)行認(rèn)證并返回認(rèn)證結(jié)果。

OpenAM提供的認(rèn)證機(jī)制主要是用戶登錄功能，用戶在接口中提供用戶名密碼，OpenAM驗(yàn)證成功之后會返回一個TokenId，用于后續(xù)的SSO步驟。

提供標(biāo)準(zhǔn)的LDAP認(rèn)證機(jī)制。