zoukankan      html  css  js  c++  java
  • 扩展RBAC用户角色权限设计方案

    RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用 户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系。(如下图)


    角色是什么?可以理解为一定数量的权限的集合,权限的载体。例如:一个论坛系统,“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等,这些是权限。要给某个用户授予这些权限,不需要直接将权限授予用户,可将“版主”这个角色赋予该用户。
    当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,每个用户组内有多个用户。除了可给 用户授权外,还可以给用户组授权。这样一来,用户拥有的所有权限,就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色 三者的关联关系)
    在应用系统中,权限表现成什么?对功能模块的操作,对上传文件的删改,菜单的访问,甚至页面上某个按钮、某个图片的可见性控制,都可属于权限的 范畴。有些权限设计,会把功能操作作为一类,而把文件、菜单、页面元素等作为另一类,这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模 时,可把功能操作和资源统一管理,也就是都直接与权限表进行关联,这样可能更具便捷性和易扩展性。(见下图)


    请留意权限表中有一列“权限类型”,我们根据它的取值来区分是哪一类权限,如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。
    这样设计的好处有二。其一,不需要区分哪些是权限操作,哪些是资源,(实际上,有时候也不好区分,如菜单,把它理解为资源呢还是功能模块权限 呢?)。其二,方便扩展,当系统要对新的东西进行权限控制时,我只需要建立一个新的关联表“权限XX关联表”,并确定这类权限的权限类型字符串。
    这里要注意的是,权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。(文件、页面权限点、功能操作等同理)。也就是每添加一个 菜单,就得同时往这三个表中各插入一条记录。这样,可以不需要权限菜单关联表,让权限表与菜单表直接关联,此时,须在权限表中新增一列用来保存菜单的 ID,权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。
    到这里,RBAC权限模型的扩展模型的完整设计图如下:


    随着系统的日益庞大,为了方便管理,可引入角色组对角色进行分类管理,跟用户组不同,角色组不参与授权。例如:某电网系统的权限管理模块中,角色就是挂在 区局下,而区局在这里可当作角色组,它不参于权限分配。另外,为方便上面各主表自身的管理与查找,可采用树型结构,如菜单树、功能树等,当然这些可不需要 参于权限分配。
    以上,是从基本的RBAC模型进行了扩展,具体的设计要根据项目业务的需要作调整。欢迎大家提出批评意见!

    不是吧,猛一看以为是我自己的数据模型呢?我以为只有我的权限系统有“页面元素”这个概念呢。
    --------------------------------------------
     
    有时候需要单独为一个用户增加一两个权限的,这时候单独为这个用户设计一个“角色”,不值得,所以我设计的是:既可以通过角色为用户分配权限,也可以直接将权限分配给用户。
    --------------------------------------------
     
    我接触过的几个开发人员,都不明白为什么要直接给用户分配权限,但是在软件的实际应用中,如果完全基于“角色”为人员分配权限,你会 发现角色之间重复、冗余的权限很多,这样反复的定义多种多样的“角色”,还不如设计成可以直接为人员分配权限呢。
    --------------------------------------------
     
    权限管理基本上分为以下几个步骤:
    1、定义权限-》定义角色-》为人员分配角色(或者直接分配权限),这是一个分配权限的过程;
    --------------------------------------------
     
    2、定义受保护资源-》为“受保护资源”指定授权权限,这是一个授权的过程;
    --------------------------------------------
     
    3、应用程序请求“受保护资源”-》“受保护资源”的授权权限与人员持有的权限进行匹配-》匹配成功,允许访问资源,匹配失败,不允许访问资源,这是一个认证的过程。
    --------------------------------------------
     
     
    上面这三个过程,是典型的“操作权限”的流程。
    --------------------------------------------
    关于“页面元素”的控制,目前多数权限管理系统,都是用“自定义权限标签”来控制页面元素的显示与否的。
    我目前也是这样实现的,但是我一直认为:其实用“自定义权限标签”来控制页面元素的显示与否,跟直接在视图中使用程序逻辑判断,是一样的,并没有做到“灵活配置”,当权限编码改变,或者权限含义改变时,还是要去动页面的标签,所以跟写死没什么分别。
     
    如果页面元素是通过服务端组装成json,或者别的格式的数据,然后返回到视图层进行渲染,这样的话,就可以做到“页面元素的权限灵活配置了”,可以通过数据库定义那些按钮对那些权限或角色进行显示。
    “服务端组装视图层组件,返回视图层渲染”,这个模式虽然做到了“对页面元素的权限灵活配置”,但是牺牲掉了很多东西,比如加大了服务端的复杂度,使得页面的设计更加“程序员化”,而不是“美工化”等。
    --------------------------------------------
     
    至于最关键的“数据权限”,也就是人员对数据的读取深度的控制,是更为复杂的流程。
    --------------------------------------------
    对于“数据深度”的控制,我目前的做法是和业务结合的非常紧密, 即:在读取数据的程序中,比如“列表”页,首先判断当前登陆者有没有“读取任意深度的权限”,如果有,就不做读取限制;如果没有,则判断当前登录人员是不 是部门主管,如果是,则递归读取本部门下的所有数据,如果不是主管,则只读取自己的数据。
    --------------------------------------------
    “数据深度”的控制,细设计的话,应该可以更通用,更灵活,大家有什么更好的思路,可以讨论一下。
     
    --------------------------------------------
    我目前设计的是一个人员只能有一个“角色”,当然,如果设计成一个人员有多个“角色”,也不是很复杂的事情,在“用户表”和“角色表”之间增加一个“用户-角色映射表”就可以了,但是为了系统的简单起见,我把这种设计简化了。
    --------------------------------------------
     
    以下是我的“权限控制”的部分数据模型:
     
  • 相关阅读:
    Linux 学习 step by step (1)
    ubuntu server nginx 安装与配置
    ubuntu server samba服务器配置
    iOS app集成支付宝支付流程及后台php订单签名处理
    mac 连接windows 共享内容
    linux 文件查找,which,whereis,locate,find
    ubuntu server vsftpd 虚拟用户及目录
    ubuntu server 安装 mantis bug tracker 中文配置
    ubuntu server vsftpd 匿名用户上传下载及目录设置
    linux 用户管理,用户权限管理,用户组管理
  • 原文地址:https://www.cnblogs.com/eggbucket/p/2725842.html
Copyright © 2011-2022 走看看