RBAC新解:基于資源的權(quán)限管理(Resource-Based Access Control)

原文:https://stormpath.com/blog/new-rbac-resource-based-access-control/
http://globeeip.iteye.com/blog/1236167

本文討論以角色概念進行的權(quán)限管理策略及主要以基于角色的機制進行權(quán)限管理是遠遠不夠的礁阁。同時我將討論一種我認為更好的權(quán)限管理方式各拷。

什么是角色
當說到程序的權(quán)限管理時,人們往往想到角色這一概念迁匠。角色是代表一系列可執(zhí)行的操作或責(zé)任的實體,用于限定你在軟件系統(tǒng)中能做什么扒吁、不能做什么犁钟。用戶帳號往往與角色相關(guān)聯(lián),因此稚字,一個用戶在軟件系統(tǒng)中能做什么取決于與之關(guān)聯(lián)的各個角色饲宿。
例如,一個用戶以關(guān)聯(lián)了”項目管理員”角色的帳號登錄系統(tǒng)胆描,那這個用戶就可以做項目管理員能做的所有事情――如列出項目中的應(yīng)用瘫想、管理項目組成員、產(chǎn)生項目報表等昌讲。
從這個意義上來說国夜,角色更多的是一種行為的概念:它表示用戶能在系統(tǒng)中進行的操作。

基于角色的訪問控制(Role-Based Access Control)
既然角色代表了可執(zhí)行的操作這一概念短绸,一個合乎邏輯的做法是在軟件開發(fā)中使用角色來控制對軟件功能和數(shù)據(jù)的訪問车吹。你可能已經(jīng)猜到,這種權(quán)限控制方法就叫基于角色的訪問控制(Role-Based Access Control)鸠按,或簡稱為RBAC礼搁。
有兩種正在實踐中使用的RBAC訪問控制方式:隱式(模糊)的方式和顯示(明確)的方式。
今天依舊有大量的軟件應(yīng)用是使用隱式的訪問控制方式目尖。但我肯定的說馒吴,顯示的訪問控制方式更適合于當前的軟件應(yīng)用。

隱式的訪問控制
前面提到瑟曲,角色代表一系列的可執(zhí)行的操作饮戳。但我們?nèi)绾沃酪粋€角色到底關(guān)聯(lián)了哪些可執(zhí)行的操作呢?
答案是:目前的大多數(shù)應(yīng)用洞拨,你并能不明確的知道一個角色到底關(guān)聯(lián)了哪些可執(zhí)行操作扯罐。可能你心里是清楚的(你知道一個有”管理員”角色的用戶可以鎖定用戶帳號烦衣、進行系統(tǒng)配置歹河;一個關(guān)聯(lián)了”消費者”這一角色的用戶可在網(wǎng)站上進行商品選購)掩浙,但這些系統(tǒng)并沒有明確定義一個角色到底包含了哪些可執(zhí)行的行為。
拿”項目管理員”來說秸歧,系統(tǒng)中并沒有對”項目管理員”能進行什么樣的操作進行明確定義厨姚,它僅是一個字符串名詞。開發(fā)人員通常將這個名詞寫在程序里以進行訪問控制键菱。例如谬墙,判斷一個用戶是否能查看項目報表,程序員可能會編碼如下:

代碼塊1. 隱式地基于角色的權(quán)限控制:

if (user.hasRole("Project Manager") ){
//show the project report button
} 
else {
//don't show the button
}

在上面的示例代表中经备,開發(fā)人員判斷用戶是否有”項目管理員”角色來決定是否顯示查看項目報表按鈕拭抬。請注意上面的代碼,它并沒有明確語句來定義”項目管理員”這一角色到底包含哪些可執(zhí)行的行為侵蒙,它只是假設(shè)一個關(guān)聯(lián)了項目管理員角色的用戶可查看項目報表造虎,而開發(fā)人員也是基于這一假設(shè)來寫 if/else 語句。

脆弱的權(quán)限策略
像上面的權(quán)限訪問控制是非常脆弱的蘑志。一個極小的權(quán)限方面的需求的變動都可能導(dǎo)致上面的代碼需要重新修改累奈。
舉例來說贬派,假如某一天這個開發(fā)團隊被告知:“哦急但,順便說一下,我們需要一個’部門管理員’角色搞乏,他們也可以查看項目報表波桩。請做到這一點∏攵兀”
這種情況下镐躲,開發(fā)人員需要找到上面的代碼塊并將其修改為:

代碼塊2. 修改過的隱式的基于角色的權(quán)限控制:

if (user.hasRole("Project Manager") || user.hasRole("Department Manager") ) {
  //show the project report button
} else {
  //don't show the button
}

隨后,開發(fā)人員需要更新他的測試用例侍筛、重新編譯系統(tǒng)萤皂,還可能需要重走軟件質(zhì)量控制(QA)流程,然后再重新部署上線匣椰。這一切僅僅是因為一個微小的權(quán)限方面的需求變動裆熙!
后面如果需求方又回來告訴你說我們又有另一個角色可查看報表,或是前面關(guān)于”部門管理員可查看報表”的需求不再需要了禽笑,豈不把人累死了入录。
如果需求方要求動態(tài)地創(chuàng)建、刪除角色以便他們自己配置角色佳镜,又該如何應(yīng)對呢僚稿?
像上面的情況,這種隱式的(靜態(tài)字符串)形式的基于角色的訪問控制方式難以滿足需求蟀伸。理想的情況是如果權(quán)限需求變動不需要修改任何代碼蚀同。怎樣才能做到這一點呢缅刽?

顯式地訪問控制:更好的選擇
從上面的例子我們看到,當權(quán)限需求發(fā)生變動時蠢络,隱式的權(quán)限訪問控制方式會給程序開發(fā)帶來沉重的負擔拷恨。如果能有一種方式在權(quán)限需求發(fā)生變化時不需要去修改代碼就能滿足需求那就好了。理解的情況是谢肾,即使是正在運行的系統(tǒng)腕侄,你也可以修改權(quán)限策略卻又不影響最終用戶的使用。當你發(fā)現(xiàn)某些錯誤的或危險的安全策略時芦疏,你可以迅速地修改策略配置冕杠,同時你的系統(tǒng)還能正常使用,而不需要重構(gòu)代碼重新部署系統(tǒng)酸茴。
怎樣才能達到上面的理想效果呢分预?我們可以通過顯式的(明確的)界定我們在應(yīng)用中能做的操作來進行。
回顧上面隱式的權(quán)限控制的例子薪捍,思考一下這些代碼最終的目的笼痹,想一下它們最終是要做什么樣的控制?
從根本上說酪穿,這些代碼最終是在保護資源(項目報表)凳干,是要界定一個用戶能對這些資源進行什么樣的操作(查看/修改)。當我們將權(quán)限訪問控制分解到這種最原始的層次被济,我們就可以用一種更細粒度(更富有彈性)的方式來表達權(quán)限控制策略救赐。
我們可以修改上面的代碼塊,以基于資源的語義來更有效地進行權(quán)限訪問控制:

代碼塊3. 顯式的權(quán)限控制:

if (user.isPermitted("projectReport:view:12345")) {
  //show the project report button
} else {
  //don't show the button
}

上面的例子中只磷,我們可明確地看到我們是在控制什么经磅。不要太在意冒號分隔的語法,這僅是一個例子钮追,重點是上面的語句明確地表示了“如果當前用戶允許查看編號為12345的項目報表预厌,則顯示項目報表按鈕”。也就是說元媚,我們明確地說明了一個用戶帳號可對一個的資源實例進行的具體的操作轧叽。

為什么說這種方式更好
上面最后的示例代碼塊與前面的代碼的主要區(qū)別:最后的代碼塊是基于什么是受保護的, 而不是誰可能有能力做什么惠毁∮糖郏看似簡單的區(qū)別,但后者對系統(tǒng)開發(fā)及部署有著深刻的影響:

l 更少的代碼重構(gòu):我們是基于系統(tǒng)的功能(系統(tǒng)的資源及對資源的操作)來進行權(quán)限控制鞠绰,而相應(yīng)來說腰埂,系統(tǒng)的功能需求一旦確定下來后,一段時間內(nèi)對它的改動相應(yīng)還是比較少的蜈膨。只是當系統(tǒng)的功能需求改變時屿笼,才會涉及到權(quán)限代碼的改變牺荠。例如上面提到的查看項目報表的功能,顯式的權(quán)限控制方式不會像傳統(tǒng)隱式的RBAC權(quán)限控制那樣因不同的用戶/角色要進行這個操作就需要重構(gòu)代碼驴一;只要這個功能存在休雌,顯式的方式的權(quán)限控制代碼是不需要改變的。

l 更直觀:保護資源對象肝断、控制對資源對象的操作(對象及對象的行為)杈曲,這樣的權(quán)限控制方式更符合人們的思想習(xí)慣。正因為符合這種直觀的思維方式胸懈,面向?qū)ο蟮木庉嬎枷爰癛EST通信模型變得非常成功担扑。

l 更有彈性:上面的示例代碼中沒有寫死哪些用戶、組或角色可對資源進行什么操作趣钱。這意味著它可支持任何安全模型的設(shè)計涌献。例如,可以將操作(權(quán)限)直接分配給用戶 首有,或者他們可以被分配到一個角色燕垃,然后再將角色與用戶關(guān)聯(lián),或者將多個角色關(guān)聯(lián)到組(group)上井联,等等卜壕。你完全可以根據(jù)應(yīng)用的特點定制權(quán)限模型。

l 外部安全策略管理:由于源代碼只反映資源和行為低矮,而不是用戶印叁、組和角色,這樣資源/行為與用戶军掂、組、角色的關(guān)聯(lián)可以通過外部的模塊或?qū)S霉ぞ呋蚬芾砜刂婆_來完成昨悼。這意味著在權(quán)限需求變化時蝗锥,開發(fā)人員并不需要花費時間來修改代碼,業(yè)務(wù)分析師甚至最終用戶就可以通過相應(yīng)的管理工具修改權(quán)限策略配置率触。

l 可在運行環(huán)境做修改:因為基于資源的權(quán)限控制代碼并不依賴于行為的主體(如組终议、角色、用色)葱蝗,你并沒有將行為的主體的字符名詞寫在代碼中穴张,所以你甚至可以在程序運行的時候通過修改主體能對資源進行的操作這樣一些方式,通過配置的方式就可應(yīng)對權(quán)限方面需求的變動两曼,再也不需要像隱式的RBAC方式那樣需要重構(gòu)代碼皂甘。

RBAC新解:Resource-Based Access Control
對于上面列出的諸多好處,我重點要說是這種顯式的機制帶給我們的富有彈性的權(quán)限模型悼凑。
如果你仍想保留或模擬傳統(tǒng)的基于角色的權(quán)限訪問控制偿枕,你可以將權(quán)限(可執(zhí)行的操作)直接分配給某個角色璧瞬。這種情況下,你依舊是在使用基于角色的權(quán)限訪問控制方式(不同之處在于你需要明確地界定角色中的權(quán)限渐夸,而不是傳統(tǒng)的使用角色字符串隱式地進行權(quán)限控制)嗤锉。
但在這種新的模型下,已不必再局限于角色了墓塌。你可以將權(quán)限直接分配給用戶瘟忱、組或其它你覺得可以的對象。
因為上面顯式地苫幢、基于資源的權(quán)限訪問控制的諸多好處酷誓,或許可以給RBAC一個新的定義:“Resource-Based Access Control”。只是我的一個想法:)

現(xiàn)實世界的例子:Apache Shiro
如果你好奇現(xiàn)實世界有沒有被多個系統(tǒng)使用的基于資源的權(quán)限控制框架态坦,你可以了解一下Apache Shiro盐数。它是一個java平臺的現(xiàn)代權(quán)限管理框架。通過它的權(quán)限(Permission)概念伞梯,Shiro很好地支持基于資源的權(quán)限訪問控制玫氢。
當然,并不需要借用Shiro來理解本文所說的一些概念谜诫,但Shiro對理解本文所討論的概念及示例有一定的幫助漾峡。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市喻旷,隨后出現(xiàn)的幾起案子生逸,更是在濱河造成了極大的恐慌,老刑警劉巖且预,帶你破解...
    沈念sama閱讀 211,817評論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件槽袄,死亡現(xiàn)場離奇詭異,居然都是意外死亡锋谐,警方通過查閱死者的電腦和手機遍尺,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,329評論 3 385
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來涮拗,“玉大人乾戏,你說我怎么就攤上這事∪龋” “怎么了鼓择?”我有些...
    開封第一講書人閱讀 157,354評論 0 348
  • 文/不壞的土叔 我叫張陵,是天一觀的道長就漾。 經(jīng)常有香客問我呐能,道長,這世上最難降的妖魔是什么从藤? 我笑而不...
    開封第一講書人閱讀 56,498評論 1 284
  • 正文 為了忘掉前任催跪,我火速辦了婚禮锁蠕,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘懊蒸。我一直安慰自己荣倾,他們只是感情好,可當我...
    茶點故事閱讀 65,600評論 6 386
  • 文/花漫 我一把揭開白布骑丸。 她就那樣靜靜地躺著舌仍,像睡著了一般。 火紅的嫁衣襯著肌膚如雪通危。 梳的紋絲不亂的頭發(fā)上铸豁,一...
    開封第一講書人閱讀 49,829評論 1 290
  • 那天,我揣著相機與錄音菊碟,去河邊找鬼节芥。 笑死,一個胖子當著我的面吹牛逆害,可吹牛的內(nèi)容都是我干的头镊。 我是一名探鬼主播,決...
    沈念sama閱讀 38,979評論 3 408
  • 文/蒼蘭香墨 我猛地睜開眼魄幕,長吁一口氣:“原來是場噩夢啊……” “哼相艇!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起纯陨,我...
    開封第一講書人閱讀 37,722評論 0 266
  • 序言:老撾萬榮一對情侶失蹤坛芽,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后翼抠,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體咙轩,經(jīng)...
    沈念sama閱讀 44,189評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,519評論 2 327
  • 正文 我和宋清朗相戀三年机久,在試婚紗的時候發(fā)現(xiàn)自己被綠了臭墨。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,654評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡膘盖,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出尤误,到底是詐尸還是另有隱情侠畔,我是刑警寧澤,帶...
    沈念sama閱讀 34,329評論 4 330
  • 正文 年R本政府宣布损晤,位于F島的核電站软棺,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏尤勋。R本人自食惡果不足惜喘落,卻給世界環(huán)境...
    茶點故事閱讀 39,940評論 3 313
  • 文/蒙蒙 一茵宪、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧瘦棋,春花似錦稀火、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,762評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至沛慢,卻和暖如春赡若,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背团甲。 一陣腳步聲響...
    開封第一講書人閱讀 31,993評論 1 266
  • 我被黑心中介騙來泰國打工逾冬, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人躺苦。 一個月前我還...
    沈念sama閱讀 46,382評論 2 360
  • 正文 我出身青樓身腻,卻偏偏與公主長得像,于是被迫代替她去往敵國和親圾另。 傳聞我的和親對象是個殘疾皇子霸株,可洞房花燭夜當晚...
    茶點故事閱讀 43,543評論 2 349

推薦閱讀更多精彩內(nèi)容

  • 轉(zhuǎn)自:http://www.thinksaas.cn/group/topic/150841/原文地址:http:/...
    光光李閱讀 1,402評論 0 9
  • Android 自定義View的各種姿勢1 Activity的顯示之ViewRootImpl詳解 Activity...
    passiontim閱讀 171,789評論 25 707
  • 說明:本文很多觀點和內(nèi)容來自互聯(lián)網(wǎng)以及各種資料,如果侵犯了您的權(quán)益集乔,請及時聯(lián)系我去件,我會刪除相關(guān)內(nèi)容。 權(quán)限管理 基...
    寇寇寇先森閱讀 7,580評論 8 76
  • 一首給你寫的詩 一支用不壞的筆 一曲聽不厭的歌 一件穿不皺的白色襯衫 一肩吹不亂的黑色長發(fā) 一把小小的傘 一條長長...
    菠蘿喵閱讀 257評論 0 0
  • 學(xué)校里剛來扰路,因為張淑莉胃疼尤溜,認識了陳老師(陳江)。 初見面 三十出頭汗唱,頭有點凸宫莱,臉圓圓,身材壯壯哩罪,小麥膚色授霸,走起路...
    山南有竹閱讀 478評論 0 0