数据库rbac
㈠ 五张表的RBAC有什么优缺点 做权限时几张表最为合适
相同点:
两种都是基于角色权限控制
2.都是同一个用户可属于多个角色或用户组
不同点:
Rbac:
1.Rbac是基于节点控制,根据3级节点,mole,controller,action,节点类似与树形结构,3级节点间相互有关联
2.表关系:用户表->用户角色关联表->角色表->角色节点关联表->节点表
3.根据3级节点控制,粒度到操作action,每个节点为单一的模块,控制器或操作
Auth:
1.Auth是基于规则控制,定制规则和条件表达式 ,每一条规则都是独立的
2.表关系:用户表->用户和用户组关联表->用户组表->规则表
3.根据规则控制,可自由定制不同的规则,非常自由,同一个规则内可以定制多个不同节点(中间的关系:OR AND)
4.可定制规则表达式,比如定制积分表达式
想法和问题:
Auth:
1.Auth验证多条规则时条件表达式不起效果
2.Auth官方例子只说一个根据积分的规则,假如我规则"Admin/Goods/goodsList,Admin/Goods/goodsDel"我
能不能定义这里面的某些ID所属角色操作权限的规则表达式,而这些所属角色id是goods表里的某个字段,可能所属的角色是多个不同的角色?
3.Auth不支持"Admin/*"泛解析,因为他每一条规则都是独立的
4.对菜单,页面,按钮类的显示使用Auth会必Rbac更好更方便
Rbac:
1.新手配置Rbac的时候经常出现 Rbac $_SESSION['_access_list'] 获取不到的问题,因为Rbac是使用ThinkPHP的底层DB引擎DSN连接数据库,需要配置数据库链接和5个表的关系,字段名和表名不能出现问题
2.允许完成"Admin/*"类型的泛解析,比如这里直接定制一个Admin模块的节点,不要下级节点就可以了
通用:
1.不管是Rbac的角色表或者Auth里面的用户组表也好,都可以扩展,比如对角色或用户组进行多层分级
2.Rbac的节点和Auth的规则都可以进行分级,比如前端功能权限,后端功能权限,后端某个功能模块权限等等
3.上面两个东西都不能应用到权限管控之中去,比如Rbac不能分享上级角色权限,Auth用户组也不能,但是能更好的管理和更加流程化的操作.
㈡ thinkphp的auth权限和rbac有什么区别
相同点:
1.两种都是基于角色权限控制
2.都是同一个用户可属于多个角色或用户组
不同点:
Rbac:
1.Rbac是基于节点控制,根据3级节点,mole,controller,action,节点类似与树形结构,3级节点间相互有关联
2.表关系:用户表->用户角色关联表->角色表->角色节点关联表->节点表
3.根据3级节点控制,粒度到操作action,每个节点为单一的模块,控制器或操作
Auth:
1.Auth是基于规则控制,定制规则和条件表达式 ,每一条规则都是独立的
2.表关系:用户表->用户和用户组关联表->用户组表->规则表
3.根据规则控制,可自由定制不同的规则,非常自由,同一个规则内可以定制多个不同节点(中间的关系:OR AND)
4.可定制规则表达式,比如定制积分表达式
想法和问题:
Auth:
1.Auth验证多条规则时条件表达式不起效果
2.Auth官方例子只说一个根据积分的规则,假如我规则"Admin/Goods/goodsList,Admin/Goods/goodsDel"我
能不能定义这里面的某些ID所属角色操作权限的规则表达式,而这些所属角色id是goods表里的某个字段,可能所属的角色是多个不同的角色?
3.Auth不支持"Admin/*"泛解析,因为他每一条规则都是独立的
4.对菜单,页面,按钮类的显示使用Auth会必Rbac更好更方便
Rbac:
1.新手配置Rbac的时候经常出现 Rbac $_SESSION['_access_list'] 获取不到的问题,因为Rbac是使用ThinkPHP的底层DB引擎DSN连接数据库,需要配置数据库链接和5个表的关系,字段名和表名不能出现问题
2.允许完成"Admin/*"类型的泛解析,比如这里直接定制一个Admin模块的节点,不要下级节点就可以了
通用:
1.不管是Rbac的角色表或者Auth里面的用户组表也好,都可以扩展,比如对角色或用户组进行多层分级
2.Rbac的节点和Auth的规则都可以进行分级,比如前端功能权限,后端功能权限,后端某个功能模块权限等等
3.上面两个东西都不能应用到权限管控之中去,比如Rbac不能分享上级角色权限,Auth用户组也不能,但是能更好的管理和更加流程化的操作.
㈢ 用一个具体数据库,分别使用BLP模型和RBAC模型对其进行访问控制策略分析
网络：陈步英
㈣ 请教关于RBAC权限管理
禁止的权限规则集
如果权限规则不是一个集合，因为只有与用户或角色关联的权限规则才允许访问，所以用户的权限是一个闭合区域，不想用户拥有某些权限时，只要不进行关联授权即可。如果权限规则使用通配符变成一个集合，那么用户的权限将变成一个开放区域，比如上面的论坛文章列表，假设论坛文章按照“版面/作者/文章标题”作为资源命名，那么将(阅览, 版面/作者/*)授权给某用户时，该用户允许阅览该版面下该作者的所有文章，假设现在有一种管理需求要求某用户可以阅览某版面下某作者除某几种文章标题外的所有文章，这样单纯的允许授权难以实现这个管理需求。
法律有许可和禁止的区别，那么权限管理也应该有许可和禁止两种授权，上面的不允许访问某几种文章标题的文章就是一种禁止规则，如果将这种禁止规则合并到允许规则中，就可以解决上面的问题。这就相当于画了一个大圈表示可以访问的区域，但是大圈里面的某些小圈是不可以访问的区域。这又带来一个问题，假设允许的和禁止的规则重叠，以谁为准？这个没有一个准则，不过基于安全性考虑，应该采用禁止优先，只要是禁止的集合，就算有允许的集合重叠，也不允许访问。
提高权限验证效率
使用关系数据库存储权限数据时，权限数据表更新和查询的操作频繁度通常小于1:9，也就是这是一个典型的OLAP系统，以查询为主，所以可以采用OLAP的优化策略进行优化，但是大多数优化策略都不具备实时性，如果兼顾实时性和效率要求，可以单独创建一个内存数据库，这个内存数据库只存放用户、资源、操作关联关系，也就是(用户, 操作, 资源)集合，如果用户通过角色关联到权限规则，那么将这些用户到权限规则的间接传递关系转变成直接传递关系保存。这个内存数据库就相当于权限数据的缓存，可以保证很高的查询效率，并且该内存数据库与权限管理保持同步，可以保证实时性。
安装和配置
附件是权限管理和权限验证的实现，也有用户管理的演示，不过用户管理很粗糙，实际使用需要做进一步开发，之所以没有开发相对完善的用户管理，是因为现在已有的系统通常都有完善的用户管理。
下面简单讲解安装配置，只在Tomcat5523+MySQL5037+jre1.5.0_12下测试过。
1． 下载rbac+profile.rar，解压，得到一系列文件，文件用途如下：
profile.admin.src.v1.jar 用户管理源代码
rbac.admin.src.v2.jar 权限管理源代码
rbac.auth.src.v2.jar 权限验证源代码
profile.v1.MySQL5.sql 用户管理用户数据表
profile.war 用户管理WEB系统
rbac.v2.MySQL5.sql 权限管理数据表
rbac.war 权限管理WEB系统
2． 创建数据库profile，使用UTF-8导入profile.v1.MySQL5.sql到profile，使用下面SQL创建用户root/1：
Insert into T_PROFILE(USER_ID, USER_NAME, USER_PASSWORD) values(‘1’, ‘root’, sha1(‘1’));
如果创建过先前SSO单点登陆的用户数据表，可以跳过这步，使用先前的数据表。
3． 创建数据库rbac，使用UTF-8导入rbac.v2.MySQL5.sql到rbac。
4． 拷贝profile.war和rbac.war到Tomcat5523/webapps/，会自动生成profile和rbac目录。
5． 参考http://blog.chinaunix.net/u1/52224/showart_412714.html配置单点登陆，因为权限管理和用户管理需要依赖单点登陆。
6． 下载相关依赖Java库：
下载cglib最新版本http://cglib.sourceforge.net/，拷贝asm.jar和cglib-2.1.3.jar到Tomcat/shared/lib。
下载c3p0最新版本http://sourceforge.net/projects/c3p0，拷贝c3p0-0.9.1.1.jar到Tomcat/shared/lib。
下载mysql-connector最新版本http://sourceforge.net/projects/mmmysql/，拷贝mysql-connector-java-5.0.4-bin.jar到Tomcat/shared/lib。
下载dwr最新版本http://getahead.org/dwr，拷贝dwr2.0.1.jar到Tomcat/shared/lib。
7． 打开profile/ WEB-INF/classes/的rbac_auth.properties、sso_agent.properties、profile_admin.properties。
# 修改为合适配置
# rbac_auth.properties
rbac.auth.db.ds.c3p0.url=jdbc:mysql://localhost/rbac
rbac.auth.db.ds.c3p0.user=root
rbac.auth.db.ds.c3p0.password=1
# sso_agent.properties
sso.passport.login=http://bsmith-cn:8080/sso/passport/login.srv
sso.passport.logout=http://bsmith-cn:8080/sso/passport/logout.srv
# profile_admin.properties
profile.admin.db.ds.c3p0.url=jdbc:mysql://localhost/profile
profile.admin.db.ds.c3p0.user=root
profile.admin.db.ds.c3p0.password=1
8． 打开rbac/WEB-INF/classes/下的rbac_admin.properties、rbac_auth.properties、sso_agent.properties。
# 修改为合适配置
# rbac_auth.properties
rbac.auth.db.ds.c3p0.url=jdbc:mysql://localhost/rbac
rbac.auth.db.ds.c3p0.user=root
rbac.auth.db.ds.c3p0.password=1
# sso_agent.properties
sso.passport.login=http://bsmith-cn:8080/sso/passport/login.srv
sso.passport.logout=http://bsmith-cn:8080/sso/passport/logout.srv
# rbac_admin.properties
rbac.admin.profile.explorer=http://bsmith-cn:8080/profile/admin/explorer.jsp?
rbac.admin.profile.profile=http://bsmith-cn:8080/profile/admin/profile.jsp?
rbac.admin.db.rbac.ds.c3p0.url=jdbc:mysql://localhost/rbac
rbac.admin.db.rbac.ds.c3p0.user=root
rbac.admin.db.rbac.ds.c3p0.password=1
㈤ 需求一个基于RBAC权限管理系统，JAVA版的，最好用SSH2做的，带数据库和源码有的发邮箱[email protected]
自己做吧
㈥ 基于RBAC权限设置的几个问题
搜一下rbac，角色都在一个表中，分配权限什么的你用前端，然后带id
㈦ 求个java版的rbac权限管理系统做毕设，需要源代码数据库，最好有报告. 邮箱1540257456@qq
RBAC的意思是基于角色的权限管理系统, 我这里好多基于Springmvc+Spring+mybatis整合的项目都是用这个模型回来实现的, 这个主要是要完答成好数据库的设计
用户表
资源表
角色表
用户-角色表
角色-资源表
每次登陆的时候联合查询把所能访问的资源查一遍就可以了
㈧ rbac是一种数据库设计思想吗
用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，回就需要给答用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）
在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。
㈨ oracle权限设计原理像oracle、mysql等数据库权限设计是不是都是基于角色访问控制(rbac)的原理啊
Oracle是基于角色访问控制的.