基于RBAC权限管理模型学习

在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。

在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。

角色与角色的关系可以建立起来以囊括更广泛的客观情况。

BAC支持三个著名的安全原则:最小权限原则,责任分离原则和数据抽象原则。

(1)最小权限原则之所以被RBAC所支持,是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。

(2)责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现,比如要求一个计帐员和财务管理员共参与同一过帐。

(3)数据抽象可以通过权限的抽象来体现,如财务操作用借款、存款等抽象权限,而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。

RBAC有许多部件(BUCU),这使得RBAC的管理多面化。尤其是,我们要分割这些问题来讨论:用户与角色的指派;角色与权限的指派;为定义角色的继承进行的角色与角色的指派。

这些活动都要求把用户和权限联系起来。然而在很多情况下它们最好由不同的管理员或管理角色来做。对角色指派权限是典型的应用管理者的职责。

当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,每个用户组内有多个用户。除了可给用户授权外,还可以给用户组授权。进一步,可以分出角色组等概念。

银行应用中,把借款、存款操作权限指派给出纳角色,把批准贷款操作权限指派给经理角色。而将具体人员指派给相应的出纳角色和管理者角色是人事管理的范畴。角色与角色的指派包含用户与角色的指派、角色与权限的指派的一些特点。更一般来说,角色与角色的关系体现了更广泛的策略。

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中,who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。

Who:权限的拥用者或主体(如Principal、User、Group、Role、Actor等等)

What:权限针对的对象或资源(Resource、Class)。

How:具体的权限(Privilege,正向授权与负向授权)。

Operator:操作。表明对What的How操作。也就是Privilege+Resource

Role:角色,一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.

Group:用户组,权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承),也可以包含用户,组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化,以满足不同层级权限控制的要求。

RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role,role可以包括多个user。

凡是用过RDBMS都知道,n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上,整个RBAC都是基于关系模型。

Session在RBAC中是比较隐晦的一个元素。标准上说:每个Session是一个映射,一个用户到多个role的映射。当一个用户激活他所有角色的一个子集的时候,建立一个session。每个Session和单个的user关联,并且每个User可以关联到一或多个Session.

在RBAC系统中,User实际上是在扮演角色(Role),可以用Actor来取代User,这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限,RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念就具象到一个人。

这里的Group和GBAC(Group-Based Access Control)中的Group(组)不同。GBAC多用于操作系统中。其中的Group直接和权限相关联,实际上RBAC也借鉴了一些GBAC的概念。

Group和User都和组织机构有关,但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型,包括部门,人,职位等等,而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。

Party模式中的Person和User的关系,是每个Person可以对应到一个User,但可能不是所有的User都有对应的Person。Party中的部门Department或组织Organization,都可以对应到Group。反之Group未必对应一个实际的机构。例如,可以有副经理这个Group,这是多人有相同职责。

引入Group这个概念,除了用来解决多人相同角色问题外,还用以解决组织机构的另一种授权问题:例如,A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group,就可直接授权给这个Group。

基于RBAC权限管理模型学习

时间: 2024-10-13 03:15:51

基于RBAC权限管理模型学习的相关文章

基于RBAC权限管理

一般web系统操作人员多时都会需求权限管理,一来限制操作范围,二来限制数据公开度. 现在最流行的一个模式为 RBAC (Role-Based Access Control) 基于角色的访问控制.设定权限范围定义到角色中,然后再分配到每个用户. 这里仅以一般后台管理系统为例,叙说数据结构: 需求: 菜单需要针对不同部门使用不同的菜单结构. 权限项能精确到页面中某个内容或局部功能. 基本要求:没有权限的菜单,页面中内容或链接禁止显示. 表结构 CREATE TABLE `power_item` (

RBAC基于角色的权限管理模型

一.权限管理模型的必要性: a. 安全性:防止误操作,防止数据泄露,保证信息的安全. b. 数据隔离:保持不同的角色具有不同的权限,只能看到自己权限范围内的数据 二.权限管理模型的发展: a. 传统的权限管理:随着用户数量的增大和用户权限区别的增大,传统的权限管理需要针对每个用户依次管理,成本较高. b. RBAC:Role-Based Access Control 用户-角色-权限,权限与角色相关联,用户与角色相关联,通过对用户赋予相应的角色,再去获取相应的权限,从而实现了用户与权限的解耦,具

vue基于d2-admin的RBAC权限管理解决方案

前两篇关于vue权限路由文章的填坑,说了一堆理论,是时候操作一波了. vue权限路由实现方式总结 vue权限路由实现方式总结二 选择d2-admin是因为element-ui的相关开源项目里,d2-admin的结构和代码是让我感到最舒服的,而且基于d2-admin实现RBAC权限管理也很方便,对d2-admin没有大的侵入性的改动. 预览地址 Github 相关概念 不了解RBAC,可以看这里企业管理系统前后端分离架构设计 系列一 权限模型篇 实现了RBAC模型权限控制 菜单与路由独立管理,完全

RBAC权限管理

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限. 这样,就构造成“用户-角色-权限”的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,“超级管理员”.“版主”都是角色.版主可管理版内的帖子.可管理版内的用户等,这些是权限.要给某个用户授予这些权限,不需要直接

使用SpringSecurity3实现RBAC权限管理

1. What? 什么是权限管理? 具体可参见百度:http://baike.baidu.com/view/2108713.htm 名词备注: 数据级权限:百科内的权限管理一文解释的比较不错,但其中的"数据级权限"有的人看来会觉得有点摸不着头脑.数据级权限,即表示权限与特定数据有联系的权限,比方说,某用户只能创建100个用户.这个100,就是数据级权限的一个指标. 2. How?怎么样实现权限管理? 2.1.一种烦恼 也许很多程序员会在权限管理中遇到这样的一个问题. 大部分项目都需要权

基于Django实现RBAC权限管理

概述 RBAC(Role-Based Access Control,基于角色的访问控制),通过角色绑定权限,然后给用户划分角色.在web应用中,可以将权限理解为url,一个权限对应一个url. 在实际应用中,url是依附在菜单下的,比如一个简单的生产企业管理系统,菜单可以大致分为以下几块:制造.资材.生产管理.人事.财务等等.每个菜单下又可以有子菜单,但最终都会指向一个url,点击这个url,通过Django路由系统执行一个视图函数,来完成某种操作.这里,制造部的员工登录系统后,肯定不能点击财务

shiro教程(1)-基于url权限管理

shiro教程系列 shiro教程(2) shiro教程(3) shiro教程(4) 一. 权限管理 1.1 什么是权限管理 基本上涉及到用户参与的系统都要进行权限管理,权限管理属于系统安全的范畴,权限管理实现对用户访问系统的控制,按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源. 权限管理包括用户身份认证和授权两部分,简称认证授权.对于需要访问控制的资源用户首先经过身份认证,认证通过后用户具有该资源的访问权限方可访问. 1.2 用户身份认证 1.2.1 概念 身份认证,就是

【基于url权限管理 shiro(一)】--基础

只要有用户参与的系统一般都要有权限管理,权限管理实现对用户访问系统的控制,按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源.权限管理包括用户认证和授权两部分.   用户认证 1.概念 用户认证,用户去访问系统,系统要验证用户身份的合法性.最常用的用户身份验证的方法:1.用户名密码方式.2.指纹打卡机.3.基于证书验证方法..系统验证用户身份合法,用户方可访问系统的资源. 2.用户认证流程   3.关键对象 subject:主体,理解为用户,可能是程序,都要去访问系统的资源,系

【转】RBAC权限管理

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成“用户-角色-权限”的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,“超级管理员”.“版主”都是角色.版主可管理版内的帖子.可管理版内的用户等,这些是权限.要给某个用户授予这些权限,不需要直接将