RBAC权限模型_节点动态java精修学校
权限系统与RBAC模型综述RBAC（基于角色的访问控制）是基于角色的访问控制。
在上世纪90年代，一大批专家、学者和专业研究机构对RBAC的概念进行了研究，并提出了许多类型的RBAC模型，其中的信息安全技术实验室乔治梅森大学（名单）的RBAC96模型具有最广泛接受的系统。
RBAC认为权限的过程可以抽象如下：确定谁可以访问什么（操作人员）。这个逻辑表达式的值是真的吗
权限问题转换为谁、什么、以及如何、如何、如何以及如何构成访问权限三元组。
RBAC支持公认的安全原则：最小特权原则、职责分离原则和数据抽象原则。
支持最小特权原则，因为在RBAC模型中，我们可以通过限制分配给他们的角色的数量和大小来分配特权给用户相应的角色，只要我们不超出用户完成任务的需求。
实现职责分离的原则，因为在RBAC模型中可以实现指派两个角色的两个相互约束的责任，在敏感的任务中，比如检查账户，只需要在财务管理员和会计管理员中扮演两个角色。
数据抽象是通过抽象权限概念实现的。例如，在会计管理活动中，我们可以使用抽象的许可权利如信用和债务而不是使用阅读具体的许可，写和执行操作系统提供的角色。但不强迫这些原则得到落实，安全管理员可以允许对RBAC模型的配置使它不支持这些原则。因此，在何种程度上支持数据抽象是RBAC的RBAC模型的相关实施细则。
RBAC96是模范家庭，其中包括四~ RBAC0 RBAC3模型。
1。基本模型RBAC0定义任何完全支持RBAC概念体系的最低要求。
2、RBAC1，和rbac2都包含RBAC0，但每增加他们的独立性，他们被称为先进的模型。
角色分类的概念加入到一个角色可以继承和RBAC1，从另一个角色的权限。
有一些限制，rbac2强调一些限制在RBAC不同组件的配置。
3、RBAC3称为一个统一的模式，包括使用及物性和rbac2 RBAC1，，和包括RBAC0。这些模型构成的RBAC96模型家族。
RBAC模型简介
在RBAC0模型包括实体集3种类型，如用户（U）、角色（R）和许可证（P）。
对rabc0权限管理的核心部分，其他版本都是建立在0的基础上，看看类图：
RBAC0定义，可以形成一个RBAC控制系统元件的最小集。
在RBAC，有五种基本的数据元素，包括用户（用户）、作用（作用），目标对象（OBS）、手术操作（OPS），和许可权限（PRMS）。该模型表示用户、角色、访问权限和会话之间的关系。
每个角色都有至少一个权限，每个用户至少扮演一个角色；在相同的访问完全不同的两种分布的作用；会话是由用户控制，用户可以创建一个会话，激活多个用户角色，从而获取相应的访问权限，用户可以更改会议的积极作用，并且用户可以主动结束会话。
用户和角色是多对多的，这表明用户可以在不同的场景中拥有不同的角色。
例如，项目经理也可以是项目架构师等。当然，可以给多个用户提供一个角色，例如，项目中有许多组长和多个成员。
这里需要提出的是，用户和许可证的分离是相互独立的，使得授权认证更加灵活。
角色和权限（权限）是多对多的关系，说角色可以有更多的权限，同样的权限可以很容易地理解给多个角色，想想现实生活中，有不同级别的权限的场景，其实这是对模型的一个抽象的限制，生命是很容易理解的。
RBAC1，基于RBAC0模型，介绍了角色之间的继承关系，即角色之间的差异是上下级。角色之间的继承关系可分为一般继承关系和限制的继承关系。一般继承关系只要求角色继承关系是一个绝对的偏序关系，让角色之间的多重继承。限制继承关系进一步要求角色继承关系是一个树结构，实现角色间的单继承。
此模型适用于角色之间角色之间清晰的级别。
rbac2，基于RBAC0模型、角色的访问进行控制。
分离责任关系添加到rbac2模型，rbac2约束指定的强制性规则时应遵循的一个角色被分配给一个角色或角色分配给用户，当用户激活点的作用。责任分离包括静态责任分离动态职责分离。约束，结合用户权限关系的角色，决定了该rbac2模型用户的访问许可，具有多种约束。
互斥角色：同一用户只能分配给一组一组互斥角色不止一个角色，支持职责分离原则的相互排斥作用是指两个角色，各机关相互制约。对于这样一个角色，一个用户只能分配一个在某个活动的作用不能得到正确的同时使用两个角色。一个常见的例子：在审计活动中，一个角色不能分配给会计人员的作用，同时审计师。
基数限制：分配给角色的用户数量有限，用户可以容纳的角色数量有限，并且对应角色的访问权限也应该受到限制，以便控制系统中高级权限的分配；
前提的角色：角色可以分配给用户，如果用户已经是另一个角色的成员；相应的可以分配给角色的权限，只有当角色已经有另一个访问权。要想获得更高的权限，必须先有一个低级别的访问，在我们的生活中，这个国家的总统已经从副总统选举。
运行时互斥体：例如，允许用户有两个角色，但是不能同时激活这两个角色。
RBAC3，权限管理的最全面的水平，是基于RBAC0，整合和rbac2 RBAC1，最前面，和最复杂的：
总的来说，权限管理模型的引入将涉及到任何系统的权限管理模块。无论多么复杂和简单，我们都可以灵活地使用RBAC模型来解决我们的问题。
RBAC的优缺点
RBAC模型没有提供一种操作顺序控制机制，这种缺陷使得RBAC模型难以应用需要严格操作顺序的实体系统。
例如，在购物控制系统中，系统需要控制购买步骤，不允许在顾客未付款之前拿走货物。
2。实用RBAC模型数据库建模
1。扩展RBAC用户角色权限设计方案
RBAC（基于角色的访问控制、基于角色的访问控制）是用户通过角色与权限关联。总之，一个用户有多个角色，每一种都有一些特权。这样，用户权限模型的角色创建。该模型的用户与角色之间，与权力之间的作用，一般的人是一个多对多的关系。（如下图所示）
角色是什么它可以被理解为一种设定一定的权限，权限的载体。例如：一个论坛系统，超级管理员、版主都是角色，管理员可以在管理版本管理岗位，在管理版的用户，这些权限授予这些权限。一个用户，你不必直接授予权限的用户，但用户可以给主持人的作用。
当用户的数量是非常大的，它是授权系统每一个用户通过一个非常繁琐的事情。在这一点上，用户需要进行分组，各有一个以上的用户，用户组，除了授权用户，也可以授权用户组。在这种方式中，所有用户的权利，是权利的用户，用户在用户组的权限。（下图是用户组之间的关系，用户和角色三）
应用程序系统的权限是什么对模块的操作功能，上传的文件删除，进入菜单，甚至在一个页面的可见性按钮，图片的控制，都属于权利的范畴，一些权限的设计将功能操作作为一类，和文件、菜单、页面元素等为另一类，从而构成了用户角色权限资源授权模型。做数据建模时，我们可以管理功能操作和资源的统一，那就是，他们都是权限表直接相关，这可能是更方便和可扩展性（见下文）。
请注意权限表中的一列权限类型，我们根据来区分什么样的权利的价值，如访问菜单，菜单功能模块操作权限，文件，修改页面元素的控制权限元素的可见性。这种设计的好处是：第一，它不需要区分许可经营和资源之间。（事实上，有时很难将它们区分开来，例如菜单、是否理解为资源或功能模块权限）。其次，扩展方便。当系统要控制新事物时，我只需要创建一个新的相关表权限XX关联表，并确定这种权限的权限类型字符串。
需要注意的是，权限表和权限菜单关联表重要，权限菜单关联表和菜单表是一对一的关系。（文件、页面权限，功能操作，等等），每添加一个菜单，你必须同时插入在每三表的记录。这样，没有权限的菜单相关表是允许的，这样的权限表是菜单表直接相关。此时，将保存菜单的ID列表添加到权限表中。权限表用于通过权限类型和ID.来区分哪个记录属于权限的类型。
这里，RBAC权限模型的扩展模型的完整设计如下：
随着系统越来越大，角色组可以通过角色组进行分类和管理，以便于管理。不同的用户组、角色组不参与授权。例如，在电网系统中的权限管理模块的作用是连接到区局和区局可以作为一个角色组，它不参与权力的分配。此外，为了为了便于管理和上述主要表查找，可以采用树结构，如树型菜单，功能树，等等，当然，这些不需要分配权限。
2，百度百科所示的模型