前言

权限往往是一个极其复杂的问题,但也可简单表述为这样的逻辑表达式:判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用,需要根据项目的实际情况和具体架构,在维护性、灵活性、完整性等N多个方案之间比较权衡,选择符合的方案。

目标

直观,因为系统最终会由最终用户来维护,权限分配的直观和容易理解,显得比较重要,系统不辞劳苦的实现了组的继承,除了功能的必须,更主要的就是因为它足够直观。

简单,包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑,而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。

扩展,采用可继承在扩展上的困难。的Group概念在支持权限以组方式定义的同时有效避免了重定义时

现状

对于在企业环境中的访问控制方法,一般有三种:

1.自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。

2.强制型访问控制方法。用于多层次安全级别的军事应用。

3.基于角色的访问控制方法(RBAC)。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是:1.减小授权管理的复杂性,降低管理开销。2.灵活地支持企业的安全策略,并对企业的变化有很大的伸缩性。

名词

粗粒度:表示类别级,即仅考虑对象的类别(the type of object),不考虑对象的某个特

定实例。比如,用户管理中,创建、删除,对所有的用户都一视同仁,并不区分操作的具体对象实例。

细粒度:表示实例级,即需要考虑具体对象的实例(the instance of object),当然,细

粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如,合同管理中,列表、删除,需要区分该合同实例是否为当前用户所创建。

原则

权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义,它们也能被理解为是“业务逻辑”的一部分。比如,要求:“合同资源只能被它的创建者删除,与创建者同组的用户可以修改,所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题,也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题,在整个权限系统的架构设计之中不予过多考虑。当然,权限系统的架构也必须要能支持这样的控制判断。或者说,系统提供足够多但不是完全的控制能力。即,设计原则归结为:“系统只提供粗粒度的权限,细粒度的权限被认为是业务逻辑的职责”。

需要再次强调的是,这里表述的权限系统仅是一个“不完全”的权限系统,即,它不提供所有关于权限的问题的解决方法。它提供一个基础,并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上,根据“业务逻辑”的独特权限需求,编码实现剩余部分(或者说细粒度的)部分,才算完整。回到权限的问题公式,通用的设计仅解决了Who+What+How 的问题,其他的权限问题留给业务逻辑解决。

概念

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

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

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

Role:是角色,拥有一定数量的权限。

Operator:操作。表明对What的How 操作。

说明

User:与 Role 相关,用户仅仅是纯粹的用户,权限是被分离出去了的。User是不能与 Privilege 直接相关的,User 要拥有对某种资源的权限,必须通过Role去关联。解决 Who 的问题。

Resource:就是系统的资源,比如部门新闻,文档等各种可以被提供给用户访问的对象。资源可以反向包含自身,即树状结构,每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。

Privilege:是Resource Related的权限。就是指,这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限,叫做"部门新闻发布权限"。这就表明,该Privilege是一个发布权限,而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。权限,包括系统定义权限和用户自定义权限用户自定义权限之间可以指定排斥和包含关系(如:读取,修改,管理三个权限,管理 权限 包含 前两种权限)。Privilege 如"删除" 是一个抽象的名词,当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。拿新闻发布来说,发布是一种权限,但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时,才会产生真正的 Privilege。这就是 Privilege Instance。权限系统根据需求的不同可以延伸生很多不同的版本。

Role:是粗粒度和细粒度(业务逻辑)的接口,一个基于粗粒度控制的权限框架软件,对外的接口应该是Role,具体业务实现可以直接继承或拓展丰富Role的内容,Role不是如同User或Group的具体实体,它是接口概念,抽象的通称。

Group:用户组,权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户,组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。在粗粒度控制上,可以认为,只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上,在业务逻辑的判断中,User仅应关注其直接属于的Group,用来判断是否“同组” 。Group是可继承的,对于一个分级的权限实现,某个Group通过“继承”就已经直接获得了其父Group所拥有的所有“权限集合”,对这个Group而言,需要与权限建立直接关联的,仅是它比起其父Group需要“扩展”的那部分权限。子组继承父组的所有权限,规则来得更简单,同时意味着管理更容易。为了更进一步实现权限的继承,最直接的就是在Group上引入“父子关系”。

User与Group是多对多的关系。即一个User可以属于多个Group之中,一个Group可以包括多个User。子Group与父Group是多对一的关系。Operator某种意义上类似于Resource + Privilege概念,但这里的Resource仅包括Resource Type不表示Resource Instance。Group 可以直接映射组织结构,Role 可以直接映射组织结构中的业务角色,比

关于用户角色权限的一点想法(1)相关推荐

  1. RBAC用户角色权限设计方案

    RBAC用户角色权限设计方案 转自http://www.cnblogs.com/zwq194/archive/2011/03/07/1974821.html RBAC(Role-Based Acces ...

  2. Mysql —— C语言链接mysql数据库,用户 角色 权限(用户根据角色的不同拥有增删改查的权限、用户有三种认证方式)

    db_修改过(用户 角色 权限): 1.新增用户时候id 改为最大id值加一,之前用的select查看出来的记录数加一,删除后再增加会出错: 2.删除用户时候,若该用户创建过其他用户(不能改此用户名. ...

  3. Jenkins中安装Role-based Authorization Strategy插件来实现用户角色权限管理

    场景 CentOS中Jenkins的下载.安装.配置与启动(图文教程): https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/11649 ...

  4. 【深度解析RBAC用户-角色-权限设计方案,以及核心逻辑代码的讲解】

    首先对于b2b.b2c等这一些网站后台,一般情况下都需要权限管理的设计与实现,对于这部分,通常是固定不变的,每次只需要做少量的改动即可. 如何设计这几张表呢? RBAC(基于角色的访问控制),也就是用 ...

  5. Web开发中的用户角色权限设计总结

    在Web开发中关于权限管理设计大抵涉及到两个方面:一:功能方面权限设计:二:资源方面权限设计.二者比较来看,功能方面权限的可重用性更高. 1.关于权限: 按照角色权限的最简单的设计 名称 描述 用户 ...

  6. oracle查询用户权限和角色_详解jenkins配置用户角色权限的实现方法

    概述 今天介绍下jenkins应该怎么去配置用户角色权限,注意jenkins 配置用户角色权限需要安装插件 Role Strategy Plugin. 1.安装 Role Strategy Plugi ...

  7. SpringSecurity动态加载用户角色权限实现登录及鉴权

    本文来说下SpringSecurity如何动态加载用户角色权限实现登录及鉴权 文章目录 概述 动态数据登录验证的基础知识 UserDetails与UserDetailsService接口 实现User ...

  8. java用户角色权限管理 只显示姓_扩展RBAC用户角色权限设计方案

    RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用 ...

  9. 系统权限控制设计001---RBAC用户角色权限设计方案

    RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用 ...

最新文章

  1. Centos7 关闭防火墙(转)
  2. python视频教程从入门到精通全集-零基础小白python从入门到精通视频(全60集)...
  3. Linux命令备忘录: jobs 显示Linux中的任务列表及任务状态命令
  4. C++中this指针的用法详解
  5. list接口中的常用方法例子
  6. OpenMV(二)--IDE安装与固件下载
  7. lua游戏开发实践指南光盘_Godot游戏开发实践之一:用High Level Multiplayer API制作多人游戏(上)
  8. WPF通用窗体模板【2】
  9. ico图标概述 附生成链接
  10. 电脑连不上网—更改电脑ip
  11. 十七点学完安全知识超级详细了解进程和病毒知识 转载
  12. Pytorch:optim.zero_grad()、pred=model(input)、loss=criterion(pred,tgt)、loss.backward()、optim.step()的作用
  13. man adduser
  14. 【CSON原创】javascript实现3D涂鸦效果
  15. 转:redis实践经验分享
  16. Android自定义控件之应用程序首页轮播图
  17. less使用语法详解
  18. VBox虚拟机Ubuntu共享文件夹设置自动挂载
  19. sql 过滤重复字段,取最早或最新记录
  20. 同步助手java_QQ同步助手Java版发布

热门文章

  1. ORB_SLAM2 源码解析 ORB_SLAM2简介(一)
  2. [条码打印]使用斑马语言(ZPL)打印汉字
  3. 专家鉴定这是2022最顶级的python框架,没有之一
  4. 用c语言写生成 mif文件的软件,生成mif文件的几种方法总结
  5. LOAM论文阅读笔记
  6. 从零开始的VUE项目–01(前期准备和前台vue搭建)
  7. 微信小程序两个view同一行两侧对齐
  8. cura_build 开源库安装
  9. Device IPC-1
  10. 数据挖掘基础知识整理