用户开始操作的主体。
对象(Subject )是指受操作的对象，如订单数据和图像文件。
权限管理表(ACL :访问控制列表)描述权限规则或用户与权限关系的数据表。
权限(Permission )是指对对象的操作，如“添加帖子的操作”。
标识访问权限的代码。 例如，添加文章操作的访问权限称为ARTICLE_ADD。
典型设计模式自主访问控制(DAC : discretionaryaccesscontrol )系统识别用户，并控制被操作对象(Subject )的权限列表) ACL :访问控制
此外，具有对象权限的用户还可以将该对象的权限分配给其他用户，因此称为“描述”控件。
这种设计最常见的应用是文件系统的权限设计，例如微软的NTFS。
DAC的最大缺点是权限管理分散，不容易管理。 例如，无法轻松将文件集的统一权限释放到指定的用户组。
Windows文件权限
强制访问控制(MAC: Mandatory Access Control ) MAC是为了弥补DAC权限控制过于分散的问题而诞生的。 在MAC设计中，每个对象都有若干权限id，每个用户也同样有若干权限id。 用户是否可以操作该对象取决于两个权限id之间的关系。 此限制的判断通常由系统强制限制。 例如，在电影作品中，当代理查询敏感文档时，“无法访问。 需要一级安全许可”经常显示在屏幕上。 在本例中，文档具有“一级安全许可”权限显示，但用户没有。
MAC非常适合敏感机构和其他等级观念强的行业，但由于业务服务系统等缺乏灵活性，因此无法适用。
RedHat MLS
Red Hat: MLS
基于角色的访问控制(RBAC : role-basedaccesscontrol )由于DAC和MAC的许多限制，RBAC应运而生，并成为迄今为止最流行的权限设计模型。
RBAC在用户和权限之间引入了“角色”的概念。 (暂时忽略Session这个概念。 ）
通过将一个或多个角色与每个用户相关联，并将一个或多个权限与每个角色相关联，可以提供非常灵活的权限管理，如图所示。 您可以根据实际业务需要灵活地创建角色，从而省去每次添加用户时关联所有权限的麻烦。 简而言之，RBAC是指用户关联角色，角色关联权限。 另外，RBAC可以模拟DAC和MAC的效果。
例如，数据库软件MongoDB采用RBAC模型，对数据库的所有操作都划分为权限(MongoDB权限文档)。
权限id表示find具有此权限的用户可以执行与查询相关的所有命令，如aggregate、checkShardingIndex和count。 insert具有此权限的用户可以执行与新数据相关的所有命令，包括insert和create。 collStats具有此权限的用户可以对指定的数据库或collection运行collStats命令。 viewRole具有此权限的用户可以查看指定数据库的角色信息。 …基于这些权限，MongoDB提供了一些预定义的角色。 (MongoDB预定义的角色文档，用户也可以自己定义角色。)。
角色findinsertcollstatsviewrole…read…read write…db admin…useradmin…最后通过向用户授予不同角色，可以分配不同粒度的权限。
目前市面上大多数系统在设计权限系统时都采用RBAC模型。 但是，也有一些系统错误地实现了RBAC，它采用了确定用户是否具有角色而不是权限。 例如，以下代码：
？ PHPif($user-HasRole('HR ) ) /执行只能充当“HR”角色的功能(如给员工涨工资)的职位公司规定也给部门管理员涨工资，则必须修改代码
以上基本上是RBAC的核心设计(RBAC Core )。 基于核心概念，RBAC规范还提供了扩展模式。
角色继承(Hierarchical Role )
具有角色继承的RBAC。 图为来自Apache目录
rqdz，角色继承意味着角色可以由其他角色继承，在拥有其他角色权限的同时，自己可以与其他权限相关联。 此设计可以对角色进行分组和分层，在一定程度上简化了权限管理工作。
“隔离”(Separation of Duty )是指篮球运动员同时拥有裁判权限，以防止用户因权限过高而产生利益冲突(乍一看犯规不狠吗？ 中，提出了另一个角色分离扩展版的RBAC。
职责分离有两种模式。
无法进行静态隔离(duty static separation of )用户
同时被赋予有冲突的角色。动态职责分离(Dynamic Separation of Duty)：用户在一次会话（Session）中不能同时激活自身所拥有的、互相有冲突的角色，只能选择其一。!
RBAC 2
静态职责分离。图片来自Apache Directory
RBAC 3
动态职责分离。图片来自Apache Directory
讲了这么多RBAC，都还只是在用户和权限之间进行设计，并没有涉及到用户和对象之间的权限判断，而在实际业务系统中限制用户能够使用的对象是很常见的需求。例如华中区域的销售没有权限查询华南区域的客户数据，虽然他们都具有销售的角色，而销售的角色拥有查询客户信息的权限。
那么我们应该怎么办呢？
用户和对象的权限控制在RBAC标准中并没有涉及到这个内容（RBAC基本只能做到对一类对象的控制），但是这里讲几种基于RBAC的实现方式。
首先我们看看PHP框架Yii 1.X的解决方案（2.X中代码更为优雅，但1.X的示例代码更容易看明白）：
<?php$auth=Yii::app()->authManager; $auth->createOperation('createPost','create a post');$auth->createOperation('readPost','read a post');$auth->createOperation('updatePost','update a post');$auth->createOperation('deletePost','delete a post');// 主要看这里。// 这里创建了一个名为`updateOwnPost`的权限，并且写了一段代码用来检验用户是否为该帖子的作者$bizRule='return Yii::app()->user->id==$params["post"]->authID;';$task=$auth->createTask('updateOwnPost','update a post by author himself',$bizRule);$task->addChild('updatePost'); $role=$auth->createRole('reader');$role->addChild('readPost'); $role=$auth->createRole('author');$role->addChild('reader');$role->addChild('createPost');$role->addChild('updateOwnPost'); $role=$auth->createRole('editor');$role->addChild('reader');$role->addChild('updatePost'); $role=$auth->createRole('admin');$role->addChild('editor');$role->addChild('author');$role->addChild('deletePost');实现效果：
Yii 1.X权限图
图片来自Yii官方WiKi
在这个Yii的官方例子中，updateOwnPost在判断用户是否具有updatePost权限的基础上更进一步判断了用户是否有权限操作这个特定的对象，并且这个判断逻辑是通过代码设置的，非常灵活。
不过大部分时候我们并不需要这样的灵活程度，会带来额外的开发和维护成本，而另一种基于模式匹配规则的对象权限控制可能更适合。例如判断用户是否对Id为123的文章具有编辑的权限，代码可能是这样的：
<?php// 假设articleId是动态获取的$articleId = 123;if ($user->can("article:edit:{$articleId}")) { // ...}而给用户授权则有多种方式可以选择：
<?php// 允许用户编辑Id为123的文章$user->grant('article:edit:123');// 使用通配符，允许用户编辑所有文章$user->grant('article:edit:*');虽然不及Yii方案的灵活，但某些场景下这样就够用了。
如果大家还有更好的方案，欢迎在评论中提出。
基于属性的权限验证（ABAC: Attribute-Based Access Control）ABAC被一些人称为是权限系统设计的未来。
不同于常见的将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性来是否满足某种条件来进行授权判断（可以编写简单的逻辑）。属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。
例如规则：“允许所有cxdjm在上课时间自由进出校门”这条规则，其中，“cxdjm”是用户的角色属性，“上课时间”是环境属性，“进出”是操作属性，而“校门”就是对象属性了。为了实现便捷的规则设置和规则判断执行，ABAC通常有配置文件（XML、YAML等）或DSL配合规则解析引擎使用。XACML（eXtensible Access Control Markup Language）是ABAC的一个实现，但是该设计过于复杂，我还没有完全理解，故不做介绍。
总结一下，ABAC有如下特点：
集中化管理可以按需实现不同颗粒度的权限控制不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中定义权限时，不能直观看出用户和对象间的关系规则如果稍微复杂一点，或者设计混乱，会给管理者维护和追查带来麻烦权限判断需要实时执行，规则过多会导致性能问题