对于RBAC的一些思考

RBAC : Role Based Access Control

基于角色的访问控制

问：引入角色的目的是什么？
答：

1. 在没有role的时候，要决定一个角色有没有权限我们必须把角色和权限绑定起来，引入role是为了解耦角色和权限。
2. 解耦的好处表现在角色和权限的变化比起用户和权限的变化要慢很多

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旧解的话，就是这样：
鸟类 -> 有翅膀 -> 可以飞
某个动物 -> 是鸟类 -> 可以飞
思考一下这两种思维方式，第二种要求我们在设计的时候把游戏世界中出现的所有特殊动物定义出来，这样的话事前设计就显得非常重要，而且扩展起来很困难（如果可以飞的不止鸟类呢）。
所以我认为在大多数时候，基于资源是优于基于角色的