基于AOP实现权限管理:访问控制模型RBAC和ACL

权限、日志是系统必不可少的的功能,将这些通用的东西抽出来,以AOP方式切入系统中,可以得到非常高的复用率。

OA中,接触了ACLaccess control list)模型的权限设计。在高校平台中,采用RBAC(Role Based Access Control)模型的权限设计。

 

下面是ACL实体模型


ACL的原理非常简单:每一项资源,都配有一个列表,这个列表记录的就是哪些用户可以对这项资源执行CRUD中的那些操作。当系统试图访问这项资源时,会首先检查这个列表中是否有关于当前用户的访问权限,从而确定当前用户可否执行相应的操作。

总得来说,ACL是一种面向资源的访问控制模型,它的机制是围绕“资源”展开的。

ACL核心在于用户可以直接和权限挂钩,简单的同时它的缺点也是很明显的,由于需要维护大量的访问权限列表,所以在性能上有明显的不足,因而便有了对ACL设计的改进,ACL不仅记录用户—资源—操作表,还记录角色—资源—操作表。


通过ACL(访问控制列表)把RoleUserModulePermissionstatus(允许/禁止)关联起来。用于记录用户或者角色对资源拥有的权限。

 

下面是RBAC物理模型


 

这样设计的核心是把用户按角色进行归类,通过用户的角色来确定用户能否针对某项资源进行某项操作。

相对于ACL最大的优势就是它简化了用户与权限的管理,通过对用户进行分类,使得角色与权限关联起来,而用户与权限变成了间接关联,从而解耦。

 

但是它也有自身的缺点,那就是由于权限是以角色为载体分配的,如果某一角色下的个别用户需要进行特别的权限定制,如同加入一些其他角色的小部分权限或去除当前角色的一些权限时,RBAC就无能为力了,只能再重新创建角色,因为RBAC对权限的分配是角色为单位的。

 

为了弥补这种设计不足,通过增加security_user_permission来满到个性化需求。


 

 

两种改进模型的比较

ACL由于用户和权限直接挂钩,可以满足个性化,即为系统中的用户单独分配权限;RBAC由于角色和权限直接挂钩,使得权限可以被复用,把用户按角色进行归类。

两种改进模型,都是为了弥补自身不足而演变而来的,即ACL需要解决复用性问题,RBAC需要解决个性化问题。其实,两种改进模型都驶向了一个平衡点,虽然RBAC改进模型中的表个数多,但是原理还是一样的,只是为了降低数据的冗余度。

 

扩展模型

这两个只是基本的ACLRBAC模型,在它们基础上可以进行扩展,比如可以在RBAC模型基础上增加用户组。用户组在模型中相当于security_organization组织机构。


 

RBAC模型的更多扩展模型,可以参考权限管理之基于RBAC的扩展设计方案

展开阅读全文
博主设置当前文章不允许评论。

没有更多推荐了,返回首页