标签：
只要是有用户参与的系统一般都会有权限管理，权限管理实现对用户的访问控制，按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。
权限管理包括用户认证和授权两部分。
用户去访问系统，系统要验证用户身份的合法性。比较常见的认证方法：1，用户名密码方式；2，指纹识别，比如我们上班打卡；3，基于证书方式；
当系统验证了用户身份的合法性，用户方可访问系统的资源。
权限管理是基于资源的，当我们去访问资源的时候，先判断这个资源是否允许匿名访问，比如我们访问一个登录页，发现这个登录页面可以匿名访问，则我们访问过程被放行，进入用户身份认证。
*subiect:主体，可以起理解为用户，但也可能是程序，都要去访问系统的资源，所以，系统需要对subject进行认证。
*principal:身份信息，通常是唯一的，一个主体还有多个身份信息，但是都有一个主身份信息（primary principal）。
*credential：凭证信息，可以是密码，证书，指纹。
用户认证通过之后，系统对用户访问资源进行控制，用户具有访问资源的权限才可以被授权访问资源。
用户认证通过之后，在用户访问资源之前，首先要判断用户是否具有访问这一资源的权限，如果有的话才可以继续访问。其实在权限控制之前，还有一项要做的额外工作就是为用户分配权限，相当于用户权限的一个初始化的过程。
授权的过程可以理解为：who 对what进行了how
who:即subject,subject在认证通过后对系统进行访问控制。
what:资源（Resource）,subject必须具备资源的访问权限才可以访问该资源，比如，用户购物时候要删除商品，但是用户是没有删除商品信息这个权限的，访问被拒绝。
PS：资源分为资源类型和资源实例，比如，商品信息，和商品ID为96e79218965eb72c92a549dd5a330112的商品。
how:权限/许可（permission）,针对资源的权限或许可，subject具有permission访问资源，如何访问操作需要定义Permission,如，用户添加，商品删除。
主体（账号、密码）
资源（资源名称，访问地址）
权限（权限名称、资源id）
角色（角色名称）
角色和权限关系（角色id、权限id）
主体和角色关系（主体id、角色id）
通常在开发中，将资源跟权限合并为一张表：
资源（资源名称、访问地址）
权限（权限名称、资源id）
合并为：
权限（权限名称、资源名称、资源访问地址）
在授权流程中，如果要使授权流程正常走下去，在这之前，要初始化我们的权限数据，即分配权限。用户需要分配相应的权限才可访问相应的资源。
权限是对于资源的操作许可。通常给用户分配资源权限需要将权限信息持久化，比如存储在关系数据库中。把用户信息、权限管理、用户分配的权限信息写到数据库（权限数据模型）
授权控制分为两种：基于角色的访问控制和基于资源的访问控制。
基于角色的访问控制： 比如，在系统中，我们将角色划分为：管理员，一般用户，匿名用户。通过配置用户在系统中的角色，来划分用户可以访问的资源。
缺点：扩展性维护性不强。
基于资源的访问控制：资源在系统中是不变的，比如资源有：类中的方法，页面中的按钮。一般建议使用这种方式实现访问控制。
粗粒度权限管理，对资源类型的权限管理。资源类型比如：菜单、url连接、用户添加页面、用户信息、类方法、页面中按钮。。
粗粒度权限管理比如：超级管理员可以访问户添加页面、用户信息等全部页面。
部门管理员可以访问用户信息页面包括 页面中所有按钮。
细粒度权限管理，对资源实例的权限管理。资源实例就资源类型的具体化，比如：用户id为001的修改连接，1110班的用户信息、行政部的员工。实际上， 细粒度权限管理就是数据级别的权限管理。
2，如何实现粗粒度的权限管理和细粒度的关系管理
粗粒度权限管理比较容易将权限管理的代码抽取出来在系统架构级别统一处理。比如：通过springmvc的拦截器实现授权。
对细粒度权限管理在数据级别是没有共性可言，针对细粒度权限管理就是系统业务逻辑的一部分，如果在业务层去处理相对比较简单，如果将细粒度权限管理统一在系统架构级别去抽取，比较困难，即使抽取的功能可能也存在扩展不强。
建议细粒度权限管理在业务层去控制。
1，基于ULR拦截：通过拦截器拦截到URL，然后进行用户认证，用户授权，通过这两部验证之后，用户才可以访问资源。
2，通过类似shiro这类权限框架实现。
标签：
原文地址：http://blog.csdn.net/lhc1105/article/details/51613765
