- 浏览: 113860 次
- 性别:
- 来自: 深圳
文章分类
最新评论
-
czqjay:
news/index/{pageNum}/{author} { ...
来谈谈REST、RBAC下的URL权限控制 -
csumck:
这也有一个在线时序图工具 http://echoma.git ...
推荐一个不错的在线“画”时序图的软件(通过文字生成图片) -
cpop:
...
如何将自己的jar包Release到Maven中央仓库中 -
yangzai911:
如果 accept-language中有值,那么也是默认取第一 ...
Play framework 国际化 -
wangyong8861850:
[color=darkred][/color][size=x- ...
EWeb4J 1.9.1 新版本发布 基于Servlet/JDBC的轻量级web开发框架
我们都知道或听说过已经很成熟的RBAC模型,本文也不打算针对RBAC模型阐述更多,若在阅读本文时表示对RBAC模型完全不懂的话,可以到以下这个网址了解清楚:http://baike.baidu.com/view/73432.htm
1.在RBAC模型中,有以下几个重要的概念
所谓的用户权限控制我想可以用这样一句简练的语句来表达吧:Who对What进行了How的操作。而很明显,Who就是用户,What就是资源,How就是操作了。
但是一般情况下用户是不会直接操作资源的,而是先成为了某种角色之后再操作资源,这时候社会更加有序。不然人人都可以对所有资源进行任何的操作,那就乱套了。
而往往,角色操作资源也是有限制的,也就是什么角色只能对什么资源作什么操作。这些也都是有规定的。
我想,这就是所谓的用户权限了吧。
既然有必要通过控制权限来维持秩序,那么权限控制必将是一门需要花心思研究的学问。
在我看来,如何抽象(或定义)“权限”是最重要的。
权限是什么?权限就是操作加上资源,在Web系统里来说,就是:权限 = Http方法+URL。
当然,这只是我的理解。
在设计的时候,需要理清RBAC模型中那些不同概念之间的关系。
从上面能够知道操作和URL其实是多对多的关系,权限只不过是这两者的关系而已。从而也能得到权限=操作+URL这样的结论。
下面,我尝试使用ER图和Java类图来表示它们的关系。
试试给出这样一个应用场景:
当前系统含有两个用户:UserA、UserB
两种角色:Role1、Role2
一个资源:News(新闻资源)
对资源的操作有:查看GET,添加POST,删除DELETE,修改PUT
标志资源的url格式:
http://localhost/news
http://localhost/news/new
http://localhost/news/{id}
http://localhost/news/{id}/edit
对以上的url添加上操作就能定义出一系列的权限:
查看新闻列表权限:http://localhost/news + GET
添加新闻内容权限:http://localhost/news + POST
查看某篇新闻内容权限:http://localhost/news/{id} + GET
删除谋篇新闻权限:http://localhost/news/{id} + DELETE
修改谋篇新闻内容:http://localhost/news/{id} + PUT
当然,上面定义权限的过程完全是可由开发者在系统设置里进行定义。这里要说明的是:不一定所有的url都需要被定义为权限,当系统需要对外提供url服务时,才有必要将其定义为权限。
你一定知道一个url没有被定义成权限时它根本就没法被使用。我们需要保证这点。例如我们可以通过隐藏菜单的方式来表达某个url没有被定义成权限。当然,这仅仅是其中一种方法而已。
试想一下:
我们使用管理员账号登陆系统后台,点击“权限管理”—>“新增权限”,然后页面显示一个url列表,我们选中某个url,然后分配操作(GET、POST、DELETE、PUT)给它,接着点击保存为"权限",这时候系统把我们选中的url加上操作保存到Permission表中,并告诉我们保存成功了。这时候我们就完成了一次权限定义的操作!
接下来,我们点击“角色管理”—>“分配权限”,页面将显示一个角色列表和一个权限列表,我们选中某个角色,然后再选中某个权限(当然可以选择多个权限),接着点击"保存",系统将为我们保存到RolePerm表,并通知我们成功了,这时候我们就完成了一次权限分配的操作。
最后,我们点击“用户管理”—>“分配角色”,有点类似以上的过程,总之最后我们肯定完成了一次分配角色给用户的操作。
以上的假想过程,就完成了一次用户权限管理操作了。这时候,使用某个被赋予某种角色的用户账号进行登录,点击任何一个按钮或者在浏览器中访问任何一个url,我想系统都应该会对其进行权限判断,从而保证系统的安全之类的。
其实我想表达的也就是这些了。我明白前面举的那些UserA、UserB后来没有被我使用,但是现实就是这样的嘛,不一定被写出来的都能够被用上的,对吧。
我想我也应该在这个时候结束这篇文章了。
哦,对了,好像忘记ER图了。不过没关系,我相信ITEye的各位都懂的。
纠结了几分钟,ER图和类图就免了,但是上一下Java代码吧。
这是我使用EWeb4j框架下的持久化类写法:
Operation.java
User.java
Role.java
Permission.java
1.在RBAC模型中,有以下几个重要的概念
- 资源(Resource):可以被标识的一切事物,例如web中用url标识的都可以称为资源,操作系统中被路径标识的文件资源。
- 权限(Permission):操作+资源(标识)
- 用户(User):权限的实际行使者或主体
- 角色(Role):一系列权限的集合体
所谓的用户权限控制我想可以用这样一句简练的语句来表达吧:Who对What进行了How的操作。而很明显,Who就是用户,What就是资源,How就是操作了。
但是一般情况下用户是不会直接操作资源的,而是先成为了某种角色之后再操作资源,这时候社会更加有序。不然人人都可以对所有资源进行任何的操作,那就乱套了。
而往往,角色操作资源也是有限制的,也就是什么角色只能对什么资源作什么操作。这些也都是有规定的。
我想,这就是所谓的用户权限了吧。
既然有必要通过控制权限来维持秩序,那么权限控制必将是一门需要花心思研究的学问。
在我看来,如何抽象(或定义)“权限”是最重要的。
权限是什么?权限就是操作加上资源,在Web系统里来说,就是:权限 = Http方法+URL。
当然,这只是我的理解。
在设计的时候,需要理清RBAC模型中那些不同概念之间的关系。
- 用户和角色是多对多的关系
- 角色和权限也是对对多的关系
- 权限和操作是多对一的关系
- 权限和URL也是多对一的关系
从上面能够知道操作和URL其实是多对多的关系,权限只不过是这两者的关系而已。从而也能得到权限=操作+URL这样的结论。
下面,我尝试使用ER图和Java类图来表示它们的关系。
- 表:User(id,name)、Role(id,name)、Permission(id,operationId,url)、Operation(id,name);
- 多对多关联表:UserRole(id,uid,rid)、RolePerm(id,rid,pid)
试试给出这样一个应用场景:
当前系统含有两个用户:UserA、UserB
两种角色:Role1、Role2
一个资源:News(新闻资源)
对资源的操作有:查看GET,添加POST,删除DELETE,修改PUT
标志资源的url格式:
http://localhost/news
http://localhost/news/new
http://localhost/news/{id}
http://localhost/news/{id}/edit
对以上的url添加上操作就能定义出一系列的权限:
查看新闻列表权限:http://localhost/news + GET
添加新闻内容权限:http://localhost/news + POST
查看某篇新闻内容权限:http://localhost/news/{id} + GET
删除谋篇新闻权限:http://localhost/news/{id} + DELETE
修改谋篇新闻内容:http://localhost/news/{id} + PUT
当然,上面定义权限的过程完全是可由开发者在系统设置里进行定义。这里要说明的是:不一定所有的url都需要被定义为权限,当系统需要对外提供url服务时,才有必要将其定义为权限。
你一定知道一个url没有被定义成权限时它根本就没法被使用。我们需要保证这点。例如我们可以通过隐藏菜单的方式来表达某个url没有被定义成权限。当然,这仅仅是其中一种方法而已。
试想一下:
我们使用管理员账号登陆系统后台,点击“权限管理”—>“新增权限”,然后页面显示一个url列表,我们选中某个url,然后分配操作(GET、POST、DELETE、PUT)给它,接着点击保存为"权限",这时候系统把我们选中的url加上操作保存到Permission表中,并告诉我们保存成功了。这时候我们就完成了一次权限定义的操作!
接下来,我们点击“角色管理”—>“分配权限”,页面将显示一个角色列表和一个权限列表,我们选中某个角色,然后再选中某个权限(当然可以选择多个权限),接着点击"保存",系统将为我们保存到RolePerm表,并通知我们成功了,这时候我们就完成了一次权限分配的操作。
最后,我们点击“用户管理”—>“分配角色”,有点类似以上的过程,总之最后我们肯定完成了一次分配角色给用户的操作。
以上的假想过程,就完成了一次用户权限管理操作了。这时候,使用某个被赋予某种角色的用户账号进行登录,点击任何一个按钮或者在浏览器中访问任何一个url,我想系统都应该会对其进行权限判断,从而保证系统的安全之类的。
其实我想表达的也就是这些了。我明白前面举的那些UserA、UserB后来没有被我使用,但是现实就是这样的嘛,不一定被写出来的都能够被用上的,对吧。
我想我也应该在这个时候结束这篇文章了。
哦,对了,好像忘记ER图了。不过没关系,我相信ITEye的各位都懂的。
纠结了几分钟,ER图和类图就免了,但是上一下Java代码吧。
这是我使用EWeb4j框架下的持久化类写法:
Operation.java
package simportal.persistent; import java.util.ArrayList; import java.util.List; import com.cfuture08.eweb4j.orm.config.annotation.Column; import com.cfuture08.eweb4j.orm.config.annotation.Id; import com.cfuture08.eweb4j.orm.config.annotation.Many; import com.cfuture08.eweb4j.orm.config.annotation.Table; import com.cfuture08.util.JsonConverter; /** * 操作,Http方法,包括GET、POST、DELETE、GET * @author weiwei[l.weiwei@163.com] * */ @Table("t_operation") public class Operation { @Id @Column("") private Integer id; @Column("") private String name; @Column("") private String description; //操作权限是一对多的关系 @Many(target=Permission.class,column="operationId") private List<Permission> permissions = new ArrayList<Permission>(); //省略setter&getter public String toString(){ return JsonConverter.convert(this); } }
User.java
package simportal.persistent; import java.util.ArrayList; import java.util.List; import com.cfuture08.eweb4j.orm.config.annotation.Column; import com.cfuture08.eweb4j.orm.config.annotation.Id; import com.cfuture08.eweb4j.orm.config.annotation.ManyMany; import com.cfuture08.eweb4j.orm.config.annotation.Table; import com.cfuture08.util.JsonConverter; /** * 用户-持久化对象 * * @author weiwei[l.weiwei@163.com] * */ @Table("t_user") public class User { @Id @Column("") private Integer id;// 自增长id @Column("") private String nickName;// 昵称 @Column("") private String account;// 账号 @Column("") private String password;// 密码,MD5加密 @Column("") private String status;// 用户状态:'在线'、'下线'、'锁定' @Column("") private String lastLoginTime;// 上一次登陆时间 @Column("") private String lastLoginIp;// 上一次登陆IP // 用户与角色时多对多关系 @ManyMany(target = Role.class, relTable = "t_user_role", from = "userId", to = "roleId") private List<Role> roles = new ArrayList<Role>();// 角色 //省略setter&getter public String toString() { return JsonConverter.convert(this); } }
Role.java
package simportal.persistent; import java.util.ArrayList; import java.util.List; import com.cfuture08.eweb4j.orm.config.annotation.Column; import com.cfuture08.eweb4j.orm.config.annotation.Id; import com.cfuture08.eweb4j.orm.config.annotation.ManyMany; import com.cfuture08.eweb4j.orm.config.annotation.Table; import com.cfuture08.util.JsonConverter; /** * 角色-持久化对象 * * @author weiwei[l.weiwei@163.com] * */ @Table("t_role") public class Role { @Id @Column("") private Integer id;//自增长ID @Column("") private String name;//角色名称 @Column("") private String description;//角色描述 //角色用户多对多关系 @ManyMany(target = User.class, relTable = "t_user_role", from = "roleId", to = "userId") private List<User> users = new ArrayList<User>();//用户 //角色权限多对多关系 @ManyMany(target=Permission.class,relTable="t_role_permission",from="roleId",to="permissionId") private List<Permission> permissions = new ArrayList<Permission>();//权限 //省略setter&getter public String toString(){ return JsonConverter.convert(this); } }
Permission.java
package simportal.persistent; import java.util.ArrayList; import java.util.List; import com.cfuture08.eweb4j.orm.config.annotation.Column; import com.cfuture08.eweb4j.orm.config.annotation.Id; import com.cfuture08.eweb4j.orm.config.annotation.ManyMany; import com.cfuture08.eweb4j.orm.config.annotation.One; import com.cfuture08.eweb4j.orm.config.annotation.Table; import com.cfuture08.util.JsonConverter; /** * 权限-持久化对象 * * @author weiwei[l.weiwei@163.com] * */ @Table("t_permission") public class Permission { @Id @Column("") private Integer id;// 自增长ID private String name;// 权限名称 @Column("") private String url;// http访问url @Column("") private String description;// 描述 //权限和操作时多对一的关系,一种操作可以形成多种权限(搭配不同的url) //暂时来说操作目前有GET、POST、PUT、DELETE四种操作,不排除未来会有其他操作 @One(column = "operationId") private Operation operation;// 操作 // 角色权限是多对多关系 @ManyMany(target = Role.class, relTable = "t_role_permission", from = "permissionId", to = "roleId") private List<Role> roles = new ArrayList<Role>();// 角色 //省略setter&getter public String toString() { return JsonConverter.convert(this); } }
发表评论
-
EWeb4J-SolidBase 发布新版本
2012-07-08 12:41 2080SolidBase项目是采用 DWZ + EWeb4J 开发的 ... -
EWeb4J 框架迁移到 GitHub
2012-07-05 10:02 1839EWeb4J 框架: https://github.com/ ... -
发布一个EWeb4J-1.9的Demo
2012-07-04 16:38 26EWeb4J-1.9框架发布在即,在此之前,发布一个小Demo ... -
Play framework 国际化
2012-05-03 20:04 4250Play的国际化操作还是非常简单的。大概分为四步: 1. ... -
解决Dojo的Widget在创建ArcGIS的Map对象时出现ID已被Registered的错误
2012-04-25 19:23 3044今天在用Dojo的toolkit(Dijits)创建ArcGI ... -
EWeb4J-1.9-控制器更新
2012-04-13 16:56 1411主要增加以下更新: 验证器 声明式事务 7个默认Acti ... -
EWeb4J-1.8.6 发布,同时带来一个演示项目
2012-03-08 17:44 2946距离上次1.7的发布已经过去5个月了。首先值得高兴的是EW ... -
推荐一个不错的在线“画”时序图的软件(通过文字生成图片)
2012-02-26 21:00 15593首先看看效果吧: 还有很多其他的风格可以选择。例如 VS ... -
选择Java,那么请拥抱Exception吧
2012-02-20 15:29 0记得很久之前就关注过Java Exception如何使用的这类 ... -
eweb demo war包+源码+db脚本 下载 (1.8.x-SNAPSHOT)
2011-12-27 17:12 2312看来,年内发布一个完整的新版本比较难了. 实在是要忙公司的项 ... -
eweb4j-1.b.8 预览 (一 新增简洁版验证器注解,改善Action访问URI注解写法)
2011-11-23 21:21 1940[list] 控制器的Action方法 ... -
Thinking in UML 学习笔记 | 第三章 UML核心元素
2011-09-05 13:53 03.1 版型(stereotype) 3.2 ... -
一个简单的菜单管理,我却迷茫了,求解惑
2011-09-01 20:28 1909一、需求 做一个 ... -
DomainModel下的包结构
2011-09-01 16:12 0从凌晨1点开始,我在ITE ... -
OSGi学习笔记
2011-08-18 09:10 1108OSGi(Open Service Gateway Initi ... -
(开源)DWZ+EWeb4j打造门户系统
2011-08-17 20:40 5830EWeb4J是一个基于Java平台 ... -
Apache与Tomcat负载均衡续
2011-08-14 14:47 1422首先非常感谢这位朋友 ... -
来谈谈REST、RBAC下的URL权限控制
2011-08-01 15:42 14846从几个月前开始接 ... -
用户权限控制分析
2011-07-28 16:20 0我们都知道或听说过已经很成熟的RBAC模型,本文也不打算针对R ... -
一个基于RBAC模型的权限管理分析
2011-07-28 16:02 0我们都知道或听说过已经很成熟的RBAC模型,本文也不打算针对R ...
相关推荐
数据仓库中用户权限控制模块的设计与实现,张京一,,随着企业业务的发展和运营人员数据分析挖掘需求的增加,传统的关系型数据库已经不能满足需求,基本的数据库访问控制已经不能很好
1》、大权限:即控制不同角色用户看到不同的树形菜单,只能看到与该用户角色对 应的菜单权限 2》、小权限:即使某几种角色的拥有相同的左菜单权限。但是根据具体的角色再细 分,控制在菜单对应的具体页面上有...
关于权限的控制如何实现,在UserRealm类中,包含认证和授权两部分,认证部分会在用户登录时,介入判断,认证通过后,生成一个ActiveUser对象,然后通过
角色-用户-权限控制设计与实现,侯潇,,本文将借助基于.NET开发的CRM示例系统,重点阐述在其中设计并实施的一套高透明度、细粒度的角色-用户-权限控制方案。此方案不依赖于
通过对传统的用户权限控制方法的全面分析,结合BBC电子商务模式用户多样化的特点,提出了一种基于角色和用户功能项相结合的权限控制方法,并给出了具体的实现方法。
分析了现有煤矿信息管理系统中权限控制策略的不足,指出基本的账户控制策略不仅功能简单,且在系统运行过程中无法修改权限,而基于角色的访问控制策略缺少对系统数据的区分,不利于系统的扩展与维护;提出了基于元数据与...
非常完整的Javaweb实践项目,可以用来作为期末课程设计,或者毕业设计,数据库脚本文件都具备,三个数据库的都含有
SAP权限审计系统的实现 SAP权限审计系统:其主要功能是事前控制及事后的合规性检查。 快速查找哪些用户拥有敏感权限(SAT); 快速查找哪些用户存在权责互斥(SOD);...快速验证用户权限; 快速抓取违规数据;
详细介绍了如何在BW系统里给用户授权,侧重点在分析权限这块,讲述了如何配置而达到控制用户依角色的不同去查看对应报表。
设置ACL练习结果分析;查看ACL控制列表;删除ACL权限;练习2;删除ACL权限;*ACL的mask权限;ACL的mask权限演示;*mask权限验证;思考;课堂活动验证&结论;*ACL的有效权限演示;ACL的有效权限验证;默认权限(拓展选学);默认...
实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户 的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一 台计算机都已具备的...
java用户角色权限设计 实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用 户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器...
基于微服务架构的云服务用户鉴权模型的分析与设计,郭云鹏,张笑燕,基于微服务架构,对提供云服务的企业业务层的用户鉴权模型进行了分析与设计,本文在分析了基于角色访问控制(RBAC)的四种权限管理模
主要介绍了linux用户和组命令,结合实例形式分析了Linux系统切换、添加用户、权限控制等相关命令与使用技巧,需要的朋友可以参考下
毕业设计可以包括文献综述、需求分析、方案设计、实施与测试等多个阶段,以确保整个过程的科学性和系统性。 其次,毕业设计的完成通常需要学生具备一定的独立思考和解决问题的能力。在研究过程中,学生可能需要采用...
针对传统界面设计方法不能很好地支持多用户访问控制建模的缺点,提出一个面向多用户访问控制的用户界面ACUI(access control user interface)模型。...实验证明,该模型能很好地指导多用户权限访问控制
Windows NT/2000/XP/2003系统支持NTFS文件系统,采用NTFS可以有效增强系统的安全性,但在ACL(访问控制列表)中对用户访问权限设置不当时,也会导致用户无法正常访问本机共享资源,出现“权限不足”的提示信息。...
而数据权限指的是某个用户、角色 或者是某个用户组对某个数据对象的操作幅度的问题,比如说用户 A可以对数据对象进行完全控制,而用户B则只能对数据对象进行 浏览的权限,同时数据权限控制隶属于动态权限控制的范畴...
软件用户分管理、普通、受限三类用户,管理用户具有最高的软件管理权限,可为不同受限用户制定不同的时间控制管理策略,各用户之间互不影响。 灵活的时间分段控制功能 时间分段控制功能提供了7 X 24...