「rbac实现JAVA」rbac模式

今天给各位分享rbac实现JAVA的知识，其中也会对rbac模式进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、什么是RBAC？
• 2、B端产品之权限设计（RBAC权限模型）
• 3、什么是rbac
• 4、Java web怎么实现普通用户与管理员跳转不同页面
• 5、请教关于RBAC权限管理

什么是RBAC？

什么是RBAC？

全称 ：role-based access control 基于角色的权限访问控制

作用 ：实现访问控制

RBAC模型概括

RBAC权限授权的过程可以概括为：W是否可以对Z进行H的访问操作，并对这个逻辑表达式进行判断是否为true的过程，也是将权限问题转换为Z、H的问题，W、Z、H构成了访问权限三元组。

权限与角色相关联，用户通过称为适当角色的成员而得到这些角色的权限，极大的简化了权限的管理。

RBAC的组成

3个基础组成部分

- 用户

- 角色

- 权限

RBAC通过定义角色的权限，并且对用户授予某个角色来控制用户的权限，从而实现了用户和权限的逻辑分离，方便了权限的管理

1. user（用户） ：每个用户都有不同且唯一的ID，用来进行识别，并被授予不同的角色

2. role（角色） ：不同的角色具有不同的权限

3. jurisdiction（权限） ：访问权限

关系 ：

- 用户 ---角色的映射：用户和角色之间的映射关系

- 角色 ---权限的映射：角色和权限之间的映射关系

例如：

用户的角色不同，看到的权限也就有所不同

RBAC的安全原则

- 最小权限原则 ：将角色配置成其完成所需的最小权限集合

- 责任分离原则 ：通过调用相互独立且互斥的角色来完成敏感任，例如：记账员和财务管理员共同参与过账操作

- 数据抽象原则 ：借助于抽象许可权这样的概念实现，例如：在账目管理活动中，可以使用信用，借方等抽象许可权，而不是使用典型的读、写、执行权限

RBAC的优缺点

优点：

1. 便于授权管理

2. 便于角色的划分

3. 便于赋予最小权限的原则

4. 便于职责的分离

5. 便于客体分类

缺点 ：

- 没有提供操作顺序的控制机制，这一缺陷使RBAC模型很难适应那些对操作顺序有严格要求的系统

RBAC的3种模型

1. RBAC0 ：最简单、最原始的实现方式，也是其他RBAC模型的基础

在该模型中，用户和角色之间可以是多对多的关系，一个用户在不同场景下是可以有不同的角色。

2. RBAC1 ：基于RBAC0模型，引入了角色间的继承关系，角色上有了上下级的区别

3. RBAC2 ：基于RBAC0模型的基础上，进行了角色的访问控制

B端产品之权限设计（RBAC权限模型）

一、前言

随着互联网的快速发展，B端行业也逐渐崛起，很多企业管理中使用的软件我们通常称其为B端管理系统，而在B端系统中“权限管理”是必不可少的功能，不同的系统中权限的应用复杂程度不一样，都是根据实际产品以及需求情况而设置合理的权限。而我们现在对于权限的设置基本上都是建立在RBAC权限模型上的、扩展的，下面我会通过介绍RBAC权限模型的概念以及结合实际业务情况列举权限设置的应用。

二、什么是RBAC权限模型？

RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色的访问控制。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What进行How的操作，也就是“主体”对“客体”的操作。其中who是权限的拥有者或主体（例如：User、Role），what是资源或对象（Resource、Class)。

简单的理解其理念就是将“角色”这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。

RBAC其实是一种分析模型，主要分为：基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2和统一模型RBAC3。

RBAC权限模型是基于角色的权限控制。模型中有几个关键的术语：

用户：系统接口及访问的操作者

权限：能够访问某接口或者做某操作的授权资格

角色：具有一类相同操作权限的用户的总称

1）RBAC0

RBAC0是RBAC权限模型的核心思想，RBAC1、RBAC2、RBAC3都是在RBAC0上进行扩展的。RBAC0是由四部分构成：用户、角色、会话、许可。用户和角色的含义很简单，通过字面意思即可明白，会话：指用户被赋予角色的过程，称之为会话或者是说激活角色；许可： 就是角色拥有的权限（操作和和被控制的对象），简单的说就是用户可使用的功能或者可查看的数据。

用户与角色是多对多的关系，用户与会话是一对一的关系，会话与角色是一对多的关系，角色与许可是多对多的关系。

2）RBAC1

RBAC1是在RBAC0权限模型的基础上，在角色中加入了继承的概念，添加了继承发的概念后，角色就有了上下级或者等级关系。

举例：集团权责清单下包含的角色有：系统管理员、总部权责管理员、区域权责管理员、普通用户，当管理方式向下兼容时，就可以采用RBAC1的继承关系来实现权限的设置。上层角色拥有下层的所有角色的权限，且上层角色可拥有额外的权限

3）RBAC2

RBAC2是在RBAC0权限模型的基础上，在用户和角色以及会话和角色之间分别加入了约束的概念（职责分离），职责分离指的是同一个人不能拥有两种特定的权限（例如财务部的纳入和支出，或者运动员和裁判员等等）。

用户和角色的约束有以下几种形式:

互斥角色：同一个用户在两个互斥角色中只能选择一个（也会存在一个用户拥有多个角色情况，但是需要通过切换用户角色来实现对不同业务操作）

基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的

先决条件约束：用户想要获得高级角色，首先必须拥有低级角色

会话和角色之间的约束，可以动态的约束用户拥有的角色，例如一个用户可以拥有两个角色，但是运行时只能激活一个角色。

例如：iconfont和蓝湖的用户与角色就采用了约束的概念，超级管理员只允许只有一个

4）RBAC3

RBAC3是RBAC1与RBAC2的合集，所以RBAC3包含继承和约束。

二、为什么要引用RBAC权限模型？

RBAC中具有角色的概念，如果没有角色这个概念，那么在系统中，每个用户都需要单独设置权限，而系统中所涉及到的功能权限和数据权限都非常多，每个用户都单独设置权限对于维护权限的管理员来说无疑是一件繁琐且工作量巨大的任务。

而引入角色这个概念后，我们只需要给系统设置不同的角色， 给角色赋予权限，再将用户与角色关联，这样用户所关联的角色就直接拥有了该角色下的所有权限。

例如：用户1~用户8分别拥有以下权限，，不同用户具有相同权限的我用不同的颜色做了区分，如下图：

在没有引入RBAC权限模型的情况下，用户与权限的关系图可采用下图的杨叔叔展示，每个用户分别设置对应的权限，即便是具有相同权限的用户也需要多次设置权限。

引入RBAC权限模型及引入了角色的概念，根据上面表格的统计，用户1、用户3、用户5、用户8拥有的权限相同，用户2、用户6、用户7拥有相同的权限，用户4是独立的权限，所以我们这里可以根据数据统计，以及实际的需求情况，可以建立三个不同的角色，角色A、角色B、角色C，三个角色分别对应三组用户不同的权限，如下图所示：

对应的上面的案例表格我们就可以调整为含有角色列的数据表，这样便可以清楚的知道每个用户所对应的角色及权限。

通过引用RBAC权限模型后，对于系统中大量的用户的权限设置可以更好的建立管理，角色的引入让具有相同权限的用户可以统一关联到相同的的角色中，这样只需要在系统中设置一次角色的权限，后续的用户便可以直接关联这些角色，这样就省去了重复设置权限的过程，对于大型平台的应用上，用户的数量成千上万，这样就可避免在设置权限这项工作上浪费大量的时间。

三、引入用户组的概念

我们依旧拿上面表格案例举例，虽然前面我们应用的RBAC权限模型的概念，但是对于大量用户拥有相同权限的用户，我们同样的也需要对每个用户设置对应的角色，如果一个部门上万人，那么我们就需要给这个部门上万人分别设置角色，而这上万其实是具有相同的权限的，如果直接采用基础的RBAC权限模型的话，那么面对这样的情况，无疑也是具有一个庞大的重复的工作量，并且也不利于后期用户变更的维护管理，那么针对相同用户具有相同的权限的情况，我们便可以引入用户组的概念。

什么是用户组呢？ 用户组：把具有相同角色的用户进行分类。

上面我们的数据表格案例中的用户1、用户3、用户5、用户8具有相同的角色A，用户2、用户6、用户7也拥有相同的角色B，那么我们就可以将这些具有相同角色的用户建立用户组的关系，拿上面的案例，我们分别对相同角色的用户建立组关系，如下：

用户1、用户3、用户5、用户8→建立用户组1

用户2、用户6、用户7→建立用户组2

因为用户4只有一个用户，所以直接还是单独建立用户与角色的关系，不需要建立用户组，当然尽管只有一个用户也是可以建立用户组的关系，这样有利于后期其他用户与用于4具有相同的角色时，就可以直接将其他用户添加到这个用户组下即可，根据业务的实际情况而选择适合的方案即可。

通过案例表格的变化我们就可以直观的看出权限设置变得清晰简洁了，通过第用户组赋予角色，可以减少大量的重复的工作，我们常见的企业组织、部门下经常会出现不同用户具有相同角色的情况，所以采用用户组的方式，便可以很好的解决这个问题，给具有相同权限的用户建立用户组，将用户组关联到对应的角色下，此用户组就拥有了此角色下的所有权限，而用户是属于用户组的，所以用户组下的所有用户也就同样的拥有了此角色下的所有权限。一个用户可以属于多个用户组，一个用户组也可以包括多个用户，所以用户与用户组是多对多的关系。

四、引入权限组的概念

权限组与用户组的原理差不多，是将一些相对固定的功能或者权限建立组的关系，然后再给此权限组赋予角色，目前我所接触的B端项目中使用权限组的概念的比较少，可简单的看一下关系图

四、功能权限和数据权限

B端系统中一般产品的权限由页面、操作和数据构成。页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限，数据可被增删改查。所以将权限管理分为 功能权限管理和数据权限管理。

功能权限管理：指的是用户可看到那些模块，能操作那些按钮，因为企业中的用户拥有不同的角色，拥有的职责也是不同的。

数据权限管理：指的是用户可看到哪些模块的哪些数据。

例如：一个系统中包含多个权责清单（清单1、清单2、清单3），系统管理员能对整个系统操作维护。。。。。

完整内容请查看公众号原文链接

原文链接：B端产品之权限设计（RBAC权限模型）

来源公众号《设计小余》

什么是rbac

基于权限的访问控制（Role Based Access Control），由于需要把权限抽象出来，做成taglib，所以最近看了一点理论，主要有：

;thread=10122

;thread=7309

及其他jdon里的一些文章。

具体实现的时候，大家作的都不太一样，而且对这个理论的认同度好像也有差异。

我现在疑惑的是：

1 现在有没有一套经过实践证明好用的基于java语言的RBAC实现，可以直接使用的。

2 sun的jaas是不是基于RBAC思想设计的，具体实现时，它对这样的授权（比如谁能添加，谁能修改什么栏目的什么记录，）支不支持，如果支持，sun的jaas在这方面有没有参考实现，忘了在什么地方看的，说chinaxp论坛用的是jaas来实现权限管理，不知是不是这样。

3 jive3的权限管理是不是基于RBAC的，因为我在看帮助时，看到了“role-based administration"，而且在管理jive的过程中，我感觉确实和自己了解的RBAC理论停相符的，当然，我对RBAC的理解可能有偏差。jive3的权限管理能在多大程度上抽象出

Java web怎么实现普通用户与管理员跳转不同页面

你都去查了user表了，你那个result里面取username，判断他不就可以了。在if(result.next())里面再判断一层，不就成了，取值差不多是result.get类型+（序号）的形式。

请教关于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． 参考配置单点登陆，因为权限管理和用户管理需要依赖单点登陆。

6． 下载相关依赖Java库：

下载cglib最新版本，拷贝asm.jar和cglib-2.1.3.jar到Tomcat/shared/lib。

下载c3p0最新版本，拷贝c3p0-0.9.1.1.jar到Tomcat/shared/lib。

下载mysql-connector最新版本，拷贝mysql-connector-java-5.0.4-bin.jar到Tomcat/shared/lib。

下载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=

sso.passport.logout=

# 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=

sso.passport.logout=

# rbac_admin.properties

rbac.admin.profile.explorer=?

rbac.admin.profile.profile=?

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和rbac模式的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。