权限系统中有2个基本的概念：
粗粒度：表示类（model）别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特定的实例。比如，对文档的管理中，创建、删除等操作，对所有的用户都一视同仁，并不区分具体的对象实例（图片，附件等）。
细粒度：表示实例(instance)级别，即需要考虑具体对象的实例(the instance of object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，文档管理中，文档所有者拥有查看、修改、删除等权限，其他用户只有文档的查看权限。
权限系统的设计原则：权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。
细粒度的权限问题因为其业务相关性而不具通用意义，它们被理解为是“业务逻辑”的一部分。比如，要求：“某个文档只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既是一个细粒度的权限问题，也是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予考虑。当然，权限系统的构架设计也必须要能支持这样的业务逻辑。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。
对于在企业环境中的访问控制方法，一般有三种：
1、自主型访问控制方法（DAC）。目前在我国的大多数的信息系统中的访问控制模块基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。
2、强制型访问控制方法（MAC）。用于多层次安全级别的军事应用。
3、基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。
RBAC（Role-Based Access Control ）基于角色的访问控制。美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有系统性
RBAC认为权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。
即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。
RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。
RBAC模型概述
RBAC即角色访问控制(Role Based Access Control)
RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。
Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege,正向授权与负向授权）。**
RBAC模型特征
基于角色的访问控制方法（RBAC）的显著的两大特征是：
1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。
2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
RBAC支持的安全原则
最小权限原则（即细粒度控制原则）
RBAC 可将其角色配置成其完成任务所需要的最小权限集；
责任分离原则
通过调用相互独立互斥的角色来共同完成敏感的任务而体现，如要求一个计帐员和财务管理员一起参与同一个过帐；
数据抽象原则
通过权限的抽象来体现，如财务操作用借款、存款等抽象权限。
RBAC模型主要分为RBAC0、RBAC1、RBAC2、RBAC3，RBAC0是所有模型的基础，其他三种是基于RBAC0模型的扩展与变形。
RBAC其实是一种分析模型，主要分为：基本模型RBAC0（Core RBAC）、角色分层模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。
最小特权原则得到支持，是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
数据抽象是借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RBAC模型的实现细节有关。
RBAC96是一个模型族，其中包括RBAC0~RBAC3四个概念性模型。
1、基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。
2、RBAC1和RBAC2两者都包含RBAC0，但各自都增加了独立的特点，它们被称为高级模型。
3、RBAC3称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。这些模型构成了RBAC96模型族。
RBAC模型简述
RBAC0，它是RBAC0的核心，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。RBAC0定义了能构成RBAC控制系统的最小的元素集合，RBAC0由四部分构成：
a、用户（User）
b、角色（Role）
c、会话（Session）
d、许可（Pemission）,其中许可又包括“操作”和“控制对象”其中许可被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的许可。会话是动态的概念，用户必须通过会话才可以设置角色，是用户与激活的角色之间的映射关系。
privilege n : 1 Resource
Role n : n Privilege
Group n : n User
Group n : n Role
User n : n Role
核心实现
权限系统的核心由以下三部分构成：创造权限、分配权限、使用权限。
1、 Creator 创造 Privilege， Creator 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是 Privilege 与 Resource 的对象声明，并没有真正将 Privilege 与具体Resource 实例联系在一起，形成Operator。
2、 Administrator 指定 Privilege 与 Resource Instance 的关联。在这一步， 权限真正与资源实例联系到了一起， 产生了Operator（Privilege Instance）。Administrator利用Operator这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等。这些操作都是由 Administrator 来完成的。
3、 User 使用 Administrator 分配给的权限去使用各个子系统。Administrator 是用户，在他的心目中有一个比较适合他管理和维护的权限模型。于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的 Operator。程序员提供 Operator 就意味着给系统穿上了盔甲。Administrator 就可以按照他的意愿来建立他所希望的权限框架自行增加，删除，管理Resource和Privilege之间关系。可以自行设定用户User和角色Role的对应关系。(如果将 Creator看作是 Basic 的发明者， Administrator 就是 Basic 的使用者，他可以做一些脚本式的编程) Operator是这个系统中最关键的部分，它是一个纽带，一个系在Programmer，Administrator，User之间的纽带。
RABC0权限管理的核心部分，其他的版本都是建立在0的基础上的，看一下类图：
图中，用户与角色是多对多的关系；角色和许可也是多对多的关系；用户与会话是一对一关系；会话与角色是一对多关系；
RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。
在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，此模型指明用户、角色、访问权限和会话之间的关系。
每个角色至少具备一个权限，每个用户至少扮演一个角色；可以对两个完全不同的角色分配完全相同的访问权限；会话由用户控制，一个用户可以创建会话并激活多个用户角色，从而获取相应的访问权限，用户可以在会话中更改激活角色，并且用户可以主动结束一个会话。
用户和角色是多对多的关系，表示一个用户在不同的场景下可以拥有不同的角色。
例如项目经理也可以是项目架构师等；当然了一个角色可以给多个用户，例如一个项目中有多个组长，多个组员等。
这里需要提出的是，将用户和许可进行分离，是彼此相互独立，使权限的授权认证更加灵活。
角色和许可（权限）是多对多的关系，表示角色可以拥有多分权利，同一个权利可以授给多个角色都是非常容易理解的，想想现实生活中，当官的级别不同的权限的情景，其实这个模型就是对权限这方面的一个抽象，联系生活理解就非常容易了。
RBAC1，基于RBAC0模型，引入角色间的继承关系，即角色上有了上下级的区别，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。
这种模型合适于角色之间的层次明确，包含明确。
RBAC2，基于RBAC0模型的基础上，进行了角色的访问控制。
RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可，此约束有多种。
互斥角色 ：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。
基数约束 ：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人有限的；
先决条件角色 ：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。
运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。
RBAC3，也就是最全面级的权限管理，它是基于RBAC0的基础上，将RBAC1和RBAC2进行整合了，最前面，也最复杂的：
综上为权限管理模型的相关介绍，其实在任何系统中都会涉及到权限管理的模块，无论复杂简单，我们都可以通过以RBAC模型为基础，进行相关灵活运用来解决我们的问题。
RBAC的优缺点
RBAC模型没有提供操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作次序的实体系统。
例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到模型
RBAC 核心对象模型
授权模型：用户-角色-权限
核心动作：
创造权限
分配权限
使用权限
核心动作的主要参与者：
Creator 创造权限：这里完成的是 Privilege 与 Resource 的对象声明；
Administrator 分配权限：把 Privilege 与 Resource Instance 真正关联到一起，产生了 Operator （Privilege Instance）。Administrator 利用 Operator 这个基本元素，来创造他理想中的权限模型，如创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等；
User 使用权限