当前位置: Coin163 >>

RBAC和ACL的区别比较

2013-04-08 | 所属分类:权限 角色 RBAC ACL
 

  RBAC 全称 Role Based Access Control ,翻译过来基本上就是基于角色的访问控制系统。
  ACL
全称 Access Control List ,访问控制列表,是前几年盛行的一种权限设计,它的核心在于用户直接和权限挂钩。 RBAC 的核心是用户只和角色关联,而角色代表了权限,这样设计的优势在于使得对用户而言,只需角色即可以,而某角色可以拥有各种各样的权限并可 继承 ACL RBAC 相比缺点 在于由于用户和权限直接挂钩,导致在 授予时的复杂性 ,虽然可以利用组来简化这个复杂性,但仍然会导致系统 不好理解 ,而且在取出判断用户是否有该权限时比较的困难,一定程度上影响了效率。

ACL RBAC 的区别 :

以部门新闻来讨论,对于 静态授权 ,在系统设计做需求分析的时候,往往就可以确定一个系统角色的种类,像新闻系统中,根据需求,可能会有新闻发布者 (Publisher) ,新闻审核者 (Reviewer) ,新闻浏览者 (Visitor) ,管理员 (Manager) 以及超级管理员 (Administrator)

在设计的时候我们也已经把这些 角色与相应的一些 Operation 绑定在一起
如: Publisher 拥有 Publish_Operation Modify_Operation
Reviewer
拥有 Review_Operation Modify_Operation Delete_Operation
Visitor
拥有 Visit_Operation,
Manager
拥有 Create_News_System_Instance_Operation
Modify_News_System_Instance_Operation
Delete_News_System_Instance_Operation
Administrator
负责 Create_User_Operation
Delete_User_Operation
Assign_Permission_Operation
Deassign_Permission_Operation
Assign_Role_Operation
Deassign_Role_Operation

在授权时,往往先为一个用户 (USER) ,赋予一个角色,如 :Manager. 这样, USER 就拥有了对所有 News_Instance( 也就是部门新闻 ) 操作的权限。现在假设用户 (UserA) 访问 Create_News_System_Instance 功能来创建一个新的新闻实例,叫做采购部门新闻 . 因为我们在设计的时候就确定,该功能只能由 Manager 来访问,于是,系统中权限的判断部分会 首先 判断当前用户 (UserA) 是否 Manager 角色,是的话就允许访问,否则显示没有授权的错误信息。

所以,对于 Manager 这样的应用

1、     在设计的时候,我们就将这样的角色与相应的 Permissions(A list of Subject-Operation pairs) 关联在一起了,这里的 Subject 是所有的新闻实例 (News_Instance),Operation 就是 Create,Modify 以及 Delete

2、     在授权的时候,超级管理员 (Administrator) 可以利 Assign_Role_Operation 将用户 (User) Manager 这个角色关联起来。这样, User 就拥有了对所有新闻实例的 Create,Modify 以及 Delete 操作的权限。

3、     在权限判断的时候, RBAC 系统 首先判断 当前 用户 是否是设计时确定的 角色 ( 这里是 Manager), 如果是,就允许用户访问,否则就拒绝访问,并显示错误信息。

对于 Publisher 这样的角色有些不同, Publisher 这个角色 只与 Operation 绑定 在一起,并没有与具体的 Subject 相关联,因此,在授权的时候,还需要指定相应的 Subject

所以,对 Publisher 这样 只能事先确定 Operation 的应用 来说 :

1、     在设计的时候,我们只能确定该角色能进行哪些操作,而不能确定这些操作实施的对象。

2、     在授权的时候 :

1)    首先将 Publisher Subject 关联 , 如将 Publisher 与采购部门新闻关联产生 : 采购部门新闻 _News_Publisher 的角色。

2)    Administrator 为用户 (User) 授于采购部门新闻 _News_Publisher 角色。从而 User 拥有了对 " 采购部门新闻 " 的发布权限

3、     在权限判断的时候,用户访问采购部门新闻 _News_Publish_Operation, 系统首先判断该用户是否采购部门新闻 _News_Publisher? 如果是,就允许用户访问,否则就拒绝访问,并显示错误信息。
这里用到的方法可能是这个样子 :
Boolean checkPermission(
采购部门新闻 ,Publish_Operation,User){
List publishers=RBAC.findRole(newPermission(
采购部门新闻 ,Publish_Operation));
if(publishers==null)returnfalse;
for(Iteratorit=publishers.iterator;it.hasNext();){
Role publisher=(Publisher)it.next();
if(publisher.isAssignedWithUser(User)){
returnture;
}
}
returnfalse;
}

假如说,不采用 RBAC 的做法,考虑一下,使用 ACL ,那又会是什么样子呢 ?
对于 Manager 那样能 在设计时就确定 Subject Operation 的角色,我认为没有必要考虑 ACL . 对于 Publisher 这样,只能事先确定 Operation 的角色,我们来做个对比 . 权限系统要灵活,但是也要简洁,要不然就很可能导致失控。因为 嵌套的层次太多,有可能发生不可预知的情况 . 有一天管理员可能会莫名的发现,怎么这个人会有这个权限的 ?
所以,我认为在 RBAC 里不支持 Role 的层级关系为妙

好了,现在来看看 ACL Publisher 应用
这里指的 ACL 是直接将 User Group Subject 关联的做法。


User
Subject 是多对多的情况,
Group
Subject 也是多对多的情况,
同样的, User Group 也是多对多的情况。

现在,还是以采购部门新闻为例 :

1、     在授权的时候,可以有以下操作 :

1)    User Subject 关联在一起 , 但是要指定相应的 Operation.
:assignPermission( 采购部门新闻 ,Publish_Operation,User)

2)    Group Subject 关联在一起 :
:assignPermission( 采购部门新闻 ,Publish_Operation,Group)

3)    User Group 关联
如: assignUserGroup(User,Group)

在权限判断的时候,用户访问采购部门新闻 _News_Publish_Operation ,系统做如下检查 :
Boolean checkPermission(
采购部门新闻 ,Publish_Operation,User){
booleanhasPermission=false;
//usersinclude:
//1.Permission direc tassigned Users
//2.The user assigned with the groups that assigned with permission
List users=getAssignedUsers(newPermission(
采购部门新闻 ,Publish_Operation));
hasPermission=users.contains(User)?true:false;

上一篇:
下一篇:

相关文章推荐

最新文章

关于Coin163网站地图

Copyright 2012-2013 Coin163.com ( Coin163 ) All Rights Reserved