沈海波

(廣東第二師范學(xué)院 計(jì)算機(jī)科學(xué)系， 廣東 廣州 510303)

?

基于OAuth 2.0擴(kuò)展的訪問(wèn)控制委托架構(gòu)

沈海波

(廣東第二師范學(xué)院 計(jì)算機(jī)科學(xué)系， 廣東 廣州 510303)

摘要:訪問(wèn)控制是保障網(wǎng)絡(luò)資源安全訪問(wèn)的關(guān)鍵措施，而訪問(wèn)權(quán)限委托是取得動(dòng)態(tài)而又靈活的訪問(wèn)控制的重要機(jī)制.OAuth 2.0規(guī)范給出一個(gè)開(kāi)放的委托授權(quán)架構(gòu)，并得到廣泛應(yīng)用，但不適用于需要更強(qiáng)安全特性的場(chǎng)合.通過(guò)對(duì)OAuth 2.0進(jìn)行擴(kuò)展，提出一種Web應(yīng)用環(huán)境下的訪問(wèn)控制委托架構(gòu).在該架構(gòu)中，利用委托令牌表示委托、訪問(wèn)令牌表示授權(quán)，可解決安全的委托訪問(wèn)問(wèn)題；利用所有權(quán)證明(Proof-of-Possession，PoP)安全機(jī)制，可解決客戶端認(rèn)證到資源服務(wù)器的問(wèn)題；討論多步委托、委托的撤銷和令牌與消息的保護(hù)機(jī)制等，可增強(qiáng)架構(gòu)的靈活性和安全性.

關(guān)鍵詞:OAuth 2.0；委托； 訪問(wèn)控制； 所有權(quán)證明；認(rèn)證

0引言

今天的計(jì)算機(jī)系統(tǒng)或Web應(yīng)用，大多是分布式的且具有動(dòng)態(tài)特性，用戶事先并不知道為了完成某一任務(wù)所應(yīng)具有的權(quán)限.在這種情況下，委托可提供有效的解決方法，特別是在跨域的訪問(wèn)應(yīng)用場(chǎng)合.委托(Delegation)是指委托者(Delegator)將自己的全部或部分對(duì)某些資源的操作權(quán)限授予給受托者(Delegatee)，讓受托者代表委托者自己實(shí)現(xiàn)對(duì)資源或服務(wù)的操作[1].委托機(jī)制可增加訪問(wèn)控制的動(dòng)態(tài)性、靈活性和規(guī)模性.委托可在單個(gè)安全域或跨多個(gè)安全域中實(shí)現(xiàn)，跨域時(shí)涉及到域聯(lián)盟問(wèn)題；委托通常涉及到委托的表達(dá)、委托的管理(如委托權(quán)限的撤銷)等相關(guān)問(wèn)題[2-3]. 文獻(xiàn)[2]采用的是基于角色的委托與撤銷機(jī)制，文獻(xiàn)[3]采用的是屬性的委托與撤銷機(jī)制，并沒(méi)有采用新近流行的委托授權(quán)架構(gòu)OAuth(OpenAuthorization) 2.0[4-5]，兩種方法在多域情況下需要進(jìn)行角色映射和屬性映射，在不同域間存在互操作問(wèn)題[6].

OAuth2.0可以讓資源擁有者委托第三方客戶端代表自己，方便實(shí)現(xiàn)對(duì)托管在資源服務(wù)器上受保護(hù)的HTTP資源的訪問(wèn)，當(dāng)然這首先需要獲得授權(quán)服務(wù)器的授權(quán)許可，獲取訪問(wèn)令牌.但OAuth2.0目前提供的是基于不記名令牌(BearerToken)[7]的訪問(wèn)機(jī)制，允許持有不記名訪問(wèn)令牌的實(shí)體訪問(wèn)相關(guān)的被保護(hù)資源，它不需要持牌人證明其擁有相應(yīng)的密碼學(xué)密鑰(不需要驗(yàn)證持牌人的身份，即不進(jìn)行所有權(quán)證明)，因此面臨各種各樣的威脅[8]，但文獻(xiàn)[8]并沒(méi)有給出解決相應(yīng)威脅的具體方法；OAuth2.0的核心規(guī)范也沒(méi)有定義客戶端與資源服務(wù)器的安全交互(相互認(rèn)證)機(jī)制，更沒(méi)有委托授權(quán)的詳細(xì)處理過(guò)程，需要開(kāi)發(fā)方設(shè)計(jì)相關(guān)的安全機(jī)制和實(shí)現(xiàn)方法.為解決上述問(wèn)題，本文提出了一個(gè)基于OAuth2.0擴(kuò)展的Web應(yīng)用環(huán)境下單個(gè)安全域中的訪問(wèn)控制委托架構(gòu).該架構(gòu)利用基于通用的JWT(JSONWebToken)[9]格式的委托令牌表示權(quán)限委托，用基于JWT格式的訪問(wèn)令牌表示授權(quán)，解決安全的委托訪問(wèn)問(wèn)題；利用所有權(quán)證明(Proof-of-Possession，PoP)安全機(jī)制[10-11]對(duì)OAuth2.0進(jìn)行擴(kuò)展，解決客戶端認(rèn)證到資源服務(wù)器的問(wèn)題.本文還詳細(xì)討論了多步委托、委托的撤銷和令牌與消息的保護(hù)等問(wèn)題，以增強(qiáng)架構(gòu)的靈活性和安全性.

1基于OAuth 2.0擴(kuò)展的訪問(wèn)控制委托架構(gòu)

1.1架構(gòu)實(shí)體與功能

本文所提出的系統(tǒng)總體架構(gòu)如圖1所示.

圖1　總體架構(gòu)圖

架構(gòu)中涉及到的實(shí)體角色及其功能如下：

1)委托者：是資源擁有者 (ResourceOwner，RO)，一般指端用戶，它將其擁有的資源操作權(quán)限授予給受托者，負(fù)責(zé)為受托者頒發(fā)委托令牌；另外，委托者還負(fù)責(zé)制定資源的訪問(wèn)控制策略.

2)受托者：是客戶端(Client，C) ，如網(wǎng)站站點(diǎn)、Web應(yīng)用、移動(dòng)應(yīng)用等，它接受委托者的委托并代表委托者對(duì)資源進(jìn)行委托的操作.

3)授權(quán)服務(wù)器(AuthorizationServer，AS)：負(fù)責(zé)根據(jù)訪問(wèn)控制策略驗(yàn)證受托者的訪問(wèn)令牌請(qǐng)求并為受托者頒發(fā)PoP訪問(wèn)令牌.

4)資源服務(wù)器(ResourceServer，RS) ：負(fù)責(zé)托管受保護(hù)的資源，能夠接收和響應(yīng)使用訪問(wèn)令牌對(duì)受保護(hù)資源操作的請(qǐng)求.

根據(jù)委托訪問(wèn)的性質(zhì)，需要委托者與受托者之間、授權(quán)服務(wù)器與資源擁有者之間、授權(quán)服務(wù)器與資源服務(wù)器之間都具有相互信任關(guān)系.因此本文假定它們?nèi)龑?duì)實(shí)體之間互相擁有對(duì)方的公鑰，表示這種信任關(guān)系.信任關(guān)系的具體建立方式不在本文討論范圍內(nèi).

另外，由于申請(qǐng)?jiān)L問(wèn)令牌時(shí)，AS需要對(duì)請(qǐng)求者進(jìn)行身份驗(yàn)證，因此本文約定所有的客戶端(受托者)均在AS處進(jìn)行了注冊(cè)認(rèn)證，獲取自己唯一的標(biāo)識(shí)符client_id、私鑰client_secret和完整的重定向URI(redirect_uri) ，作為客戶端注冊(cè)認(rèn)證的憑據(jù).

1.2訪問(wèn)控制委托實(shí)施流程

基于OAuth2.0的訪問(wèn)控制委托實(shí)施流程如圖2所示.

圖2　訪問(wèn)控制委托流程圖

圖2中所示的抽象的OAuth2.0委托訪問(wèn)流程描述了四種角色之間的交互，包括以下步驟：

1)受托者從委托者處請(qǐng)求委托授權(quán).

2)委托者對(duì)委托請(qǐng)求進(jìn)行驗(yàn)證后，為受托者頒發(fā)委托令牌(這是一個(gè)代表委托者的委托授權(quán)憑據(jù)).為了保證委托令牌的機(jī)密性和完整性，委托者可用受托者的公鑰對(duì)委托令牌進(jìn)行加密，并用自己的私鑰對(duì)委托令牌進(jìn)行簽名.

3)受托者收到響應(yīng)后解密出委托令牌，然后認(rèn)證到AS(利用注冊(cè)時(shí)返回的客戶端憑據(jù))并出示簽名的委托令牌，以請(qǐng)求訪問(wèn)令牌.

4)AS驗(yàn)證受托者的身份(驗(yàn)證客戶端憑據(jù))并驗(yàn)證委托令牌(對(duì)委托令牌進(jìn)行簽名驗(yàn)證)，若有效則頒發(fā)訪問(wèn)令牌(本文頒發(fā)的不是不記名令牌，而是一種PoP令牌)，并為受托者與資源服務(wù)器創(chuàng)建一個(gè)共享會(huì)話密鑰，而且將此密鑰綁定到PoP令牌(綁定方法見(jiàn)1.4節(jié))，最后訪問(wèn)令牌由AS簽名.同時(shí)，也可選擇性地頒發(fā)刷新令牌.另外，為了實(shí)現(xiàn)對(duì)令牌的管理，可在AS上分別建立委托令牌列表、訪問(wèn)令牌列表、刷新令牌列表.

5)受托者向RS請(qǐng)求受保護(hù)的資源，并出示PoP訪問(wèn)令牌以認(rèn)證自己.認(rèn)證方法見(jiàn)1.5節(jié).

6)RS驗(yàn)證訪問(wèn)令牌(對(duì)令牌的AS簽名、有效期、操作的資源及權(quán)限等進(jìn)行驗(yàn)證)，若有效則給予請(qǐng)求的資源.

1.3委托令牌的結(jié)構(gòu)

OAuth2.0規(guī)范中并沒(méi)有定義令牌的表示方式，本文的各種令牌均采用比較簡(jiǎn)單緊湊的JWT結(jié)構(gòu)[9,12]表示.委托令牌中包括如下主要的聲明，也可根據(jù)需要添加其他聲明元素.

delegatorID：委托者標(biāo)識(shí)符;delegateeID：受托者標(biāo)識(shí)符;scope：受托者要訪問(wèn)的資源，用URI表示;act(Action)：表示訪問(wèn)請(qǐng)求的資源操作選項(xiàng)，可以取值GET、POST、PUT、DELETE中的任一個(gè)，分別用對(duì)應(yīng)的整數(shù)值0，4，2，3表示;exp(ExpirationTime)：有效期，表示自令牌發(fā)布之時(shí)起在這一時(shí)間段內(nèi)有效;iat(IssuedAt)：令牌發(fā)布的時(shí)間；有效期與發(fā)布時(shí)間均用UTC格式表示;nonce：一次性隨機(jī)數(shù)，既用于唯一標(biāo)識(shí)委托令牌，又用于重放保護(hù).

委托令牌樣例如圖3所示.

圖3　委托令牌樣例圖

1.4PoP密鑰和PoP訪問(wèn)令牌的綁定

基于PoP安全機(jī)制的受托者認(rèn)證方案的關(guān)鍵，是如何將PoP密鑰綁定到PoP令牌，作為所有權(quán)證明的憑據(jù).本文的PoP令牌，其聲明元素除了普通訪問(wèn)令牌所擁有的發(fā)布者iss、許可訪問(wèn)的資源scope、令牌主體sub(對(duì)應(yīng)委托令牌的delegateeID)、頒布時(shí)間iat、有效期exp、許可對(duì)資源進(jìn)行的操作act、一次性隨機(jī)數(shù)nonce等常規(guī)聲明元素外，通過(guò)專門定義一個(gè)cnf(comfirmation)聲明元素，來(lái)實(shí)現(xiàn)PoP密鑰到PoP令牌的綁定.cnf聲明的值是一個(gè)JSON對(duì)象，其成員jwk(沒(méi)有加密的PoP密鑰)或jwe(經(jīng)過(guò)加密的PoP密鑰)用于標(biāo)識(shí)PoP密鑰，從而實(shí)現(xiàn)PoP密鑰與PoP令牌的綁定，PoP密鑰用JWK(JSONWebKey)[13]格式表示.PoP令牌可用于令牌頒布者聲明令牌持有者擁有此PoP密鑰，只要能夠讓資源服務(wù)器從密碼學(xué)上證實(shí)自己擁有此PoP密鑰，受托者(客戶端)就能證明自己是PoP令牌的合法持有者.一個(gè)具有綁定功能的JWT格式的PoP令牌樣例如圖4所示. 為了保證會(huì)話密鑰的安全性，需要進(jìn)行加密.樣例中聲明jwe表示的是對(duì)稱會(huì)話密鑰k：{“kty”:”oct”, “alg”:”HS256”, “k”:”ZoRSOrFzn_Fz…”}，利用加密算法{“alg”:”RSA-OAEP”, “enc”:”AES128CBC-HS256”}，經(jīng)過(guò)JWE(JSONWebEncryption)[14]加密規(guī)則加密后的結(jié)果.

圖4　PoP令牌樣例圖

1.5受托者到資源服務(wù)器的認(rèn)證方案

在OAuth2.0的很多實(shí)際應(yīng)用場(chǎng)合，為了安全訪問(wèn)，資源服務(wù)器RS不僅要驗(yàn)證訪問(wèn)令牌的有效性，還需要對(duì)客戶端C進(jìn)行身份認(rèn)證，證實(shí)C就是訪問(wèn)令牌的合法持有者，才能許可訪問(wèn)資源.但在OAuth2.0核心規(guī)范中，并沒(méi)有定義C認(rèn)證到RS的機(jī)制，并且不需要對(duì)持有不記名令牌的客戶端進(jìn)行身份認(rèn)證，存在各種各樣的安全隱患.本文基于所有權(quán)證明(PoP)的安全機(jī)制，提出了C(本文指受托者)認(rèn)證到RS的方案.PoP安全機(jī)制的基本思想是授權(quán)機(jī)構(gòu)為請(qǐng)求方頒布PoP令牌，該令牌包含相關(guān)的認(rèn)證數(shù)據(jù)，能用于請(qǐng)求者證明自己擁有某種所有權(quán)的憑據(jù)，服務(wù)器通過(guò)驗(yàn)證請(qǐng)求者是否確有此憑據(jù)來(lái)確認(rèn)請(qǐng)求者的身份(不是直接認(rèn)證請(qǐng)求者本身)，因此稱作所有權(quán)證明認(rèn)證方法.因此，本文的方案是：當(dāng)受托者向授權(quán)服務(wù)器請(qǐng)求訪問(wèn)令牌時(shí)，授權(quán)服務(wù)器為受托者創(chuàng)建相應(yīng)的PoP令牌以及可與此PoP令牌綁定的密鑰(稱作PoP密鑰，它就是所有權(quán)證明的憑據(jù))，此密鑰可以是對(duì)稱密鑰，也可以是非對(duì)稱密鑰.當(dāng)受托者向資源服務(wù)器RS請(qǐng)求訪問(wèn)資源時(shí)，受托者通過(guò)向RS證明它擁有與PoP令牌綁定的密鑰，從而證明受托者就是PoP令牌的合法持有者.資源服務(wù)器RS接收到訪問(wèn)令牌時(shí)，通過(guò)驗(yàn)證受托者持有的密鑰與訪問(wèn)令牌上的密鑰是否匹配，來(lái)認(rèn)證受托者的身份合法性.PoP密鑰與PoP令牌的綁定方法見(jiàn)1.4節(jié).一種基于對(duì)稱會(huì)話PoP密鑰的受托者認(rèn)證到資源服務(wù)器的方案如圖5所示.

圖5　基于對(duì)稱PoP密鑰的認(rèn)證過(guò)程圖

1)受托者持委托令牌向AS請(qǐng)求PoP訪問(wèn)令牌，請(qǐng)求消息中包括受托者唯一標(biāo)識(shí)符delegateeID、授權(quán)類型grant_type(PoP類型)、請(qǐng)求訪問(wèn)的資源scope及操作act等.

2)授權(quán)服務(wù)器AS對(duì)訪問(wèn)令牌請(qǐng)求驗(yàn)證通過(guò)后，為受托者和RS創(chuàng)建一個(gè)會(huì)話密鑰KS(一種對(duì)稱PoP密鑰).為了保護(hù)會(huì)話密鑰KS的安全，需要利用RS的公鑰pkRS進(jìn)行加密后置入到PoP令牌的cnf聲明元素中，并且對(duì)PoP令牌簽名以進(jìn)行完整性保護(hù)；然后對(duì)會(huì)話密鑰KS利用受托者的公鑰加密后，與訪問(wèn)令牌一起，傳遞給受托者.這樣受托者既擁有PoP令牌，又擁有對(duì)應(yīng)的PoP密鑰，并且PoP密鑰被綁定到PoP令牌.AS產(chǎn)生的PoP令牌樣式如1.4節(jié)所示.

3)當(dāng)受托者接收到AS的響應(yīng)消息后，抽取會(huì)話密鑰KS；當(dāng)受托者向資源服務(wù)器RS請(qǐng)求訪問(wèn)資源時(shí)，需要向RS證明自己也擁有會(huì)話密鑰KS，這只要用會(huì)話密鑰KS計(jì)算請(qǐng)求消息的摘要值MAC，隨請(qǐng)求發(fā)送給RS.

4)當(dāng)資源服務(wù)器RS接收到受托者的請(qǐng)求后，恢復(fù)訪問(wèn)令牌并驗(yàn)證它，利用私鑰解密cnf中的密鑰抽取KS，然后利用KS驗(yàn)證請(qǐng)求消息的摘要值MAC，驗(yàn)證通過(guò)則說(shuō)明受托者提供(擁有)的會(huì)話密鑰KS與訪問(wèn)令牌中KS相匹配，從而實(shí)現(xiàn)對(duì)受托者的認(rèn)證.

1.6委托的撤銷

委托權(quán)限的撤銷是委托機(jī)制靈活性的重要體現(xiàn).為了實(shí)現(xiàn)對(duì)委托的撤銷，需要對(duì)授權(quán)服務(wù)器的功能進(jìn)行擴(kuò)展，讓其能提供撤銷服務(wù).同時(shí)，資源服務(wù)器也要建立被撤銷的訪問(wèn)令牌的列表，以避免被撤銷訪問(wèn)令牌的再使用.委托的撤銷，有兩種方式來(lái)實(shí)現(xiàn).一種是過(guò)期失效法，即當(dāng)委托令牌過(guò)期后，授權(quán)服務(wù)器從列表中刪除過(guò)期的委托令牌及其對(duì)應(yīng)的訪問(wèn)令牌和刷新令牌.第二種是強(qiáng)制失效法，即當(dāng)委托者想要收回委托權(quán)時(shí)，申請(qǐng)授權(quán)服務(wù)器撤銷委托，從列表中刪除申請(qǐng)撤銷的委托令牌，及其對(duì)應(yīng)的訪問(wèn)令牌和刷新令牌.第二種方法對(duì)應(yīng)的委托撤銷過(guò)程如圖6所示.

圖6　委托撤銷過(guò)程圖

首先，委托者向授權(quán)服務(wù)器HTTPPOST委托撤銷請(qǐng)求，請(qǐng)求中包括申請(qǐng)撤銷的委托令牌的委托者標(biāo)識(shí)符delegatorID、受托者標(biāo)識(shí)符delegateeID、令牌類型token_type等參數(shù).為了確認(rèn)申請(qǐng)來(lái)自于委托者，委托者需要對(duì)請(qǐng)求消息進(jìn)行簽名.當(dāng)授權(quán)服務(wù)器收到撤銷請(qǐng)求后，首先驗(yàn)證請(qǐng)求消息的簽名，然后驗(yàn)證申請(qǐng)被撤銷的委托令牌的確是頒發(fā)給申請(qǐng)中的受托者；驗(yàn)證通過(guò)后，以HTTP200方式響應(yīng)撤銷請(qǐng)求，從列表中刪除申請(qǐng)撤銷的委托令牌及其對(duì)應(yīng)的訪問(wèn)令牌和刷新令牌，并通知資源服務(wù)器何種訪問(wèn)令牌已被撤銷.如果授權(quán)服務(wù)器驗(yàn)證失敗，以HTTP400方式響應(yīng)撤銷請(qǐng)求，包括參數(shù)unsupported_token_type(申請(qǐng)撤銷的令牌類型錯(cuò)誤，即不是delegation_token,access_token,refresh_token三種令牌之一)和invaild_token(申請(qǐng)撤銷的令牌不存在).

1.7多步委托問(wèn)題

在實(shí)際應(yīng)用中，一個(gè)任務(wù)的完成可能需要多步委托才能實(shí)現(xiàn).例如，小車的擁有者Bob，委托他的服務(wù)經(jīng)理Dave進(jìn)行小車維修，Dave需要進(jìn)一步委托小車制造商維修服務(wù)公司，才能完成小車的維修任務(wù)，這涉及到再次委托，有的任務(wù)可能涉及更多的委托過(guò)程.多步委托涉及到最初的委托者(originaldelegator)、中間委托者(intermediatedelegator)、最后的受托者(finaldelegatee)、授權(quán)服務(wù)器、資源服務(wù)器等相關(guān)角色以及委托令牌鏈.中間委托者同時(shí)也是受托者.3步委托的授權(quán)過(guò)程如圖7所示.

圖7　多步委托授權(quán)示意圖

從圖7中可以看出，每步委托過(guò)程中由委托者給受托者頒發(fā)委托令牌并簽名，最后整個(gè)委托令牌鏈傳遞到最后的受托者，由受托者遞交給授權(quán)服務(wù)器，由授權(quán)服務(wù)器根據(jù)訪問(wèn)控制策略對(duì)整個(gè)委托令牌鏈進(jìn)行授權(quán)評(píng)估，如果最終的受托者得到認(rèn)證、每個(gè)委托令牌的簽名得到驗(yàn)證、委托的資源操作權(quán)限與申請(qǐng)的操作權(quán)限匹配或在委托的權(quán)限內(nèi)、沒(méi)有超時(shí)，則頒發(fā)訪問(wèn)令牌.為了保證委托令牌鏈的驗(yàn)證通過(guò)，需要后一個(gè)委托令牌的權(quán)限是前一個(gè)委托令牌的權(quán)限的子集，并且后一個(gè)委托令牌的有效期小于等于前一個(gè)委托令牌的有效期.

在存在多步委托的授權(quán)架構(gòu)中，最初的委托者和中間委托者都可請(qǐng)求撤銷其委托的權(quán)限；授權(quán)服務(wù)器也可強(qiáng)制撤銷其頒發(fā)的訪問(wèn)令牌，從而使相應(yīng)的委托失效.因此，各種撤銷機(jī)制不應(yīng)該引起互操作問(wèn)題.要注意的是，當(dāng)由最初的委托者撤銷某一委托時(shí)，則整個(gè)委托鏈將被撤銷；當(dāng)由中間的委托者撤銷某一委托時(shí)，則委托鏈中僅從此開(kāi)始的委托將被撤銷，前面的委托仍然有效.例如，假設(shè)原始委托者A將對(duì)某資源的操作權(quán)限r(nóng)委托給B，B又將其委托給C，則當(dāng)A撤銷對(duì)r的委托時(shí)，B和C都會(huì)失去權(quán)限r(nóng)；而當(dāng)B撤銷對(duì)r的委托時(shí)，則只有C失去權(quán)限r(nóng).

2結(jié)束語(yǔ)

訪問(wèn)控制是保護(hù)資源的重要安全方法，它可以防止非法的主體進(jìn)入受保護(hù)的網(wǎng)絡(luò)資源；允許合法用戶訪問(wèn)受保護(hù)的網(wǎng)絡(luò)資源；防止合法的用戶對(duì)受保護(hù)的網(wǎng)絡(luò)資源進(jìn)行非授權(quán)的訪問(wèn).而委托可以增強(qiáng)訪問(wèn)控制的靈活性和動(dòng)態(tài)性，使之更適用于當(dāng)今動(dòng)態(tài)的分布式應(yīng)用中.OAuth2.0作為廣受歡迎的開(kāi)放授權(quán)架構(gòu)，已廣泛應(yīng)用于Internet和Web應(yīng)用中，但它目前主要應(yīng)用于公開(kāi)的客戶端，對(duì)于安全性要求更高的場(chǎng)合，還存在各種各樣的安全問(wèn)題.本文對(duì)OAuth2.0進(jìn)行擴(kuò)展，提出的一種委托授權(quán)架構(gòu)，主要應(yīng)用于單個(gè)安全域中，研究了委托授權(quán)機(jī)制.接下來(lái)的工作，一是進(jìn)一步研究多步委托的委托鏈的管理機(jī)制，二是研究如何實(shí)現(xiàn)跨多個(gè)聯(lián)盟安全域的委托授權(quán)問(wèn)題，使架構(gòu)適用于更多的場(chǎng)合.

參考文獻(xiàn)：

[1]PHAMQuan,REIDJasonFrederick,MCCULLAGHAdrian,etal.Onataxonomyofdelegation.Computers&Security[J]. 2010,29(5):565-579.

[2] 袁家斌, 魏利利, 曾青華. 面向移動(dòng)終端的云計(jì)算跨域訪問(wèn)委托模型[J]. 軟件學(xué)報(bào), 2013, 24(3):564-574.

[3] 吳檳, 馮登國(guó). 多域環(huán)境下基于屬性的授權(quán)委托模型[J]. 軟件學(xué)報(bào), 2011, 22(7):1661-1675.

[4]HARDTDick.TheOAuth2.0authorizationframework[EB/OL]. (2012-10-11).[2015-12-03].http://www.rfc-editor.org/info/rfc6749.

[5] 時(shí)子慶,劉金蘭,譚曉華. 基于OAuth2.0 的認(rèn)證授權(quán)技術(shù)[J]. 計(jì)算機(jī)系統(tǒng)應(yīng)用，2012, 21(3):260 264.

[6]GUSMEROLISergio,PICCIONSalvatore,ROTONDIDomenico.Acapability-basedsecurityapproachtomanageaccesscontrolintheInternetofThings[J].MathematicalandComputerModeling, 2013,58(5-6):1189-1205.

[7]JONESMichael,HARDTDick.TheOAuth2.0authorizationframework:bearertokenusage[EB/OL]. (2012-10-11).[2015-12-10].http://www.rfc-editor.org/info/rfc6750.

[8]LODDERSTEDTTorsten,MCGLOINMark,HUNTPhil.OAuth2.0threatmodelandsecurityconsiderations[EB/OL]. (2013-01-08).[2015-12-17].http://www.rfc-editor.org/info/rfc6819.

[9]JONESMichael,BRADLEYJohn,SAKIMURANat.JSONWebToken(JWT) [EB/OL]. (2015-05-15). [2015-12-25].http://www.rfc-editor.org/info/rfc7519.

[10]TALAVIYABharatkumar,SHROFFNamrate.ModelingandassessingOAuth2.0underPoP(ProofofPossession)forsecrecy[J].InternationalJournalofEngineeringDevelopmentandResearch, 2015,3(2):883-886.

[11]HUNTPhil,RICHERJustin,MILLSWilliam,etal.OAuth2.0Proof-of-Possession(PoP)securityarchitecture[EB/OL]. (2015-12-01).[2016-01-08].https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/.

[12]JONESMichael,CAMPBELLBrain,MORTIMOREChuck.JSONWebToken(JWT)profileforOAuth2.0clientauthenticationandauthorizationGrants[EB/OL]. (2015-05-16).[2016-01-29].http://www.rfc-editor.org/info/rfc7523.

[13]JONESMichael.JSONWebKey(JWK) [EB/OL]. (2015-05-16).[2016-02-16].http://www.rfc-editor.org/info/rfc7517.

[14]JONESMichael,HILDEBRANDJoe.JSONWebEncryption(JWE). (2015-05-16).[2016-02-23].http://www.rfc-editor.org/info/rfc7516.

收稿日期：2016-04-27

基金項(xiàng)目:廣東第二師范學(xué)院教授科研專項(xiàng)基金資助項(xiàng)目(2014ARF24)

作者簡(jiǎn)介:沈海波，男,湖北孝感人，廣東第二師范學(xué)院計(jì)算機(jī)科學(xué)系教授，博士.

中圖分類號(hào)：TP309

文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：2095-3798(2016)03-0080-06

OAuth 2.0 Extensions Based AccessControlDelegationFramework

SHENHai-bo

(DepartmentofComputerScience,GuangdongUniversityofEducation,Guangzhou,Guangdong, 510303,P.R.China)

Abstract:The access control is the key measure which ensures the secure access of the Web resources, and the authority delegation is the important method to achieve dynamic and flexible access control mechanism. OAuth 2.0 specification defines an open delegation authorization framework and is used in a wide variety of applications, but it is not applicative to the scenarios that require stronger security properties. By extending the functionalities of the OAuth 2.0, an access control delegation framework for the Web application environment is proposed in this paper. In the proposed scheme, a delegation authorization problem can be solved by using the delegation token to express delegation and the access token to express authorization. And the issue of client authentication to resource server is handled based on the Proof-of-Possession (PoP) security mechanism. Finally, the multi-step delegation issues, the revocation of delegation, the protection methods of all kinds of tokens and request-response messages are discussed in detail. Those measures can strengthen the framework’s flexibility and security.

Key words:OAuth 2.0; delegation; access control; Proof-of-Possession (PoP); authentication