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

沈海波

(廣東第二師范學院 計算機科學系， 廣東 廣州 510303)

?

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

沈海波

(廣東第二師范學院 計算機科學系， 廣東 廣州 510303)

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

關鍵詞:OAuth 2.0；委托； 訪問控制； 所有權證明；認證

0引言

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

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

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

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

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

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

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

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

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

3)授權服務器(AuthorizationServer，AS)：負責根據(jù)訪問控制策略驗證受托者的訪問令牌請求并為受托者頒發(fā)PoP訪問令牌.

4)資源服務器(ResourceServer，RS) ：負責托管受保護的資源，能夠接收和響應使用訪問令牌對受保護資源操作的請求.

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

另外，由于申請訪問令牌時，AS需要對請求者進行身份驗證，因此本文約定所有的客戶端(受托者)均在AS處進行了注冊認證，獲取自己唯一的標識符client_id、私鑰client_secret和完整的重定向URI(redirect_uri) ，作為客戶端注冊認證的憑據(jù).

1.2訪問控制委托實施流程

基于OAuth2.0的訪問控制委托實施流程如圖2所示.

圖2　訪問控制委托流程圖

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

1)受托者從委托者處請求委托授權.

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

3)受托者收到響應后解密出委托令牌，然后認證到AS(利用注冊時返回的客戶端憑據(jù))并出示簽名的委托令牌，以請求訪問令牌.

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

5)受托者向RS請求受保護的資源，并出示PoP訪問令牌以認證自己.認證方法見1.5節(jié).

6)RS驗證訪問令牌(對令牌的AS簽名、有效期、操作的資源及權限等進行驗證)，若有效則給予請求的資源.

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

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

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

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

圖3　委托令牌樣例圖

1.4PoP密鑰和PoP訪問令牌的綁定

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

圖4　PoP令牌樣例圖

1.5受托者到資源服務器的認證方案

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

圖5　基于對稱PoP密鑰的認證過程圖

1)受托者持委托令牌向AS請求PoP訪問令牌，請求消息中包括受托者唯一標識符delegateeID、授權類型grant_type(PoP類型)、請求訪問的資源scope及操作act等.

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

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

4)當資源服務器RS接收到受托者的請求后，恢復訪問令牌并驗證它，利用私鑰解密cnf中的密鑰抽取KS，然后利用KS驗證請求消息的摘要值MAC，驗證通過則說明受托者提供(擁有)的會話密鑰KS與訪問令牌中KS相匹配，從而實現(xiàn)對受托者的認證.

1.6委托的撤銷

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

圖6　委托撤銷過程圖

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

1.7多步委托問題

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

圖7　多步委托授權示意圖

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

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

2結(jié)束語

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

參考文獻：

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

[2] 袁家斌, 魏利利, 曾青華. 面向移動終端的云計算跨域訪問委托模型[J]. 軟件學報, 2013, 24(3):564-574.

[3] 吳檳, 馮登國. 多域環(huán)境下基于屬性的授權委托模型[J]. 軟件學報, 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] 時子慶,劉金蘭,譚曉華. 基于OAuth2.0 的認證授權技術[J]. 計算機系統(tǒ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

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

作者簡介:沈海波，男,湖北孝感人，廣東第二師范學院計算機科學系教授，博士.

中圖分類號：TP309

文獻標識碼：A

文章編號：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