1.6 JeeGit 3.0 系统核心模块jeegit-module-sys 数据库设计 RBAC RBAC96(RBAC0+RBAC1+RBAC2+RBAC3) ARBAC97

Posted 2022-03-24 长春叭哥

希望各位高手多多留言指点！

1.6.1 jeegit-module-sys 模块

国内我们常见到的开源权限管理系统，大部分仅仅实现了标准的RBAC模型。这种模型对于组织机构简单，用户数量不大的中小企业来讲，显然是十分够用的。

JeeGit的主旨是为Web3.0 时代的互联网平台提供一款快速开发平台，我们的目标是为企业快速赋能互联网平台能力。当动辄是面向全国甚至全球的用户时，标准的RBAC模型显然无法满足。经过调研ARBAC97正是为解决超大数据量以及分布式高并发而生的一套权限模型。

资料推荐
权限基础 RBAC、RBAC96、ARBAC97、ABAC、DRBAC、PBAC、ABE 权限模型讲解

1.6.2 RBAC（Role-Based Access Control ）基于角色的访问控制

在20世纪90年代期间，大量的专家学者和专门研究单位对RBAC的概念进行了深入研究，先后提出了许多类型的RBAC模型，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有系统性，得到普遍的公认。

RBAC认为权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。

即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。

RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。

最小特权原则得到支持，是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
数据抽象是借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RBAC模型的实现细节有关。

1.6.3 RBAC96

1 RBAC0定义了完全支持RBAC概念的任何系统的最低需求。

2 RBAC1和RBAC2两者都包含RBAC0，但各自都增加了独立的特点，它们被称为高级模型。

3 RBAC1中增加了角色分级的概念，一个角色可以从另一个角色继承许可权。

4 RBAC2中增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。

5 RBAC3称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。这些模型构成了RBAC96模型族。

1.6.3.1 RBAC0

RBAC0的模型中包括用户（U）、角色（R）和许可权（P）等3类实体集合。

RABC0 是权限管理的核心部分，其他的版本都是建立在0的基础上的，国内大部分开源框架模型大部分属于RBAC0 模型！

RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。

在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，此模型指明用户、角色、访问权限和会话之间的关系。

每个角色至少具备一个权限，每个用户至少扮演一个角色；可以对两个完全不同的角色分配完全相同的访问权限；会话由用户控制，一个用户可以创建会话并激活多个用户角色，从而获取相应的访问权限，用户可以在会话中更改激活角色，并且用户可以主动结束一个会话。

用户和角色是多对多的关系，表示一个用户在不同的场景下可以拥有不同的角色。

例如项目经理也可以是项目架构师等；当然了一个角色可以给多个用户，例如一个项目中有多个组长，多个组员等。

这里需要提出的是，将用户和许可进行分离，是彼此相互独立，使权限的授权认证更加灵活。

角色和许可（权限）是多对多的关系，表示角色可以拥有多分权利，同一个权利可以授给多个角色都是非常容易理解的，想想现实生活中，当官的级别不同的权限的情景，其实这个模型就是对权限这方面的一个抽象，联系生活理解就非常容易了。

1.6.3.2 RBAC1

RBAC1，基于RBAC0模型，引入角色间的继承关系，即角色上有了上下级的区别，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。

这种模型合适于角色之间的层次明确，包含明确。

1.6.3.3 RBAC2

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

RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可，此约束有多种。

互斥角色 ：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。
基数约束 ：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人有限的；
先决条件角色 ：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。
运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。

1.6.3.4 RBAC3

RBAC3称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。RBAC3，也就是最全面级的权限管理，它是基于RBAC0的基础上，将RBAC1和RBAC2进行整合了，最前面，也最复杂的。

综上为权限管理模型的相关介绍，其实在任何系统中都会涉及到权限管理的模块，无论复杂简单，我们都可以通过以RBAC模型为基础，进行相关灵活运用来解决我们的问题。

1.6.4 jeegit-module-sys 最终设计

最终设计时，引入了组的概念。并做了性能优化。核心模块虽然没有设计在线国际化功能，但是并不代表产品不支持国际化。jeegit 不推荐在线实时国际化功能，主要因为jeegit的国际化采用物理级国际化策略！并利用消息队列技术，对于实际运营的国家系统，给予通知，请求对方同步更新，而对于未运营国家，则自动同步国际化。这样虽然系统物理空间变大了，但是以产品为主，数据量相对小的中小企业全球范围内营销产品！ 最重要的是，国际化营销时，我们的为了提供用户体验度，本身也要将服务器选择不同的服务器节点。以提高不同国家的访问速度。所以，jeegit内部，既有Java传统的国际化i18n方案，又整合了一套同数据库传译的解决方案。为未来企业在针对产品做长尾词，短尾词，地域营销裂变推广做好准备！

在线预览
http://101.43.250.170/jeegit/dbdocs/index.html

1.6.4.1 核心设计

1.6.4.2 完整设计

1.6.5 RBAC的优缺点

RBAC模型没有提供操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作次序的实体系统。

例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到模型。不过对于这类需求，我们未来会引入工作流引擎，服务于互联网类业务！解决该类问题！

1.6.6 参考资料