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