前言
权限、日志是系统必不可少的的功能,将这些通用的东西抽出来,以AOP方式切入系统中,可以得到非常高的复用率。
在OA中,接触了ACL(access control list)模型的权限设计。在高校平台中,采用RBAC(Role Based Access Control)模型的权限设计。
一、ACL实体模型
下面是ACL实体模型
ACL的原理非常简单:每一项资源,都配有一个列表,这个列表记录的就是哪些用户可以对这项资源执行CRUD中的那些操作。当系统试图访问这项资源时,会首先检查这个列表中是否有关于当前用户的访问权限,从而确定当前用户可否执行相应的操作。
总得来说,ACL是一种面向资源的访问控制模型,它的机制是围绕“资源”展开的。
二、ACL设计的改进
ACL核心在于用户可以直接和权限挂钩,简单的同时它的缺点也是很明显的,由于需要维护大量的访问权限列表,所以在性能上有明显的不足,因而便有了对ACL设计的改进,ACL不仅记录用户—资源—操作表,还记录角色—资源—操作表。
通过ACL(访问控制列表)把Role、User、Module、Permission、status(允许/禁止)关联起来。用于记录用户或者角色对资源拥有的权限。
三、RBAC物理模型
下面是RBAC物理模型
这样设计的核心是把用户按角色进行归类,通过用户的角色来确定用户能否针对某项资源进行某项操作。
相对于ACL最大的优势就是它简化了用户与权限的管理,通过对用户进行分类,使得角色与权限关联起来,而用户与权限变成了间接关联,从而解耦。
但是它也有自身的缺点,那就是由于权限是以角色为载体分配的,如果某一角色下的个别用户需要进行特别的权限定制,如同加入一些其他角色的小部分权限或去除当前角色的一些权限时,RBAC就无能为力了,只能再重新创建角色,因为RBAC对权限的分配是角色为单位的。
四、RBAC物理模型改进
为了弥补这种设计不足,通过增加security_user_permission来满到个性化需求。
五、两种改进模型的比较
两种改进模型的比较
ACL由于用户和权限直接挂钩,可以满足个性化,即为系统中的用户单独分配权限;RBAC由于角色和权限直接挂钩,使得权限可以被复用,把用户按角色进行归类。
两种改进模型,都是为了弥补自身不足而演变而来的,即ACL需要解决复用性问题,RBAC需要解决个性化问题。其实,两种改进模型都驶向了一个平衡点,虽然RBAC改进模型中的表个数多,但是原理还是一样的,只是为了降低数据的冗余度。
六、扩展模型
扩展模型
这两个只是基本的ACL和RBAC模型,在它们基础上可以进行扩展,比如可以在RBAC模型基础上增加用户组。用户组在模型中相当于security_organization组织机构。
七、RBAC模型的更多扩展模型
RBAC模型的更多扩展模型,可以参考权限管理之基于RBAC的扩展设计方案
除两上述两种主要的模型之外,还有包括:基于属性的访问控制ABAC和基于策略的访问控制PBAC等等,因为应用不是很广泛,就不做介绍了。
原文地址:
https://blog.csdn.net/tch918/article/details/18449043