java web项目 权限管理



方法一、SpringMVC整合Shiro （Shiro是强大的权限管理框架）

http://www.360doc.com/content/14/0529/09/11298474_381916189.shtml

方法二、基于角色的访问权限控制

基于角色的访问权限控制
废话少说，理论的东西不想多说了，网上一大把，我来点实际的。
首先基于角色的访问权限控制，所有的用户访问都会经过过滤，然后分析访问权限加以认证！
权限中的重点，表的设计。

普遍三张表，表名自定义。用户表（User），角色表（Role），资源表（Resource）

用户表没有特别，很简单。关键是角色表和资源表。


表结构总览


数据表


角色表



用户表




资源表
角色表中关键的一个字段，访问级别（level）
该字段直接控制了该角色能访问哪些表信息，比如一张数据表中有移动、联通两种数据，访问级别可以控制角色只能访问其中一种。


资源表中关键字段：AuthorityName与resourceURL：
一个URL可以对应多个AuthorityName，但一个AuthorityName只能对应一个URL，URL的访问可以定义为需要多个权限还是单个权限的。
这三张表的关系是多对多的关系
即用户可以拥有多个角色，角色可以访问多种资源。特定情况下，我们可以关联用户表和资源表，为用户分配特定的资源访问。


另外我们要在数据表中加入访问级别字段。用以判断访问的角色是否拥有该级别。

首先不要框架手写权限控制，基本流程如下
写一个pojo类，定义一个Map<String,Collection<String>>集合。作用就是用来配对资源与权限。
配置一个servlet，在容器启动时自加载权限，并且通过资源表的数据信息，将每一条资源中的resourceURL与AuthorityName（权限名）进行配对。这里的resourceURL可能对应多个权限，所以Map集合内的Collection集合就是用来配置多个权限的，验证时需匹配该集合内所有的权限。所以URL可以重复录入数据库，但权限不能重复。
AuthorityDataMap，建立这个类用来存放经过权限匹配后的权限信息，是项目所有的权限集合。缓存在servlet上下文中。
UserAuthorityManager 这个类定义登录用户索要注册的信息，比如有：用户名，角色组，登录信息等。在登录后就会缓存在servlet容器中。用户访问时权限的验证。
实现一个过滤器，AccessDecider，这是一个访问决策器，主要用于对当前用户访问的资源进行验证和权限匹配，符合则通过，不符合就驳回。
实现一个过滤器，authorityFilter ，这个过滤器用来过滤用户所有请求。将过滤的请求与缓存在servlet中的AuthorityDataMap中的权限集合进行匹配，如发现有该URL则遍历UserAuthorityManager中的当前用户权限进行匹配。在查询时，还需检查用户的访问级别，即角色级别，根据级别展现不同数据。
所有，最后梳理一下过程：
1，服务启动，AUthorityDataMap开始加载所有权限
2，UserAuthorityManager用户登录加载用户权限
3AuthorityFiler过滤所有请求 → 转交给AccessDecider做权限判断 → 根据判断结果做出相应的成功或失败跳转。

方法三、建议用RBAC权限模型

NIST （The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。 

 
 RBAC 0 模型 
RBAC0 定义了能构成一个RBAC控制系统的最小的元素集合
在RBAC 之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权 permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、 RBAC3都是先后在RBAC0上的扩展。

 RBAC1 引入角色间的继承关系
角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。

RBAC2 模型中添加了责任分离关系
RBAC2 的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
l RBAC3 包含了RBAC1和RBAC2
既提供了角色间的继承关系，又提供了责任分离关系。

建立角色定义表。定出当前系统中角色。
因为有继承的问题，所以角色体现出的是一个树形结构。 



思想 :
权限系统的核心由以下三部分构成： 1. 创造权限， 2. 分配权限， 3. 使用权限，然后，系统各部分的主要参与者对照如下： 1. 创造权限 - Creator 创造， 2. 分配权限 - Administrator 分配， 3. 使用权限 - User ：
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 之间的纽带。



详细内容在http://info.codepub.com/2008/05/info-19368.html

方法四、参考尚学堂的OA项目

http://bbs.csdn.net/topics/300237764里面有提及