對於RBAC的一些思考 RBAC : Role Based Access Control 基於角色的訪問控制 問:引入 的目的是什麼? 答: 1. 在沒有role的時候,要決定一個角色有沒有許可權我們必須把角色和許可權綁定起來,引入role是為瞭解耦角色和許可權。 2. 解耦的好處表現在角色和許可權的變化比 ...
對於RBAC的一些思考
RBAC : Role Based Access Control
基於角色的訪問控制
問:引入角色
的目的是什麼?
答:
- 在沒有role的時候,要決定一個角色有沒有許可權我們必須把角色和許可權綁定起來,引入role是為瞭解耦角色和許可權。
- 解耦的好處表現在角色和許可權的變化比起用戶和許可權的
變化
要慢很多
RBAC新解 : Resource based Access Control
基於資源的訪問控制
基於角色的訪問控制缺點:
原始代碼如下:
if (user.hasRole("Project Manager") ) {
//show the project report button
} else {
//don't show the button
}
如果公司要求新增一個也有許可權的角色叫“部門經理”,程式員就必須修改上面的代碼如下:
if (user.hasRole("Project Manager") || user.hasRole("Department Manager") ) {
//show the project report button
} else {
//don't show the button
}
當許可權對應的角色改變的時候,必須對古老的代碼進行修改,這樣的隱式許可權控制(隱式是對於操作來說的)對變化太敏感,是非常脆弱的,那麼有沒有更好的解決方案來解決這樣的變化呢?當然,那就是RBAC新解:
if (user.isPermitted("projectReport:view:12345")) {
//show the project report button
} else {
//don't show the button
}
通過判斷用戶有沒有這項操作許可權(操作許可權暴露在代碼中,所以被成為顯式許可權控制
)進行工作
有種游戲框架系統component的感覺,如果一個實體擁有這個組件就擁有這項能力:
某個動物->擁有翅膀組件->可以飛
如果也用游戲框架思想來解釋RBAC舊解的話,就是這樣:
鳥類 -> 有翅膀 -> 可以飛
某個動物 -> 是鳥類 -> 可以飛
思考一下這兩種思維方式,第二種要求我們在設計的時候把游戲世界中出現的所有特殊動物定義出來,這樣的話事前設計
就顯得非常重要,而且擴展起來很困難(如果可以飛的不止鳥類呢)。
所以我認為在大多數時候,基於資源是優於基於角色的