rbac

RBAC权限管理 近 2 年一直使用蚂蚁金服的 Ant Design UI 框架以及其开箱即用的中台前端/设计解决方案 ANT DESIGN PRO （去年的圣诞风波有点影响，希望不再发生类似的事情），框架是一直更新一直迭代，不过里面涉及权限管理的部分的使用场景还是比较有限，兼容不了需要细化到各模块中的具体动作的场景。授人以鱼不如授人以渔，没有就自己撸一个呗。 设计思想 虽然是自己撸，但还是得站在前辈的肩膀上，离开设计的代码都不够优雅。向我司的校长（霸气绰号，具体为什么叫校长可以在 https://www.luweitech.cn/ 上找找，可能能找到 (#^.^#) ）学习——写代码要写得像诗一样优雅。 找了一圈，最终选了一个设计思想——RBAC， RBAC 以角色为基础的访问控制（英语：Role-based access control，RBAC） ，简单可以归纳为 who、what、how，即，who 对 what进行了 how 的操作，翻译成广东话就系：“有一个靓仔企一个野里面做左滴野”。 一张简单的图（图是盗来的~）理解： 即，张三、李四是“销售角色”，而“销售角色拥有查看“客户列表”和“编辑客户”两个动作的权限，自然而然的，张三、李四就拥有查看“客户列表”和“编辑客户”两个动作的权限。 完整一点就是（图也是盗来的）： 由上可以看出，核心就三步： 定义角色

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 用户管理手册 系统术语 用户 系统的使用者通常称为用户，用户登录后，系统通过各种标识赋予用户操作和查看权限。 后台需要对用户账户、操作权限和数据权限等进行管理。用户管理贯穿业务各个环节，是支撑业务运营的核心部分。 系统用户一般分为内部用户和外部用户。这种区分是从平台运维角度出发，平台运维公司的员工称为内部用户，其他用户称为外部用户。 外部用户 外部用户隶属关系比较复杂，有的挂靠在某公司之下，无需注册，由系统管理员分配账户。 有的则以独立个体存在，例如：钉钉，以独立个体注册，公司邀请员工，员工同意后才有了归属。 第三种情况是用户以独立个体注册时选择所属公司，这种方式存在两个问题： 用户随意选择企业，不能保证准确性； 是否要在后台维护企业基础数据，不维护的话，无法统一数据源，维护的话，不能覆盖全部注册用户的企业。 选择哪种方式，需要根据实际业务情况进行设计。 例如 目前平台的服务对象是门店销售员，由于业务冲突，平台无法获得企业级的合作，前两种情况需要隶属公司在平台上进行操作，只能选择第三种方式，用户以独立个体注册平台，并填写所属企业。 为避免第三种方式存在的问题，做如下处理： 用户注册填写企业，无需选择基础数据； 后台维护企业基础数据； 用户审核时，有平台客服人员选择企业基础数据。 这样既减少了用户操作的繁琐

PHPCMS中的RBAC权限系统主要用到了4张数据表：管理员表，角色表，菜单表，菜单权限表。先来看看数据库的数据表结构： admin 管理员表 ID 字段 类型 Null 默认 索引 额外 注释 1 userid mediumint(6) unsigned PK auto_increment 用户id 2 username varchar(20) YES INDEX 用户名 3 password varchar(32) YES 密码 4 roleid smallint(5) YES 0 角色 5 encrypt varchar(6) YES 加密因子 6 lastloginip varchar(15) YES 最后登录ip 7 lastlogintime int(10) unsigned YES 0 最后登录时间 8 email varchar(40) YES Email 9 realname varchar(50) NO 真实姓名 10 card varchar(255) NO 密保卡 admin_role 角色表 ID 字段 类型 Null 默认 索引 额外 注释 1 roleid tinyint(3) unsigned PK auto_increment 角色id 2 rolename varchar(50) NO 角色名称 3 description text NO 描述

基于RBAC的权限设计模型： 1 RBAC 介绍 　　RBAC 模型作为目前最为广泛接受的权限模型。 　　NIST （The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　图表 1 RBAC 0 模型 l RBAC0 定义了能构成一个RBAC控制系统的最小的元素集合 　　在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。 l

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 权限的设计中比较常见的就是RBAC基于角色的访问控制,基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。 一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。 在Angular构建的单页面应用中,要实现这样的架构我们需要额外多做一些事.从整体项目上来讲,大约有3处地方,前端工程师需要进行处理. 1. UI处理(根据用户拥有的权限,判断页面上的一些内容是否显示) 2. 路由处理(当用户访问一个它没有权限访问的url时,跳转到一个错误提示的页面) 3. HTTP请求处理(当我们发送一个数据请求,如果返回的status是401或者401,则通常重定向到一个错误提示的页面) 如何实现? 首先需要在Angular启动之前就获取到当前用户的所有的permissions,然后比较优雅的方式是通过一个service存放这个映射关系.对于UI处理一个页面上的内容是否根据权限进行显示,我们应该通过一个directive来实现.当处理完这些

RBAC用户角色权限设计方案 转自 http://www.cnblogs.com/zwq194/archive/2011/03/07/1974821.html RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如下图） 角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。 当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系） 在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单