（转）shiro权限框架详解01-权限理论介绍
http://blog.csdn.net/facekbook/article/details/54890365
权限管理
本文介绍权限管理的理论和权限管理的一些名词。
- 介绍权限管理
- 理解身份认证和授权
- 掌握权限管理的数据模型
什么是权限管理
基本上涉及到用户参与的系统都要进行权限管理，权限管理属于系统安全的范畴，权限管理实现对用户访问系统的控制，按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。
权限包括用户认证和授权两部分。对于需要访问控制的资源用户首先经过身份认证，认证通过后用户具有该资源的访问权限方可访问。
用户身份认证
概念
身份认证，就是判断一个用户是否是合法用户的一个过程。最常用的简单身份认证方式是系统通过核对用户输入的用户名和口令，看是否与系统中存储的该用户的用户名和口令一致，来判断用户是否正确。还有其他的身份认证方式，例如指纹、刷卡等。
用户密码身份认证流程
流程图关键对象
上面的流程图中需要理解以下关键对象:
- Subject：主体
访问系统的用户，主体可以是用户、程序等，进行认证的都称为主体。
-Principal：身份信息
是主体(subject)进行身份认证的标识，标识具有唯一性，如用户名、手机号、邮箱地址等，一个主体可以有多个身份，但必须有一个主身份(Primary Principal)
-credential：凭证信息
是只有主体自己知道的安全信息，如密码、证书等。
授权
概念
授权，即访问控制，控制谁能访问那些资源。主体进行身份认证后需要分配权限后方可访问系统资源，对于某些资源没有权限是无法访问的。
授权流程
下面是截图： 
流程图关键对象
授权可简单理解为who对what(which)进行how操作：
- Who，即主体(Subject)，主体需要访问系统中的资源。
- What，即资源(Resource)，如系统菜单、页面、按钮、类方法、系统商品信息等。
-How，权限/许可(Permission)，规定了主体对资源操作的许可，权限离开资源没有意义，如用户查询权限、用户添加权限、某个类方法的调用权限、编号001的用户修改权限，通过权限可知主体对那些资源都有哪些操作。
权限分为粗粒度和细粒度，粗粒度权限是指对资源类型的权限，细粒度权限是对资源实例的权限。
主体、资源、权限关系如下图： 
权限模型
对上面的主体、资源、权限通过数据模型表示。
主体(账号、密码等)
资源(资源名称、资源地址等)
权限(权限名称、资源id)
角色(角色名称)
角色和权限(角色id、权限id)
主体和角色(主体id、角色id)
可以通过下图表示： 
通常企业开发一般会将资源表和权限表合并。如下：
资源(资源名称、资源访问地址)
权限(权限名称、资源id)
合并为：
权限(权限名称、资源名称、资源访问地址)
模型图如下： 
权限分配
对主体进行权限分配，主体只允许对分配的权限范围内的资源进行操作。权限分配的数据通常都需要进行持久化。
权限控制
权限控制有两种方法实现，一种是基于角色的访问控制还一种是基于资源的访问控制。
基于角色的访问控制
RBAC基于角色的访问控制(Role-Based Access Control)是以角色为中心进行访问控制，比如：主体的角色为总经理可以查询企业运营报表，查询员工工资信息等，访问流程如下：
上图中的判断逻辑可以理解为：
if(主体.hasRole("总经理")){
查询工资
}
缺点：以角色进行访问 控制粒度较粗。系统扩展性较差。比如上图查询工资的逻辑变为总经理或部门经理，就必须要修改代码。
if(主体.hsRole("总经理") || 主体.hasRole("部门经理")){
查询工资
}- 基于资源的访问控制
RBAC基于资源的访问控制(Resouce-Based Access Control)是以资源为中心进行访问控制，比如：主体必须具有查询工资权限才可以查询员工的工资信息等，访问控制流程如下：
上图中的判断逻辑可以理解如下：
if(主体.hasPermission('查询工资权限标识')){
查询工资
}
优点：系统设计时定义好查询工资的权限标识。即使查询工资所需要的角色变为部门经理也只需要将“查询工资权限的标识”添加到“部门经理角色”的权限列表中，判断逻辑不用修改，系统可扩展性强。
